[e2e] Since we're already learning TCP fundamentals...
Fred Baker
fred at cisco.com
Fri Mar 10 14:10:19 PST 2006
oh my goodness. this was a long debate...
Let's say that there is no "right" way to do it - one could count
octets or bits or segments and it would work. In 1980, there were a
number of transports that in fact counted segments - XNS SPP, DECNET,
Apple, ISO, and so on. When the proponents of one or another was
asked about the claims of the other, they would generally note that
an API could be built using their version that simulated the other.
And they were correct; RFC 1006 describes a way to run the ISO
transport over TCP, and there are several API implementations that
run streams over packet-based transports.
When I implemented the XNS SPP for CDC (seriously many moons ago),
there was one problem that I encountered in which counting packets
(which the Sequenced Packet Protocol called them) worked against me.
That was when the network sent an error message indicating that I had
sent a sent a packet that was too large (IDP doesn't fragment). In
that case, I might well have sent subsequent packets, and I therefore
didn't have the option of resending the packet as several sequential
smaller packets. I had to close the connection and restart. I didn't
have that problem with TCP; I could simply send several smaller
segments. See PMTU. I would also note that the reverse is true; if
the Nagle option is implemented and the one outstanding segment is
lost and therefore needs to be retransmitted, and if I happen to have
more data than I originally sent, I can actually send new data in the
retransmitted segment if I like.
On Mar 10, 2006, at 1:32 PM, 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
More information about the end2end-interest
mailing list