[e2e] TCP fragmentation and reassembly

[Joe Touch]

David Borman wrote:
> 
> On Dec 7, 2005, at 6:56 PM, Joe Touch wrote:
> 
>> 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.
> 
> No.  The receive window has no influence on the MSS value.  Look at RFC
> 1122.  The value to use in the MSS option is to be less than or equal to
> MMS_R - 20, where MMS_R is "the maximum message size that can be
> received and reassembled in an IP datagram" (RFC 1122, pg 57). 

1122 only says:

	The MSS value to be sent in an MSS option must be less than
      	or equal to:

               MMS_R - 20

(i.e., it doesn't require 'equal to') I'm suggesting that an
_additional_ requirement is that TCP be able to support the reassembled
payload. There's nothing in 1122 that precludes that, and 793 implies it.

> When you
> actually go to send a packet, the received MSS value is only one of
> several things that can limit the packet size.
> 
> ...
>>> 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.
> 
> Provided you know for sure which is the incoming interface.  You can
> always know what interface you are using to send packets, but in many
> multi-homed situations you can't guarantee on which interface the
> traffic will arrive.

You know which ones were used; it might be sufficient to use the lower
bound of the incoming interfaces that were actually used as a limit
(lower bound of all interfaces if you haven't received anything).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051208/47d39240/signature.bin