> On 19 Dec 2014, at 10:35, Michael Welzl <[email protected]> wrote: > >> >> On 19. des. 2014, at 20.29, Michael Welzl <[email protected]> wrote: >> >> >>> On 19. des. 2014, at 20.05, Brian Trammell <[email protected]> wrote: >>> >>> >>>> On 18 Dec 2014, at 22:37, Michael Welzl <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> Thanks for this update! >>>> >>>> A question: >>>> >>>>> We've posted a -01 rev of the TAPS transports document. We believe that >>>>> the format and level of detail for the TCP section is about what we're >>>>> targeting for each of the other sections, but this is still open to >>>>> discussion. >>>> >>>> Why is Nagle not a part of the protocol components and interface >>>> description? It’s mentioned in the protocol description above, and it’s >>>> something that an application decides. >>> >>> Simple omission. >>> >>> Should we make an attempt to give this (as a component) a generic name? >>> "Selectable sender side buffering"? Or can we just call it simply "Nagle"? >> >> In >> http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf >> we took SCTP's term for the same function because we found it more >> meaningful than "Nagle": Application PDU Bundling. I like that - it's also >> perhaps useful to folks to reuse terminology when we mean the exact same >> thing. > > Very sorry for writing a separate email! But having this open made me notice > another one: "error detection" (or "integrity check", whatever you prefer). > There's a checksum, it can't be disabled, it's covering the full data. > Different from some other protocols. > And another: flow control. Mentioned in the text, but should be a component > because the feature that it implements is meaningful to an application (if > there's no flow control, you may have to take care of it yourself).
Yep, both excellent points. Will add to working -02. Thanks, cheers, Brian > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
