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

[Agarwal, Anil]

We can envision TCP offering a byte-stream service to applications (no
user segment boundaries), as it does now, but internally use segments
(appropriately sized, with PMTUD) and segment numbers. If PMTU changes
in the middle of a connection, then rely on IP fragmentation/reassembly
or some new procedure.

That can lead to a substantial CPU performance boost and code
simplification for TCP and TCP buffer management, especially with SACK
and PAWS. Would that be worth something?

Perhaps, there are historical reasons why TCP was designed to use byte
numbers - telnet over 2.4 kbps links, aggregation, 2^32 seemed like a
very large number, etc.

Regards,
Anil

-----Original Message-----
From: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] 
Sent: Friday, March 10, 2006 6:07 PM
To: Michael Welzl
Cc: End to End
Subject: Re: [e2e] Since we're already learning TCP fundamentals...


Maintaining segment boundaries is a performance challenge.

You cannot trust applications to pick segment boundaries (size that is
right for application may be too small [see Nagle algorithm] or too big
[see Mogul/Kent on why fragmentation is bad]).

If you let TCP pick segment boundaries, what happens if TCP picks wrong
(MTU changes? -- see previous paragraph) or needs to retransmit
(aggregating
segments into one big packet is a win..., but aggregation is an complex
mechanism...)

Craig

PS: You're right that segments make some mechanisms a lot simpler (if
you
want to take a peek, I can send you a UNIX RDP implementation from c.
1989 --
very clean).  But the semantics of segments is lousy for performance and
flexibility.


In message <000501c6448a$17cdd9a0$0200a8c0 at fun>, "Michael Welzl" writes:

>... 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