On 31-jul-2007, at 16:08, Iljitsch van Beijnum wrote:
So for full end-to-end jumbo use across the internet the additional
mechanisms need to be implemented on all intermediate ethernets (or
jumboframes must be enabled administratively) but with only RFC
4821 you can still have out-of-the-box jumboframe capability for
TCP and maybe some other transports on the local subnet.
Rethinking the type of MTU detection packets: a new mechanism that
must be supported by both sides, or something that can be implemented
by just one side?
For the latter, the question would be: what type of packet is most
appropriate? I see two options:
1. ICMP echo request/reply
2. Oversized ARP and neighbor discovery packets
The advantage of ICMP is that using echo request/reply doesn't
introduce new uses for an existing message, but it has several
downsides:
- replying to large packets with large packets could be abused for
denial of service
- replying with large packets is unnecessary but inherent to ICMP echo
- many software firewalls, some enabled by default, block these messages
I haven't been able to find a description of "jumbo ARP" but I assume
this is simply an ARP request padded to the desired length and sent
as unicast. (Multicasting large packets if it can be avoided is a big
no-no on wifi because multicasts are typically sent at the lowest
supported rate.)
If an answer comes back, the target host is able to receive packets
of the length used when sending. ARP packets are already often padded
to 46 bytes to fill a minimum ethernet frame, so I assume this will
work in many cases. IPv6 ND would work much the same way except that
a padding option would have to be added to increase the packet size.
Some systems may not be prepared to handle ND packets of arbitrary
sizes.
In each case, the test packet would have to be sent shortly after
discovering a neighbor's MAC address using regularly-sized ARP or ND.
Since it is unknown whether the neighbor supports jumboframes at all,
let alone what size, it's probably prudent to test in two stages:
first send a test packet of the minimum usable jumbo size (I'm
thinking 1520 bytes, that would be 1500 + 20 byte IP-in-IP header).
This wastes less time on the wire and is likely to upset old gear to
a lesser degree than a maximum size jumboframe.
If an answer comes back, note the increased MTU and the next try is
with the largest packet size supported locally. If an answer comes
back for that one, again note the larger MTU. If no answer comes
back, do nothing. If the other side supports a smaller maximum size,
then it will probe with that size at some point, and that will be our
cue to try one last time with that size. This way, it's possible to
find out the largest supported MTU between two hosts that both
implement this mechanism without trying a large number of sizes.
However, if only one end supports the mechanism, additional probes
are necessary to discover the maximum supported MTU, or a
conservative maximum must be chosen and the real maximum between two
neighbors is never discovered.
With IPv6 neighbor discovery, we can add an MTU option so that if
both neighbors support the new mechanism, they'll tell the other
their MTU without the need to send multiple large packets. (Also very
useful to signal lack of jumboframe support.) If nodes run both IPv4
and IPv6, this information can be reused for IPv4, and it only has to
be validated by sending a jumbo ARP. In this case, we can probably
get away with trying just 9000 bytes or the local maximum, whichever
is smaller, if no neighbor specific information is known, as few
hosts (but a larger number of switches) implement jumboframes < 9000
bytes.
Unless someone has other insights to offer, I think I'll update my
draft according to the above.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
