hi Michael, > On 19 Dec 2014, at 10: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.
So I'd argue that (1) this isn't *exactly* the same thing, as the interface to SOCK_SEQPACKET has application PDU preservation as an explicit part of the API contract, while SOCK_STREAM does not, but (2) that at the protocol level it might as well be, so "bundling" is exactly the right word. How about "sender segment bundling" for TCP? Thanks, cheers, Brian _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
