A further suggestion: the performance of jumbo ARP/padded ND can be improved if the router is configured in advance with the likely MTU sizes on the subnet. For the most common case, with one supported jumbo size plus the standard, this approach only requires one extra directed ARP/ND per peer (assuming that long term caching is ok).
This in not unreasonable, give that all >1500 Ethernet solutions requires at least some minimal configuration on each device. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Tue, 31 Jul 2007, Iljitsch van Beijnum wrote: > 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 > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
