[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