[e2e] TCP fragmentation and reassembly

[David Borman]

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.

>> 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.  For this reason, some  
systems use an MSS that is based on the maximum MTU of all  
interfaces, rather than the outgoing interface.

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.

			-David Borman