Subject: Re: [pmtud] Re: [dccp] PMTU issues

From: Fred Templin <[email-masked]>
Date: Tue, 18 Nov 2003 15:47:52 -0800

Eddie,

Your opinion is from the perspective of a modern-day expert
technologist with specific insight into the problem space, and
I have a great deal of respect for that. My opinion brings an
historical perspective that I believe also bears consideration:

I was very close to "ground-zero" when the current RFC-1191
style Path MTU discovery method took shape. In 1988-1990, I
was heading up the team that developed ULTRIX support for
Digital's initial FDDI product offering. The initial offering
included an FDDI wiring concentrator (i.e., a fancy hub), two
host adapters, and an Ethernet-to-FDDI L2 bridge.

This latter product presented the interesting problem of how to
support path MTU discovery in the presence of bridged media
with diverse MTUs. The oft-cited problem case was the "dumbell
configuration" in which two FDDI rings were on either side of
an Ethernet pipe - in this example, how could hosts A and B
on FDDI rings know whether an Ethernet was on the path?

Some interesting alternatives were kicked around, including
marking L2 packet headers with a bit to indicate that an Ethernet
was traversed. But, a vocal minority at that time insisted that the
only way to go was to either have the bridge support IPv4
fragmentation, or have it send "fragmentation needed"
messages when dropping a packet with the DF bit set.

The vocal minority got their way, but the chosen alternatives
disqualified the opportunity to support transparent L2 bridging
between media with diverse MTUs. Some made valiant attempts
to market "brouter" or "transluscent bridge" products, but the
vocal minority was easily able to shoot these down with counter-
marketing and the advent of L3 routing (i.e., "smart networks")
took flight.

Since then, we have seen the boom and subsequent bust of the
Internet revolution. It would be a far stretch to say that this all
came as result of the path MTU discovery decisions, but I do
believe it fair to say that a harmful precedent was set: folks
started to believe they could engineer the network with no
regard for the End-to-End Principle.

So, where does this leave us today? We have an unreliable,
untrustworthy (and, frankly, noisy) network-based mechanism
that only works when forwarding nodes get involved with
inspecting IPv4 packet headers. We'd like to be able to hook
a dumb 9KB MTU Gbps Ethernet hub to a dumb 1500B MTU
10/100 Ethernet hub and enable the larger MTUs, but we can't
because we blew the option out of the water back in the good
old days and we have based so many of our architectural
decisions on that precedent since.

Now, with the emergence of techniques like PLPMTUD, we
have the opportunity for healing by allowing new packetization
layers, APIs, etc to gracefully supplant the old network-based
mechanism. I envision an Internet restored to the End-to-End
Principles, with new opportunities for innovation enabled by
seamless support for L2 media with diverse MTUs.

So, in response to a network that keeps endlessly screaming:

  "Packet Too Big!"
  "Fragment Needed!"

 I say:

  "Turn Off The Noise!"

Fred
[email-masked]   

Eddie Kohler wrote:

>Hi Fred,
>
>* PLPMTUD is useful.
>* Designing PMTUD so that it works in the absence of ICMP feedback seems
>  necessary.
>
>BUT
>
>* Suitable ICMP feedback hints might significantly improve the performance
>  of a transport protocol.
>* We can program our transports to react to ICMP as a hint -- i.e., not
>  trust it, but use it to optimize performance.
>* So ICMP should not be "needed", but it might, and probably would, be quite
>  helpful in some cases.
>* For instance, not all packetization layers have as easy a time as TCP
>  with packet size changes.  The smooth ramp-up suggested in PLPMTUD may
>  require intervention from the application for example.  For good
>  performance, these applications may apply PMTUD in unexpected ways --
>  they might start large, for example.  ICMP feedback would really help
>  them.
>* ICMP is not a significant cause of Internet congestion and need not ever
>  become one (mark it less-than-best-effort).
>
>I still think your overloading of ECN capable as "PLPMTUD capable, don't
>send ICMP" is not necessary, a bad idea, and will not fly.
>
>Eddie
>  
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Tue, 18 Nov 2003 17:29:05 -0800

Eddie Kohler wrote:

>Well, I wouldn't want to be responsible for any further destruction of the
>Internet revolution, but most of this seems besides the point.  Old-style
>PMTUD, which *depended* on the delivery of ICMPs, is a far cry from
>new-style PMTUD, which *can benefit* from the delivery of ICMPs.  The
>problem was the PMTU algorithm, not the idea of ICMPs.  And the network
>isn't full of useless ICMPs.
>

Nonetheless, I believe we should keep options open and investigate
ways to support L2 devices that don't send ICMPs and don't support
IP fragmentation without relegating them to second-class citizens.
PLPMTUD gives us one such tool, but does it *really need* the ICMPs?

We got this wrong on the first iteration some 15 years ago, and if there
is now an opportunity to set things right we should at least give it serious
consideration and make the right informed decisions.

Thanks - Fred
[email-masked]

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 18 Nov 2003 16:50:37 -0800

> believe it fair to say that a harmful precedent was set:  ...

> inspecting IPv4 packet headers.  ...

Eddie