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

[Craig Partridge]

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