[e2e] TCP fragmentation and reassembly

[Detlef Bosau]

Joe Touch wrote:
> 
>
> > 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.


I think we are splitting hairs here %-)

For me, it was helpful to read once more, that MSS is set amongst others
by the receiver side.
I forgot about it - but obviously, there is a necessity to do so and
when I think about it, I believe to remember
TCP options for MSS negotiation. Is this correct?

However: 

To my understanding, the packet size of outgoing packts is limited. And
there are several limiting factors:
-the MTU, i.e. the maximum packet size an outgoing interface can handle,
-the Path MTU (if known), i.e. the maximum packet size the _path_ can
handle
-the receiver´s MSS, i.e. the maximum segment size a receiver can
handle.

Whether a receiver´s MSS is limited by the IP layer, it´s network
interface card, the receiving TCP socket or the light of the moon does
not really matter.
The receiver asks politely not to exceed a certain MSS and the sender is
polite and will not do so :-)

> 
> 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.

And this perfectly makes sense to me.

> 
> > 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


..and the receiver´s advertised MSS is only _one_ of the upper limits
for the MSS to be used, right?

> 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.

Hm. I think we should be careful to use "powerful" knobs for each and
anything and get lost in what we use for which purpse.

To my understanding the proper way to avoid fragmentation is path MTU
detection. Although there may be systems around which do not
implement it properly, it´s the proper way to go because a receiver will
hardly know the path MTU. In contrast to that a sender can and will.

And IIRC in IPv6 the path MTU detection mechanism is compulsory and no
transparant fragmentation will take place at any routers.
However, please correct me if I´m wrong, I didn´t look up it in the RFCs
in the moment.

Detlef 

> 
> -----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-----

-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937