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 [EMAIL PROTECTED] >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >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 >[email protected] >http://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
