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: I was trying to make a much less subtle point from the interface side: since SCTP actually _has_ a concept of application PDU, it can bundle them, while TCP has no such concept, so what it's bundling can't really be PDUs. > 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. sending app gives PDUS 1,2,3,4 via sendto(), receiver calls recvfrom() four times and gets four PDUs. > 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. sending app writes PDUS 1,2,3,4 via write(), receiver gets some bytes from read(), and must either (1) know how large each PDU is in advance or (2) use some framing information in the byte stream to figure this out. > 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 ? "Data bundling" unqualified is just fine by me. Cheers, Brian > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
