> 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). Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
