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 PROTECTED]
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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
