[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] MTU, jumboframes, ITR & ETR placement, ITR function in hosts
Hi Iljitsch,
Responding to what you wrote in:
PMTUD, Sprite & IPTM; Outer src-addr = sending host's addr
http://psg.com/lists/rrg/2007/msg00599.html
and changing the subject line again . . .
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 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.
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.
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. I think we
need to have great flexibility in where ETRs are located, so I can't
imagine it being practical to assume all ETRs have an MTU above 1500.
Also, I think there are many benefits in having a caching ITR in the
sending host, as I discuss below.
Some messages on the RAM list concerning this are:
http://www1.ietf.org/mail-archive/web/ram/current/msg01733.html
Gert Doering:
As of today, too many links and routers still have issues
handling more than 1500 bytes of IP packets (like "most
FastEthernet interfaces on Cisco routers", which is still
considered "high bandwidth" over here).
> What about routers in end-user networks, or CE routers of
> providers?
Even worse, due to DSL encapsulation you already end up with
an IP MTU of 1492 bytes or less.
http://www1.ietf.org/mail-archive/web/ram/current/msg01847.html
http://www1.ietf.org/mail-archive/web/ram/current/msg01849.html
Iljitsch van Beijnum:
I don't see anyone seriously claiming that ALL ISP networks
support packets larger than 1500 bytes on ALL their internal
links (and also on inter-ISP links).
Believe me when I tell you that this is a minefield. However,
the good thing with a LISP-like solution is that we get to
design everything on all ends (ITR, ETR, mapping) so it's not
too hard to implement fragmentation at the encapsulation layer.
But what about inter-ISP links? I'm assuming this isn't a big
issue for high capacity private peering, but here in Europe a
lot of peering happens over exchanges, which obviously use
equipment that can easily handle larger packets, but so many
people are on a big fat shared subnet that it's a given at
someone will bring down the lowest common denominator to 1500.
http://www1.ietf.org/mail-archive/web/ram/current/msg01854.html
Iljitsch van Beijnum:
I think most people take it {jumboframes} to mean 9000 bytes.
This is the only real jumboframe IP MTU size I've seen
implemented in hosts. However, routers and especially switches
come with many different maximum frame sizes. I've looked over
some product literature and compiled the following list: 1508,
1530, 1536, 1546, 1998, 2000, 2018, 4464, 4470, 8092, 8192,
9000, 9176, 9180, 9216, 17976, 64000 and 65280.
(More interesting stuff on the innards of Ethernet.)
http://www1.ietf.org/mail-archive/web/ram/current/msg01861.html
Gert Doering:
Dino Farinacci wrote:
>> To summarize the issue we are trying to put to rest:
>>
>> o All router-to-router links on the downstream side of
>> an ITR use either 4470 or 9180 byte MTUs.
Where is this assumption coming from? As long as there are
FastE links, this is not going to happen.
http://www1.ietf.org/mail-archive/web/ram/current/msg01862.html
RJ Atkinson:
Btw, at least some 100baseTX/FX switches/routers can
support the 9180 IP MTU. So it is not necessarily
the case that 100baseTX/FX implies a 1518 byte link MTU.
http://www1.ietf.org/mail-archive/web/ram/current/msg01863.html
http://www1.ietf.org/mail-archive/web/ram/current/msg01864.html
http://www1.ietf.org/mail-archive/web/ram/current/msg01865.html
Gert Doering:
In nearly all locations we have devices that still have Fast
Ethernet links (because upgrading to GigE is expensive and the
amount of packets flowing through the link doesn't require it).
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.
So there is no way our network could run on a MTU of 4470 or
even higher any time soon.
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".
RJ Atkinson wrote (in part):
> Are you trying to say that you currently have deployed
> router-to-router links inside an ISP/IX with less than
> 4470 bytes of IP MTU ?
We have no single ethernet link in our network that has a MTU
*above* 1530 (there are some that could be cranked up, but
there was no need yet)
I have a large number of links that have a MTU of *exactly*
1500 (because there is equipment that cannot handle 1530).
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.
So: the answer is "yes".
> Btw, at least some 100baseTX/FX switches/routers can
> support the 9180 IP MTU. So it is not necessarily
> the case that 100baseTX/FX implies a 1518 byte link MTU.
Switches are easy. Routers are not.
What good is having a Jumbo-capable switch if there is one peer
on the shared fabric that can only receive 1500-byte (+
Ethernet header) packets?
Regarding an ITR function in the sending host, this could be a
really good use of free CPU and RAM resources, saving upstream
dedicated ITRs from most of the work. I don't see any special
security problems. Can you point out any specific problems? The
only ITR-ETR scheme which allows for an ITR function in a sending
host is Ivip:
http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-1.7.3
The ITR function in a sending host needs to have fast, efficient,
link to a nearby Query Server - so it would be a bad idea on dialup
or on a link to an ISP which didn't have its own full database Query
Server.
- Robin
--
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