[e2e] Since we're already learning TCP fundamentals...
David P. Reed
dpreed at reed.com
Mon Mar 13 04:52:28 PST 2006
And in fact a TCP source may use different segmentation in a
retransmission from the segmentation it used in the original
segmentation. This has advantages, too, for example when using TCP to
send typed characters one at a time. There were those who advocated
record-based counting, flow control, and error control in the original
TCP design group, but the reason Bob states is one of several arguments
against that (e.g., what if a record is bigger than the maximum segment
In general the TCP designers tended to avoid putting into the protocol
anything that was argued solely because it would be "useful to most
applications". This is one of the many places where end-to-end
arguments were clearly uttered (though it's important to note that
Saltzer, Clark and myself didn't describe and name the category of such
arguments until a couple of years later, when we recognized the pattern
Bob Braden wrote:
> You are confusing a segment with a record. You meant to ask,
> why doesn't TCP count records? (A segment is just another
> name for a TCP packet; the sender is free to packetize any way it
> pleases, so the count of segments has no significance.)
> One simple answer to counting records is: because
> if you count records, the protocol has to negotiate record sizes.
> That is an extra mechanism.
> Bob Braden
> At 10:32 PM 3/10/2006 +0100, Michael Welzl wrote:
>> ... here's a stupid question:
>> Why does TCP count bytes and not segments?
>> Bytestream semantics, I know - but what's the benefit? TCP is
>> not supposed to receive half a segment AFAIK, and counting
>> segments = less space, or less risk of wrapping.
>> There must have been a reason for this design choice.
>> I expected to find an explanation in RFC 793, but I couldn't
>> find anything - might have overlooked it though...
More information about the end2end-interest