Jonathan> PMTU is also useful if you have an Ethernet subnet at
    Jonathan> home, with a SLIP or PPP connection configured to a low
    Jonathan> MTU (256 bytes) for latency reasons.

>  I, for one do. However, since prior to PMTU, you were supposed to
>assume an MTU of 576 for non-local TCP connections, it doesn't affect
>me. It affects people that have their PPP MTU set to a higher value.


I think it's the same issue as Floyd and Romanov address in their
paper examining loss of ATM cells comprising TCP packets, and (IIRC)
Jeff Mogul's classic "fragmentation considered harmful" paper.

If a connection uses the historic nonlocal MTU while the actual PMTU
is signficantly lower, then any loss of fragments over the low-MTU
link (ppp or otherwise) causes retransmission of entire TCP packets,
which then get fragmented over the PPP link, and may get lost, etc..
You have to get a whole TCP packet across the PPP link and reassemble
it before you make any progress.  You might successfully send enough
fragments of a TCP successfuly across the link and still get zero
goodput if line noise takes out one fragment from each copy.

This causes pain not just for sessions across a low-MTU lossy link but
for the rest of the net. If there's *any* congestion elsewhere this
just makes things worse.

Using the real path MTU is  just Better.


This gets worse when (as CGD observed privately) if you have multiple
subnets at home. Yah, some people have 100Mbit ethernet or FDDI or old
T3 (cards used as a highspeed LAN) at home.