Thus spake "Mark Smith" <[EMAIL PROTECTED]>
On Tue, 26 Jul 2005 13:05:31 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
You mean: if I hook up two hosts that support 9k jumboframes to a
cheap unmanaged 10/100 switch (all out of the box) and it doesn't
work, I have to go in and reconfigure the hosts so it does work?
Sorry, but that's not acceptable.
I think that is an uncommon scenario. How many hosts with jumbo
frame capable interfaces come with jumbo frame capablility _enabled
by default_ ?
They can't today according to the existing RFC. What we're proposing is a
solution that works in any environment with zero configuration so that
jumbos _can_ be enabled by default.
The complex "cope with any MTU on any device"
solution is really trying to address what I think would currently be the
worst case scenario. I don't think that scenario will be all that
common, at least in the short to medium term because :
(a) devices that are jumbo frame capable don't come with them enabled
by default
(b) people who enable jumbo frames usually know what they're doing and
what is required for them to work ie. a layer 2 infrastructure that will
support them.
Neither of these statements (and the snipped discussion that follows) fit
the model some of us are targeting, i.e. Joe Sixpack plugging a bunch of
stuff together at home. IMHO, he should get the benefit of jumbos when
possible even if he has no clue what "IP" means, much less "jumbo frames".
And, I hate to point it out, but even many "professional" admins out there
fall into the Joe Sixpack category.
What we need in addition to this would be (as outlined in my
message to Bob):
- a mechanism to distribute the MTU for the layer 2 network to
jumbo-capable systems
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. Not really
necessary for ethernets as this value would normally be 1500 bytes,
although there are some uses for ethernets if all offlink destinations
are via a link with a slightly smaller MTU e.g., and IPsec tunnel, to
avoid a PMTUD cycle. The other reason to specifically set it is to cope
with layer 2 technologies such as token ring which don't have a
standardised MTU.
I think I'd name this "link multicast MTU" or "link minimum MTU" and I'd
default it to 1280 on all media types unless a larger value was advertised
(remember, there may not be a router on all networks, and many routers won't
implement jumbos at all).
(b) the "link maximum jumbo" ie. the absolute largest MTU that the
layer 2 infrastructure can support. Nodes that can support jumbo
frames can raise their MTU up to either the maximum MTU they
support above the standard value that is less than this value (eg 7k if
they don't support 9K jumbos (they exist, even in fast ethernet. My
Netgear Fa312s under Linux support MTUs of 2024 bytes !)) or set
their MTU to this value, which may actually be smaller than the
jumbo size they're capable of supporting (I think I've read that some
Intel GigE NICs can support 16K jumbos). This value would be
configured on the routers making RA announcements after the layer
2 infrastructure has been had jumbo frame capability enabled.
I'd call this "link maximum MTU", which would be used to constrain the upper
bound of the MTU search space. The upper bound might also be constrained by
a host with a lower hardware MTU. In the case where there's no router
sending such an advertisement, the upper bound would equal the host's
hardware MTU.
Note that in all cases, a host's MRU should always be the maximum that the
hardware supports. It's only the mcast and per-neighbor MTUs that are
lower. "Be liberal in what you accept" and all that.
- 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. 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.
Methinks you overestimate (a) the number of cases where the "admin" knows
the MTU, and (b) the odds that what they "know" is correct, either
immediately or after a couple years of maintenance.
I don't think a probing scenario is avoidable, unfortunately. If people
make one small mistake and the hosts don't detect and work around it, the
network fails; people will learn that jumbos "don't work" and rarely use
them. And, if you start with the assumption you need to probe, the solution
becomes more obvious and the problems you can solve become more interesting
and compelling.
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.
And at least some of us appear to be trying to solve the larger problem now
instead of addressing it in two stages as you propose. I don't like the
idea of half-solutions because it delays getting to the real goal, and the
interim step seems just as bad if not worse than the status quo.
> Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin
> in draft-templin-ipvlx-02.txt.
I don't really see how those apply.
Only because from what I remember of Matt's draft, and what Fred
said about his, they perform some sort of MTU discovery without
relying on a feedback mechanism e.g. ICMP Dest Unreachable,
Packet Too Big, which I think you solution would have to deal with,
assuming that there wasn't a requirement to add protocols to the
switches.
Any solution which requires an upgrade of all the L1/L2 devices in a path
will fail in the majority (IMHO) of cases. Let's stick to smart edges and
dumb networks.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
