[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transmech MTU comments
Your message was a cop-out, Pekka. Please address the question:
Do we, or do we not want to allow for the possibility of
future L2 bridges, switches, hubs etc. that connect media
with dissimilar MTUs but that don't get involved with
L3 functions like IPv4 fragmentation and sending
"packet too big" ICMPs?
Let's look at a real-world example of where our failure to
support such L2 devices is currently hurting us. Look at the
interface MTU for your 802.11 card under your favorite host
OS (e.g., Microsoft, Linux, etc.) and you will see that it says
1500 Bytes. Next, go to the IEEE specs and you will see that
802.11 frames can support a body of 2312 bytes.
So, why can't we set the MTU of our 802.11 interfaces to
2312 and take immediate advantage of the 35% gain in
efficiency? Because there might be an 802.11/Ethernet
L2 bridge somewhere on the path and IPv4 path MTU
discovery would break!
The current IPv4 path MTU discovery scheme is limiting
potential growth and precluding legitimate solution alternatives.
While we can't fix it all in one fell swoop, we can start making
informed decisions (e.g., non-assumption of IPv4 fragmentation,
support for packetization-layer path MTU discovery that does
not require ICMPs, etc.) that will eventually bring about healing
and new growth opportunities.
Fred
ftemplin@iprg.nokia.com
Pekka Savola wrote:
Hi,
On Thu, 20 Nov 2003, Fred Templin wrote:
Should we have as a goal the ability to support L2 bridges, switches,
hubs, etc. that join media with dissimilar MTUs, but do not support
IPv4 fragmentation and do not send "packet too big" ICMPs?
We answered "NO" to this 15 years ago when we allowed the
approach now specified in RFC 1191 to go forward, and that
decision took a viable design alternative off the table which had
a profound effect on the shaping of the industry.
We're not going to fix this overnight by anything we do here, but
allowing for generality (i.e., not expecting any IPv4 fragmentation
support along the forwarding path) would be an important step
toward restoring a level playing field. Let's not blow it again,
given new opportunities to get things right.
Fred, I appreciate your concern about creating a robust and optimal
Path MTU Discovery mechanism, but IMHO this document -- which we're
moving towards DS -- just simply doesn't seem to be the right time and
place to do so.
There is little we can do to fix IPv4 at this point; IPv6 already
doesn't include fragmentation support along the path, and might be
enhanceable, in future, to support new methods. We'll need to live
with what we have.