> On 17 Mar 2015, at 12:26, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > 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.
Ok, thanks... yes this is indeed different from "Nagle'ing"... Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
