[e2e] TCP fragmentation and reassembly
touch at ISI.EDU
Thu Dec 8 11:11:58 PST 2005
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
> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051208/47d39240/signature.bin
More information about the end2end-interest