[e2e] TCP fragmentation and reassembly

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



David Borman wrote:
> 
> On Dec 7, 2005, at 2:22 PM, Joe Touch wrote:
> 
>>> The TCP MSS value specifies the largest size of packet that the
>>> receiver can reassemble.  I doubt that there are many, if any, TCP
>>> implementations that can't handle receiving a full 64K TCP/IP packet
>>> (as a series of IP fragments).
>>
>> See: http://www.psc.edu/networking/projects/tcptune/
>>
>> The table (grep for "FreeBSD") shows that current OS's start with a
>> default socket size smaller than 64KB (which limits the size of the
>> receive window, right?).
> 
> Yes, but that has nothing to do with the MSS value.  The MSS is  simply
> the largest IP packet that the host can reassemble.

According to RFC793, MSS is the max TCP segment the receiver can handle
- - not just the largest IP packet that can be reassembled (though this
could be presumed as a prerequisite). If the connection can only handle
8KB outstanding, even if IP can handle a packet that large, TCP cannot,
so it seems inappropriate to ever advertise an MSS > max_recv_window,
which is bounded by the socket size.

>>> But since most TCP implementations  try
>>> very hard to not send packets that will be fragmented at the IP   layer,
>>> as long as the MSS is larger than the underlying MTU it  doesn't  really
>>> matter.  In theory, when using Path MTU discovery,  there is no  reason
>>> to not always use the maximum MSS value of 64K-1.
>>
>>
>> Most systems don't try anything larger than the outgoing interface  MSS,
>> though, which is often much smaller (1500 bytes (ethernet), 4400 bytes
>> (POS), or 9KB (ATM)).
> 
> The received MSS value is only one of several variables that will  limit
> the size of packets that get sent.  While common, basing the  MSS on the
> MTU of the outgoing interface breaks down in the case of  asymetric
> routing, when the MTU of the incoming interface is larger  than the MTU
> of the outgoing interface.

The outgoing segment size is limited by the min of the received MSS, the
outgoing interface MTU, and the override value in the routing table - at
least that's how it's implemented in BSD.

(I was assuming 'bounded by' the outgoing interface MTU, not just
assuming the outgoing interface MTU -sorry about using MSS in that
context. However, I'm confused by the counterexample - the case where
the incoming interface MTU is larger than the outgoing is where you
_need_ to look at the outgoing interface, to avoid using the other
side's declared MSS and causing fragmentation for your end).

> For this reason, some  systems use an MSS
> that is based on the maximum MTU of all  interfaces, rather than the
> outgoing interface.

The advertised MSS can be that large, but it presumes that all
interfaces are capable of receiving and reassembling IP packets equally
well, which is not the case where reassembly happens on the NIC. The
advertised MSS sbould be bounded by the incoming interface MTU of this
connection.

> But the MSS is also a powerful knob that can be used to force remote 
> systems to send smaller packets when they aren't smart enough to send 
> packets that are small enough to not get fragmented along the way.  
> Fundamentally, it is this reason why most hosts don't just use an MSS 
> of 64K-1.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDl4TAE5f5cImnZrsRAnSCAKCBWOANWpfuIuYHs/weNfPvMWEEGgCgww05
kyC6AYAcADgFTSiuSmlF3BA=
=Abyi
-----END PGP SIGNATURE-----