[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] MTU, jumboframes, ITR & ETR placement, ITR function in hosts
On 25 nov 2007, at 15:08, Robin Whittle wrote:
Hi again Iljitsch!
:-)
I'm not responding to your previous message because the way I see it,
all those issues are sidestepped by simply mandating a minimum MTU of
1500 in the *TR system.
The practicality of that insistance isn't derived from wide
availability of 1500+ byte MTUs in provider networks (although
Dino claims this isn't an issue based on a survey he did) but
rather from the trouble we can expect to see if we reduce the MTU
of links across the core of the internet to below 1500 bytes.
This sounds like an argument between the immovable object and the
irresistible force.
Only if you assume that the requirement to have an MTU that will
accommodate 1500 byte inner packets + encapsulation is equal to moving
an immovable object or resisting an irresistable force.
You later contemplate extending this to those end-user networks
which contain ITRs. In practice, as the ITR-ETR scheme becomes
ubiquitous, this would be virtually all end-user networks.
Is it important for ITRs to become ubiquitous?
Is this more important than avoiding the situation where path MTU
blackholes become very common? Like it or not, the de facto MTU of the
internet is 1500 bytes. Go below that at your peril.
The correspondence I quoted, from people who know much more about
this than me, convinced me that your desirable idea of upgrading to
MTU >> 1500 is not practical.
Depends on what exactly you want to upgrade. I fully agree this is a
problem for people behind a DSL line using a sub $100 CPE. But I don't
consider that an issue.
Perhaps it can be done, but I want ITRs and ETRs to be placed pretty
much everywhere
If you want people with an MTU of 1500 to encapsulate, you have two
choices:
1. Run PTMUD
2. Fragment
Unfortunately, you can't really do both at the same time unless your
router keeps track of who it sent "too big" messages to recently. And
I'm saying choice #1 isn't an option because of broken PMTUD behavior
in way too many hosts connected to the internet. So that means
fragmenting EVERY 1500-byte packet in the encapsulators and
reassembling them in the decapsulators. That's an ongoing cost, while
upgrading the mid-level potential runners of *TRs is a one-time cost.
I'm not sure what you feel are the advantages of people below that
level running *TRs as well (those are the people that aren't
multihomed themselves) so please explain.
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-
mtu-01.txt
Sorry, I didn't look in detail at this, because it seems to be only
for IPv6.
No, that was version 00. There is support for IPv4 using jumbo ARPs in
version 00 but it's less robust than IPv6 because IPv4 doesn't have
any neighbor discovery.
All exchange points that we're connected to run the fabric at
1500 byte MTU, because they have members that have equipment
that cannot handle more. There are *some* IXPs that have two
different LANs, one with 1500 and one with "Jumbo", but that's
not very widespread yet.
That's because there is little value in configuring a larger MTU
today because in 99% of all paths through the internet there is
at least one 1500-byte ethernet hop, so you're pretty much never
going to see actual data packets flowing between end-users that
are bigger than 1500 bytes.
This sounds familiar . . . everyone (or almost everyone) has to do
an expensive upgrade before anyone derives any benefit.
That is (somewhat) true for wide scale adoption of jumboframes on the
internet. Supporting jumboframes on an exchange pretty much means that
you have to split the existing peering LAN into two new ones: one for
1500-byte packets and one for a larger size. This isn't a huge deal
but it is of course somewhat annoying. (My draft wants to address this
by allowing hosts with different maximum packet sizes on the same
subnet.)
If some administrative arrangements could be used to cause all
relevant gear to be upgraded to gigabit Ethernet, I would be
delighted to forget about IPTM. However, I think that would be a
cause of further delay for deploying Ivip - or whatever ITR-ETR
scheme is chosen - and/or for seriously restricting where ITRs and
ETRs could be located.
I think our respective positions are clear, I'd be interested to learn
what others think.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg