Hi, >-----Original Message----- >From: Michael Welzl [mailto:[email protected]] >Sent: Tuesday, March 17, 2015 11:09 AM >To: Karen Elisabeth Egede Nielsen >Cc: [email protected] >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt > >Hi, > > >> On 16 Mar 2015, at 23:54, Karen Elisabeth Egede Nielsen ><[email protected]> wrote: >> >> HI, >> >> Please accept the following "minor" comments/questions to the TCP >> protocol >> components: >> >> #1: >> The list include both of the followings: >> >> *ordered delivery for each byte stream >> * stream-oriented delivery in a single stream >> >> Wouldn't it be more fair to combine these two and say: >> >> *ordered delivery in a single stream >> >> "Each stream" seems a little too much for TCP, I think. >> >> #2: >> Segmentation and bundling is listed as separate components, even if >> bundling, for TCP, is part of the segmentation process. >> I suppose that is as it should be, but when speaking "Bundling" then I >> actually think that "Bundling delay" is a better term. Especially for TCP. >> >> To put in context: >> For SCTP it is actually relevant to discuss bundling and bundling >> delay separately as two different components. >> Meaning that SCTP WILL bundle PDUs up to PMTU size (and I would call >> that bundling), but it CAN (depending on no_delay setting) implement >> bundling delay or not. > >So how does bundling without delaying work? > [Karen ] If there are multiple messages available for transmittal in the SND buffer. E.g., 2 messages of 600 bytes would be bundled into the same SCTP packet. This of course is only in situations where there has been congestion or receiver window blocking.
For TCP this "bundling" of data bytes is part of the basic segment partitioning of the data byte stream. BR, Karen >Cheers, >Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
