Re: plpmtud BOF (resent to add the iesg...)

[Sally Floyd <floyd@icir.org>]

>I would recommend that this WG be chartered, since it seems to have  a very
>focussed problem statement and clear idea of goals.

Yep.  Nicely done.

My notes are below, just FYI.  

- Sally

-------------------------------------------------------------------

Unedited notes...

Packetization Layer Path MTU Discovery (PLPMTUD)
 
Path MTU Discovery: Sent a large packet with the Don't Fragment bit set;
router sends back an ICMP message if the packet is too large to be
forwarded.

Problems (RFC 2923):
* ICMP messages are sometimes blocked.
* Broken routers don't send ICMP messages.
* Tunnel endpoints might have problems.
* Weird layer-2 devices bridging networks with different MTUs.
* Broken PPPoE implementations.

draft-mathis-plpmtud-00.txt

Most of the algorithm runs in the transport layer, but state
resides in the IP layer.

Lost probes do not trigger congestion control.
Nearly everything else is heuristic.

Start as extensions to RFCs 1191 and 1981.

Open MTU caching issues:
How to use the IP layer to share state.
IP layer has to account for IPsec, tunnels, etc.
How do multiple connections with different headers interact.

Open robustness issues:
Their goal is to fix all of the robustness corner cases in Path MTU.
* Multipath with differing MTUs.
* Double timeouts?  Persistent double timeouts?
* Heuristics to reduce MTU?

Cases where a too-large MTU hurts you:
* Windows become too small.
* Large MTU causes higher loss rate.

Their real goal is to push up the deployed MTU in the Internet.
Increasing the deployed MTU can increase the loss rate.

What protocol deployments are stalled because of problems with
 MTU discovery?

Who ignores the DF bit?

Why isn't this in tsvwg?  We want a broader audience, ops, lower
layers, etc., and we couldn't get the broader audience in tsvwg.

It will be a big problem if there is any technology out there that
ignores DF.