On 19 Dec 2014, at 23:08, Michael Welzl <mich...@ifi.uio.no> wrote: > >> On 20. des. 2014, at 01.13, Brian Trammell <i...@trammell.ch> wrote: >> >> hi Michael, >> >>> On 19 Dec 2014, at 10:29, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>> >>>> On 19. des. 2014, at 20.05, Brian Trammell <i...@trammell.ch> wrote: >>>> >>>> >>>>> On 18 Dec 2014, at 22:37, Michael Welzl <mich...@ifi.uio.no> 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. I guess the 1460 are related to the IP and TCP header. For SCTP it would be 20 bytes for IPv4 header, 12 bytes for the SCTP common header, 16 bytes for the DATA chunk header, 450 byte payload 16 bytes for the DATA chunk header, 450 byte payload 16 bytes for the DATA chunk header, 450 byte payload This gives 1430 bytes. So 70 bytes are left. The SCTP implementation can just leave them unused or, and that is the point I want to make, add 16 bytes for the DATA chunk header 54 bytes (the initial 54 bytes of the fourth 450 bytes user message) Then the frame is completely used. > 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 ? I wouldn't object against using the term Nagle also for SCTP. It refers to delaying the initial sending of user message in case of outstanding data. Bundling in SCTP might happen even when Nagle is turned off, for example when you retransmit messages.
Best regards Michael > > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
