Subject: alternative PMTU

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 21 Mar 1999 22:18:50 -0800

Hi,

I'm sure somebody's thought of this before, but I can't figure out why
it wouldn't have worked.

Suppose that instead of doing this complex probe operation that we have
today, we just send datagrams with fragmentation allowed. Then, if
fragmentation does occur somewhere, the recipient responds with a TCP
option that states "fragmentation occurred: fragment size is X"

This would let the sender immediately drop the MSS down to the reported
size, and we wouldn't have any of this crap that we have to go through
today for PMTU (ICMP probs, etc.).

The only issue I can see here is that the sender may transmit lots of
too-big segments, and on a lossy network the resulting fragmentation
could cause all data to get lost. However, slow start would seem to
prevent this from happening. In that case, the same strategies used
today would still work (scale down until successful).

The other issue would be coordinating between TCP and IP, so that IP
could tell TCP when fragmentation had in fact occurred (based on the
header bits). I suppose one alternative to this would be for IP to send
this option/message if it gets data for TCP where fragmentation has
occurred.

The upsides to using an option is that it gets to ride for free on the
ACKs, it will get ignored if the original sender doesn't understand it,
and it won't be blocked by firewalls.

Thoughts?

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 22 Mar 1999 04:32:12 -0800

> Am I missing something here. The ICMP reply optionally gives you the
> mtu size

Sometimes an intermediary will, but the end-point never does. Also, it
can take multiple efforts to find the "true" end-to-end mtu.

---

From: [email-masked] (Alan Cox)
Date: Mon, 22 Mar 1999 13:17:10 +0000 (GMT)

> and it won't be blocked by firewalls.

Dream on. Quite a few firewall products "clean up" the tcp sessions or
semi-proxy them. Look at both sides of a cisco PIX for example and you'll
see all sorts of magic going on, including some rather out of spec 
fragment handling.

Alan

---

From: [email-masked] (Alan Cox)
Date: Mon, 22 Mar 1999 13:28:53 +0000 (GMT)

> can take multiple efforts to find the "true" end-to-end mtu.

You want the path mtu's passed in the BGP4 routing tables ?

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 22 Mar 1999 10:24:33 -0800

> You want the path mtu's passed in the BGP4 routing tables ?

No, what I'm thinking is that instead of sending a series of recursive
probes through the network (which don't get returned, or which get eaten
by ICMP-hostile devices, or which don't provide any useful info), just
have the end-node return an option that says "hey fragmentation has
occurred and this is the biggest fragment that I got."

It is a lot easier to deal with the one message that is explicit than
trying to deal with many messages of many different flavors that don't
necessarily tell you anything even when they do succeed (the current
design of using DF and hoping for informative errors).

One downside to the one-shot model is that the remote end-point HAS to
support the option if it is going to be relied upon. Otherwise you'd
just keep sending fragmentable data and never get a response saying "got
frags."