[e2e] [Fwd: Re: [pmtud] Re: [dccp] PMTU issues]

[Fred Templin]

  Hi,

I'm forwarding this post from other lists as it seems relevant to
the subject matter of interest to this group.

Fred Templin
ftemplin at iprg.nokia.com

P.S. See one of the other lists for the entire thread that led
    up to this message if interested...

-------- Original Message --------
Subject: Re: [pmtud] Re: [dccp] PMTU issues
Date: Tue, 18 Nov 2003 15:47:52 -0800
From: Fred Templin <ftemplin at IPRG.nokia.com>
To: Eddie Kohler <kohler at icir.org>
CC: dccp at ietf.org, pmtud at ietf.org, ipv6 at ietf.org, v6ops at ops.ietf.org
References: <200311180139.hAI1dJIe059714 at coyote.icir.org>



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
ftemplin at iprg.nokia.com