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

[Robin Whittle <rw@firstpr.com.au>]

Hi again Iljitsch,

I hope others can join this discussion.

I think that ITRs and ETRs are going to be ubiquitous.  I can't see
how IPv6 (or any other imaginable replacement for IPv4) is going to
be widely enough adopted in the next decade or two to make ordinary
users happy without a public or "behind NAT" IPv4 address.  I think
an ITR-ETR scheme is the only way of handling increased numbers of
multihomed networks, and increased address utilization, without
causing a meltdown in the BGP routing system.

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

Clearly we can't have a major, systemic, increase in PMTU black-holes.

I hope some other folks can comment on your statement that PMTUD is
broken on way too many current hosts:

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

I assume you mean that the host doesn't respond to RFC 1191 "Packet
Too Big" (actually "Datagram Too Big") messages by resending the
message in smaller packets according to the Next-Hop MTU value in
that message.  I assume you are not referring to filters which block
these messages, either in the network of the sending host or in the
network nearer the destination host.

If these messages are dropped by filters in the sending host's
network, or anywhere between the sending host and the nearest ITR
(perhaps outside that network's ISP) then there is something wrong
with the filtering system and I think it should be fixed.

If host sending behaviour is genuinely broken in a generalised
manner, then then Fred's Sprite and my IPTM proposals would be
useless or close to it.

But if there are only occasional applications or operating systems
which don't do RFC 1191 PMTUD correctly, then wouldn't they have
trouble today, unless their default MTU was set somewhat below 1500?
 If there are just a few of these "broken hosts", I think it would
be better to weed them out than to pursue the only other apparent
alternatives:

1 - Insist on a radical upgrade to (in general) gigabit Ethernet
    gear in most networks (any network which connects to the Net) -
    in order that they can run ITRs.

2 - "Only" insist on a gigabit upgrade to all ISPs who want to run
    ITRs (we are intending they all do it pretty soon) and then
    generally accept that ITRs have to be in ISP networks and not
    in parts of end-user networks which don't have gigabit links
    to the ISP.

I suppose there is the prospect of re-engineering 100Mbps gear to
have a higher MTU, but I guess that means new silicon, with very
little profit from higher prices - so I assume this is not much of
an option.  Also, so many things have their Ethernet interface built
in, that there would need to be complete upgrades to many servers
and devices, not "just" plugging in faster or jumboframe-compatible
Ethernet cards into routers.

What about routers themselves?  Wouldn't the frame size be a
fundamental design decision?  In that case, I think you are
advocating a tremendous equipment upgrade everywhere, before the
ITR-ETR scheme (without Sprite or IPTM) could create benefits for
anyone.

If so, this would violate the requirements of incremental
deployment.  Sprite or IPTM should be able to meet those
requirements, by not requiring any massive hardware upgrades in ISP
and end-user networks all over the world.


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

OK - I will check it out.

On Jumboframes:

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

Yes!

  - 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