Hi Mark,
It's clear that we're thinking from two very different starting
points. You want to make a few very small changes to the current way
of using jumboframes, all the while accepting all the current
limitations that make that virtually nobody uses them.
What I want to do is remove the limitations so jumboframe capability
will be used whenever it's available.
On 26-jul-2005, at 15:06, Mark Smith wrote:
There are probably a few RA announced-style MTU values that need to be
distributed around :
(a) the original MTU that is currently in RAs - the "whole of link"
one.
This is the MTU that all nodes on the link must be capable of
receiving,
as it will be used as the maximum size for multicasts.
Right. We leave this one alone.
(b) the "link maximum jumbo" ie. the absolute largest MTU that the
layer
2 infrastructure can support.
Yes.
(I think I've read that some Intel GigE NICs can support 16K
jumbos).
I was once testing switches from a vendor we hadn't used before, and
I complained that they didn't support jumboframes. A few days later
the rep came by again with a card that supported 64000 byte frames. :-)
This value would be configured on the routers making RA
announcements after the layer 2 infrastructure has been had jumbo
frame
capability enabled.
Yes, except that it would be even better to have _switches_ announce
this value since they're the ones that know it, which means a new
message type.
- validation that jumboframes indeed work to minimize the impact of
misconfiguration
Once your layer 2 infrastructure is known to support a specific jumbo
frame size, I don't think it is all that necessary to check for it
anymore.
People can hook up extra layer 1 or layer 2 devices to your jumbo-
capable switch. It's nice if that doesn't bring down the network.
The overheads of checking for it all the time may be too high
when compared to how often unauthorised standard MTU or unconfigured
switches are plugged in to the network.
One extra packet in each direction whenever an ND exchange takes
place doesn't seem excessive, especially on gigabit ethernet.
Remember that we routinely encrypt untold terabytes of data on the
off-chance that someone may look at it some time.
Autoconf is the word, is the word that you heard. It's got groove,
it's got meaning. Autoconf is the time, is the place is the
motion. Autoconf is the way we are feeling.
The problem is going too far with the goal of PnP, and then ending
up with
monsterously complex solutions that attempt to address every possible
scenario, including the most esoteric onces, rather than just the
common ones
(ie. common operational scenarios, common failure scenarios).
"There is no way anyone will be using this software by the year 2000
anyway..."
All of this really isn't very complex. All that's needed is:
Simple switches:
- periodically multicast a packet with fixed content
Routers and managed switches:
- accept a user configured value for each interface and multicast an
IPv6 packet containing that value
Jumboframe capable hosts and routers:
- listen for a new type of message to learn link jumbo MTU
- whenever such a message is received, see if it's lower or equal to
the current stored value, update timestamp
- remove stored jumbo MTU for an interface when it's not refreshed in
the last N seconds
- update IPv6 MTU for interface based on learned jumbo MTU / local
maximum
- put current IPv6 MTU in neighbor advertisements/solicitations
- when receiving neighbor advertisement/solicitation containing jumbo
MTU option, send test packet at mimimum of local/remote jumbo MTU
- when receiving test packet, update IPv6 MTU for neighbor
- when NUD is triggered, update IPv6 MTU for neighbor to regular IPv6
link MTU
This is a very simple implementation that doesn't handle lost packets
and optimizing for the largest possible jumboframe size, but it
should work well enough.
Don't get me wrong, I'd like this solution to be developed. I'm just
wondering how hard it might be to develop, and if there is simpler
interrim "sub-solution" that would still be useful to a fair number of
people, namely those who don't expect to just "plug-and-play" when
they
want to use non-standard protocol parameters and feature, such as
jumbo
frames.
Once a fully fledged "cope with any MTU" solution exists, then
manufacturers of NICs and switches could enable jumbo frames by
default.
No, this is exactly the wrong thing to do. The overhead of making ANY
change is so huge that it's really not worth it unless you get it
right. Also, there often isn't a second chance. Getting things right
the first time in actual deployment is very important.
Iljitsch
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
