On Mon, 17 Aug 1998, Vern Paxson wrote:
>
> > 2. Is there any evidence that Path MTU discovery is more beneficial than
> > raising the default MSS for nonlocal destinations? It seems to me that if the
> > network is able to handle fragmentation without bad things happening
> > (particularly congestion-related loss of fragments), the satellite TCP
> > connection would be better off not allowing the MTU to be negotiated downward.
>
> I'm confused by this - can you elaborate? It sounds like you're either
> saying just hardwire in a big MTU and fragment if need be (but that runs
> into the usual problems of fragment loss amplifying the amount of data lost),
> or to hardwire it reasonably large but not super large (Ethernet size)
> because the gain beyond that isn't so much. I wouldn't buy either of these
> interpretations without more elaboration ...
>
> Vern
I meant the first interpretation. My question was whether, in a long RTT
environment, the degradation due to occasional fragment loss was more than
offset by the benefit of having a big MTU for growth of cwnd. I've since
noticed that sending out large MTUs without knowledge that the
path can support them falls under the "should not" category of RFC 1122, so
I'm not advocating this approach even if it were beneficial.
On a similar note, Stevens points out (Stevens vol. 1) that Path MTU discovery
is overridden if the peer does not return a MSS (or returns a MSS of 536 for
all nonlocal destinations). Is this still a problem with Path MTU discovery
in practice? If so, Sec. 3.1 of the draft probably needs to be revised.
>From RFC 1191:
A TCP implementation must also store the MSS value received from its
peer (which defaults to 536), and not send any segment larger than
this MSS, regardless of the PMTU. In 4.xBSD-derived implementations,
this requires adding an additional field to the TCP state record.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:46 EST