On Sat, 23 Jul 2005 14:16:46 -0500
"Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> Thus spake "Mark Smith" <[EMAIL PROTECTED]>
> > On Fri, 22 Jul 2005 13:20:40 -0500
> > "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> >> The hole is that there may be an L2 device in the middle which has
> >> a lower MTU than the end hosts. The neighbor MTU is an upper
> >> bound, but it's not guaranteed to work -- you need to probe to see
> >> what really works.
> >
> > I agree that probing would be nice to have, however I don't think not
> > having it is a "black" hole.
> >
> > When a larger than standard MTU is used (e.g., 9K jumbos over
> > GigE verses the 802.3 standard of 1500), the operator has made a
> > conscious decision to increase the MTU, and therefore needs to
> > take responsibility for ensuring that intermediary layer 2 devices
> > support the increased MTU. People who want use jumbo frames
> > on GigE interfaces know usually that they have to also have
> > jumbo frame capable switches..
>
> Except we nearly have this situation today -- jumbos only work if the admin
> goes through a lot of painstaking effort to make sure they do. You're
> proposing we eliminate the per-host effort but not the network-side effort;
> to me that's a half-solution (as you granted in a section I snipped). I
> want jumbos to work out of the box without the admin (which might be my
> grandmother at home) even knowing what jumbos are.
>
Remember that the per-host effort is where a lot of the effort is -
there are just so many more of them than there are layer 2
infrastructure devices.
I'd like "ultimate plug-and-play" for this scenario, however, for quite
valid reasons, that problem is either quite hard or even impossible to
solve.
The fundamentaly issue I think I'm really addressing is that even if the
administrator goes to the effort of ensuring that the layer 2
intermediary devices support jumbo frames, IPv6 currently prevents you
taking advantage of it for the hosts that support it, the moment you
plug in one legacy device that doesn't.
For example, you may have a few hundred hosts that support jumbo frames,
and layer 2 switching infrastructure that also supports jumbo frames.
You then want to plug in an older 10 or 100Mbps network attach printer
(that has been software upgraded to support IPv6) that doesn't. That
printer hobles all the hosts to using 1500 byte frames for IPv6. Sure,
you can fix that by buying or building a 2 interface router that
supports jumbo ethernet frames on at least one interface, and then
plugging the printer into the other interface, creating a different
MTU'd segment. Thats a fairly $$$$ or time intensive solution. I'd think
modifying IPv6 to support this scenario (again, assuming layer 2
infrastructure supports the largest MTU/MRU) would be very much
appreciated by people who design a network like this and are then faced
with the idea of having to buy/build a router just to support an
existing, legacy printer.
"Legacy" printers could with any other "legacy hardware" device that has
been software upgraded to support IPv6, e.g. router, host, scientific
equipment etc.
> > If we make the assumption that the intermediary link layer devices
> > support the largest node MTU/MRU on the segment, I think the
> > problem becomes a lot simpler, and then the issues to solve are :
> >
> > (a) how to ensure large MTU/MRU capable end nodes use them
> > when communicating between each other.
> >
> > (b) how to ensure end-nodes with smaller MTU/MRUs are not sent
> > too large frames by the large MTU/MRU capable end-nodes.
> >
> > I think either of these issues could be solved by using a ND NS/NA
> > MRU type option, and, because RAs can carry a link-layer address,
> > negating the need for a node to perform a ND NS/NA transaction
> > with the router, at least initially, have an RA also possibly carry
> > an MRU indication.
>
> The RA's MRU would make a good upper bound, but you still need to probe to
> make sure a host you're talking to isn't sitting behind some $30 hub that
> silently drops jumbos (er, giants). And you have to keep probing in case
> the host moves or the L1/L2 path changes, unless you've recently received
> from that host a jumbo or ACK for your own jumbo.
>
If you've gone to the effort of consciously building a jumbo capable
infrastructure, and then chosen to use it, and then somebody else
('cause it won't be you) plugs in a $30 hub, then
(a) you can repremand them
(b) be sure that the problem will be localised to the devices on the
other side of the hub, if they try to plug jumbo capable devices in
behind it, and attempt to use jumbo frames. The existing, properly
supported jumbo capable devices plugged into the proper jumbo capable
layer 2 infrastructure would continue to work properly. If they plug in
jumbo frame capable devices behind the hub (forgetting for the moment
that hubs don't come in GigE flavour), but don't enable jumbo frames on
the end-nodes, things will work as normal.
Again, remember that my suggestion solution is _constrained_ to
scenarios where the layer 2 infrastructure has been specifically
designed to support jumbo frames, and a conscious effort has been made
to enable them. My solution has the fundamental goal of allowing
small-MTU, "legacy" end-nodes (e.g., printers, routers, etc.) to be
plugged into the same layer 2 infrastructure without those legacy
devices hobbling the MTU/MRUs the jumbo capable devices support.
I think this scenario is or will be quite common in the future. I'd
suggest that buying GigE layer 2 switching without looking at its
features, capabilities and specifications, is only limited to the
residential, SOHO and maybe small business market. IOW, any scenario
where the network is actually designed may benefit from this MTU/MRU
discovery solution for unicast traffic. Those networks are present in
medium to large businesses, and service providers, and I think there
will be lots of "_designed_ to support jumbo" frame networks in the
future.
> The reason I think this is necessary is that it allows hosts supporting
> jumbos to have them on by default and gracefully fall back to non-jumbo
> sizes in the presence of non-jumbo-aware hosts or network devices. You can
> only have them on by default if you're sure you can handle the most perverse
> case (which I think I presented).
>
> > For multicast, the link standard MTU or the link RA announced MTU
> > would be used.
>
> I'm not sure using an MTU above 1500 for multicast should be legal; there
> may be hosts on the subnet which we don't know are neighbors and thus we
> don't know the lowest MRU out there. Also, aren't there cases where we'll
> know of a neighbor but wouldn't have had to do ND and thus wouldn't have
> learned their MRU?
>
They wouldn't be legal, as the multicast scenario is exactly why RFC2461
says the MTU has to be of a fixed size for the segment. However, once we
apply this constraint only to multicast traffic, we then may be able to
allowing differing MTU/MRUs for unicast traffic between hosts on the
same link (of course, again, assuming that the layer 2 infrastructure
supports the largest MTU/MRU).
> > For nodes that don't implement this "MRU" option, they'll use the link
> > standard MTU to communicate with their neighbours and vice-versa,
> > as per IPv6 operation today.
>
> Of course.
>
> And, since I know this is the IPv6 WG list, which WG would be appropriate to
> discuss back-porting this feature into IPv4 after we solve it for IPv6?
>
We choose not to back-port (it may not be possible anyway as I don't
think ARP is extensible like IPv6 ND is), and that will then provide
another reason to migrate to IPv6 ... :-)
Back-porting nice features from IPv6 to IPv4 is possibly false economy.
It takes extra effort (even though it may be a small amount), which
instead could be used to further improve IPv6, and also provides
additional disincentives to adopt IPv6. In some ways it reminds me of
the effort that is spent overcoming NAT limitations, rather than more
usefully either improving the application by adding features, or porting
the application to IPv6 and avoiding then avoiding NAT issues
completely.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
