[e2e] Since we're already learning TCP fundamentals...
craig at aland.bbn.com
Fri Mar 10 15:07:17 PST 2006
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
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
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...
More information about the end2end-interest