> On 20. des. 2014, at 09.24, Michael Tuexen <[email protected]> wrote: > > On 19 Dec 2014, at 23:08, Michael Welzl <[email protected] > <mailto:[email protected]>> wrote: > >> >>> 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. > I guess the 1460 are related to the IP and TCP header.
Silly me, yes of course I was thinking of TCP while actually talking about SCTP :) > 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. Ah, ok. I wasn’t aware of that. Is that decision up to the application? >> 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. I like Brian’s proposal of unqualified “data bundling” - it is just a bit more meaningful than “Nagle” (despite the historic relevance of the latter). Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
