[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] MTU, jumboframes, ITR & ETR placement, ITR function in hosts

On 24 nov 2007, at 3:58, Robin Whittle wrote:


I would be delighted if you can show me it is practical to insist
that ITRs and ETRs be installed only in places with significantly
greater than 1500 byte MTU to the rest of the Net.  As far as I
know, it is impractical, due to the widespread use of 100Mbps links
in many places.
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. 


The quotes below from the RAM discussion on this, especially those
from Gert Doering, seem to indicate that at present, there is
sufficiently widespread use of 100Mbps Fast Ethernet, to drag down
the MTU of many Internet exchange networks to 1500.
Obviously smaller ISPs will have 100 Mbps links in some places. The real question is: do the *TRs need to be behind those 100 Mbps links, or can they be placed in a more central part of the network where the requirement of a 1500+ byte MTU can reasonably be met?
You seem to want *TRs pretty much everywhere. Although I think there are security issues with that, I don't reject having them even in end- user networks out of hand, but that doesn't mean I accept the lowest common denominator in those networks. If they want to run an encapsulation/decapsulation device, they'll just have to upgrade their network to support the MTU that makes this possible. 


I don't discount what you are saying.  Maybe by the time an ITR-ETR
scheme is introduced, it will be practical to insist on a minimum
standard well above 1500.  I hope some other people can contribute
to this discussion.
I don't expect the situation in this area to change significantly. Today, pretty much all 100 Mbps or slower stuff doesn't support jumboframes, while pretty much all 1000 Mbps or faster stuff does. (Sometimes this even goes for the 10/100 and 1000 ports on the same switch.) Expensive 100 Mbps equipment doesn't exist anymore, so I don't see a push for larger MTUs there. 


However, while it would be possible to configure an ITR in some way
to tell it that it has a >>1500 byte MTU to the "core of the Net",
this doesn't help much, since it can't know for sure that every ETR
it needs to send packets to has a similarly high MTU.


This could be learned through the mapping service.


Also, I think there are many benefits in having a caching ITR in the
sending host, as I discuss below.
In that case there are no problems, because obviously it's allowed to send packets smaller than the minimum maximum and PMTUD black holes aren't possible here because everything happens on the source host. 


    While we don't run 1500 on links where MPLS is used, most Cisco
    gear in use cannot go over 1520...1530 on FastEthernet ports.
    This limits the GigE machines to 1530 as well, as things really
    break (today) if you share a layer2 segment between machines
    with different MTUs.


Yeah, someone should do something about that. Oh wait:

http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-01.txt


    At the DECIX, currently the 3rd biggest exchange in Europe,
    about one third of the members (all sharing a common L2
    network!) are still connected with 100 Mbit/s.



    Which means "1500 for all of them".


Yes, this is an issue.


    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.
I'm pretty sure if LISP or something like it is deployed by the big guys in the US (which do all their interconnecting through private links AFAIK) the Europeans who use internet exchanges will spit and curse but make the necessary changes to the exchange setups after that. The alternative is endless handholding of customers with PMTUD problems rather than a one-time infrastructure change. 


--
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