> On 20. des. 2014, at 01.13, Brian Trammell <[email protected]> wrote: > > 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,
Ahh… let me see if I get this right: your point is, in terms of the actual function, the difference is: SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a 1460-byte segment and get shipped together after an RTT, wasting space for 110 bytes. TCP: app gives the same app PDUs into the send buffer, where they are treated as a byte stream and a segment of 1460 bytes can be exactly filled. If that’s it, then I agree, that’s functionally different. > 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? Ok by me, but we'll have to be careful later: when trying to unify access to these services across protocols, the two different names for SCTP and TCP may make it seem like they are entirely different in functionality when in fact they are not much different indeed: TCP’s Nagle operates on single bytes, SCTP’s app PDU bundling operates on potentially larger blocks of a given size? What about: “data bundling (1 byte)”, as opposed to “data bundling (application PDU)” for SCTP ? Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
