On 20 Dec 2014, at 00:14, Michael Welzl <mich...@ifi.uio.no> wrote: > >> On 20. des. 2014, at 09.24, Michael Tuexen <tue...@fh-muenster.de> wrote: >> >> 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. > > 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? Not via the socket API as it is defined right now. > > >>> 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). OK. Then in both cases the application can't turn it off. Using TCP_NODELAY or SCTP_NODELAY just affects it.
Best regards Michael > > Cheers, > Michael > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
