[e2e] Since we're already learning TCP fundamentals...

[David P. Reed]

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 
size?)

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 
as important).
 
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...
>>
>> Cheers,
>> Michael
>
>
>