Re: [Int-area] Multi-MTU subnet draft

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Iljitsch,

Apologies on being slow to coming around to reading this.
Still have to read further, but one question for now: is
this useful for router-to-router, or is it only used for
host-to-router (and maybe also host-to-host). For that
matter, perhaps the definition of what is meant by "host"
and "router" is somewhat soft?

Thanks - Fred
fred.l.templin at boeing.com  

>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] 
>Sent: Sunday, February 24, 2008 7:26 AM
>To: Internet Area
>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
>Int-area at ietf.org
>http://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area