Subject: [tsv-area] Fwd: [Int-area] Multi-MTU subnet draft

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Feb 2008 12:53:35 +0200

This draft is of interest to the Transport Area as well.

Begin forwarded message:

> From: "ext Iljitsch van Beijnum" <[email-masked]>
> Date: February 24, 2008 17:25:43 GMT+02:00
> To: Internet Area <[email-masked]>
> Subject: [Int-area] Multi-MTU subnet draft
>
> Hi,
>
> Here is an update of my multi-MTU subnet draft. Based on the
> discussion in the summer I've pruned the CRC text (although most of
> the points are still there) and I've spent a lot of time coming up
> with a way to make all of this simpler. I think I found a good  
> tradeoff.
>
> The basic idea is that routers advertise three parameters in IPv6
> router advertisements. (These parameters apply equally to IPv4 and
> IPv6 operation, though.) They are:
>
> - An absolute maximum packet size that is allowed on a link. This  
> can be
>   used make sure larger packets aren't used if they're known to have
> bad
>   effects (MAXMTU)
>
> - A maximum packet size for nodes operating at 10 or 100 Mbps (the
> cutoff
>   is 600 Mbps) in case these are connected to switches that don't
> support
>   jumboframes or it's undesirable that slow nodes send large packets
> for
>   QoS reasons (SLOWMTU)
>
> - A packet size cutoff for not probing / probing for a jumbo-clean  
> path
>   (SAFEMTU)
>
> The neighbor discovery options and jumbo ARP for communicating per-
> neighbor MTUs and probing whether large packets work are still there,
> but they are optional. Hosts may use RFC 4821 as a probing mechanism
> instead. (Although this means that some transport protocols can use
> larger packets and others can't and routers can't use RFC 4821.)
>
> Alternatively, nodes may forego probing altogether if they stick to a
> maximum packet size of SAFEMTU. The disadvantage of this is that
> SAFEMTU must be set administratively because only the administrator
> can know what a safe MTU is in the absense of probing. But the good
> part is that it is compatible with current manually configured jumbo
> frame use.
>
> There needs to be a bit more text about operational issues (or maybe
> those should go in an applicability document), and I'm not sure yet if
> I want to keep the CRC discussion even though it's a lot shorter now.
> Depending on the discussion on the list and in Philadelphia I want to
> see if this can be published as experimental.
>
> Begin forwarded message:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>
>> 	Title           : Extensions for Multi-MTU Subnets
>> 	Author(s)       : I. van Beijnum
>> 	Filename        : draft-van-beijnum-multi-mtu-02.txt
>> 	Pages           : 17
>> 	Date            : 2008-02-24
>
>> In the early days of the internet, many different link types with
>> many different maximum packet sizes were in use.  For point-to-point
>> or point-to-multipoint links, there are still some other link types
>> (PPP, ATM, Packet over SONET), but shared subnets are now almost
>> exclusively implemented as ethernets.  Even though the relevant
>> standards mandate a 1500 byte maximum packet size for ethernet, more
>> and more ethernet equipment is capable of handling packets bigger
>> than 1500 bytes.  However, since this capability isn't standardized,
>> it's seldom used today, despite the potential performance benefits of
>> using larger packets.  This document specifies a mechanism for
>> advertising a non-standard maximum packet size on a subnet.  It also
>> specifies optional mechanisms to negotiate per-neighbor maximum
>> packet sizes so that nodes on a shared subnet may use the maximum
>> mutually supported packet size between them without being limited by
>> nodes with smaller maximum sizes on the same subnet.
>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-van-beijnum-multi- 
>> mtu-02.txt
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/int-area