Subject: IPv6 MTU issues in FTTH applications

From: [email-masked]
Date: Fri, 22 Feb 2002 09:51:57 -0500 (EST)

I am trying to convince myself that the IEEE 802.3ah working group
working on FTTH should not consider a proposal to increase the MTU
size of Ethernet beyond 1500 bytes.  There is a strong likelyhood
that 802.3ah may require a redesign of SerDes chipsets, so why not
view this as an opportunity to recommend a physical layer design for
FTTH which is optimized for the likely use of IPv6.  It will not do too
much good if the protocol stack is more busy doing addressing than
actually transporting application data due to the inability of the
underlying layer to bear a decent MTU size.

I am also listing the various approaches to transmit an FTTH IPv6
packet (e.g. H.263 video + G.726 audio over RTP, over UDP, over IPv4
over IPSecV6 over IPv6 with multiple source routing headers {up to 23 ipv6
addresses} and authentication), over multiple Ethernet frames without
using IPv6 packet fragmentation mechanisms.

Would it be possible for example to develop a new protocol number at the
Ethernet layer which would identify that two Ethernet frames that are back
to back, originating from the same MAC address, are to be considered glued
together across local links, by the destination IPv6 stack?

-=Francois=-

---

From: [email-masked]
Date: Fri, 22 Feb 2002 14:53:08 -0500

> using IPv6 packet fragmentation mechanisms.

Ouch.  My head hurts.  What MTU would you need to make this work? ;)

> together across local links, by the destination IPv6 stack?

Hmm.. There's probably security implications of using this to "tack
onto" an ethernet frame by just dropping a frame with a spoofed MAC
address - since the "second" frame would (presumably) not have an IP
or TCP header, you could use this to inject into an existing connection
without even having to know what the port or TCP sequence numbers were.
Even IPSec doesn't help here, since this can still be used as a denial
of service to arbitrarily disrupt a connection.

How many people are actually using the existing jumbogram support on
gigaE networks? As far as I can tell, a lot aren't, because you still
end up having to do PMTU-D when leaving your local subnet, and we know
how incredibly well THAT works out in the field (my favorite breakages
are sites that filter all ICMP, and access providers that number their
point-to-points out of RFC1918 space so their 'Frag Needed' packets
get tossed by our border router's martian filters)....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Feb 2002 12:39:21 -0800

> using IPv6 packet fragmentation mechanisms.

It is always possible to construct insane header sets for a packet
stream, but that doesn't mean we should be modifying lower layer designs
based on those. In the example here in particular, putting voice over
large packets is intuitively the wrong thing to do, and making those
frames larger than 1500 simply makes the problem worse. I am not arguing
that chip designers shouldn't be thinking about expanding the link MTU,
just that any examples use something realistic as a basis. Try the fact
that filling a 10GE 300ms path for file transfer would take 250k 1500
byte frames, resulting in a packet rate around 750k pps. If those frames
were 9k bytes the packet rate would drop closer to 125k pps. Building a
home router that can handle the lower packet rate would seem to be
cheaper than trying to build the fast one.

> together across local links, by the destination IPv6 stack?

A spectacularly bad idea, but even if you wanted to do this it would be
a link layer process that handled it, not the IPv6 stack.

Tony

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Feb 2002 14:46:33 +0100

In your previous mail you wrote:

   I am trying to convince myself that the IEEE 802.3ah working group
   working on FTTH should not consider a proposal to increase the MTU
   size of Ethernet beyond 1500 bytes.

=> usually larger frames are better than the opposite: if IEEE 802.3ah
WG on FTTH (fiber to the home?) considers to decrease the MTU below
1500 octest then we shall be really in trouble.

=> fragmentation is the enemy... But as 99.9...% Internet has a MTU
of 1500 octets the worst thing that could happen is the bigger MTU
remains mostly unused (as 9K frames in GigaEthernet).

=> I've seen one day someone using multi-link PPPoE (RFC 1990 & 2516)
for this purpose... BTW this is not so stupid because multi-link PPP
is near the only standardized generic fragmentation/reassembly for
a link-layer, and it is already available nearly everywhere.

Regards

[email-masked]

---

From: bad bob <[email-masked]>
Date: Sat, 23 Feb 2002 10:00:01 -0500

> [email-masked]
I feel obliged to comment here, I apologize if this has been 
covered and I missed it.

Unless my old brain is really failing me, MTU setting was 
determined by our experience with a number of things:
bit error rates, congestion, and technologies/compatibility.
Bit Error Rate (BER) of the medium we were using to pass the
traffic - we had a mix of ten base, running thru bridges, routers
and other devices that were sometimes connected by POTS (plain old
telephone service) lines over 2xx style modems, by satellite
connecitons that varied in effective BER, and just plain slow
gear.
Congestion on the LAN - don't forget ether is still CSMA,
and switches were rather rare.
Technologies/compatibilty - we all had budget constraints and could
not throw out gear that was functioning until we went thru the next 
set of budget cycles. We also could not start with a blank sheet
of paper.

I think the BER issue is about nil now, with some exceptions of course,
the technologies, links, and installations are pretty clean.
I think the congestion issue is going to come and go as we load up
the installations and saturate the gear.
I think the compatibility issue is the driver here. As long as there is
some way to phase in new gear to take advantage of the standard, without
breaking what is there now, MTU size could be increased to something
that
makes sense for the applications.  With streaming media, application
sharing,
VoIP, and all the emerging apps, there is a need to increase the
efficiency
of the protocols.  The larger the payload, assuming apps can take
advantage
of it, the more efficient the protocol (simplistically and generally
speaking).
vr
bob

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 22 Feb 2002 20:23:17 -0500

On Friday, February 22, 2002, at 09:51 , [email-masked] wrote:

> FTTH which is optimized for the likely use of IPv6.

Actually, nearly all GigE vendors (both switch vendors and many
common NIC chipsets) were long since herded into supporting a
9180 byte MTU for IP/GigE, despite the conflict with existing
IEEE standards.  9810 byte MTU is the de facto convention
for Ethernet jumbo frames, though it violates IEEE standards
to support more than 1500 bytes (and larger won't work over
CSMA/CD links anyway).

I doubt that many chipsets would require redesign.

Ran
[email-masked]

---

From: Francois Menard <[email-masked]>
Date: Sat, 23 Feb 2002 10:26:05 -0500 (Eastern Standard Time)

> of it, the more efficient the protocol (simplistically and generally

That was my point, with the IEEE looking at a brand new generation of
hardware for fiber to the home applications, if re-consideration of
increasing MTU to something wich would be more optimal for an IPv6 FTTH
world do not happen over the coming weeks, we'll be missing a great
opportunity.  There are no budge cycles here, no hubs to worry about, no
intermediate routers that could not support the higher MTU.

What we have here is a community of FTTH users with brand new gear doing
peer to peer applications like high quality video conferencing.  I'm
trying to validate if the IPv6 routing header could be a good way
to perform constraint-based routing without requiring the use of MPLS to
perform this.

-=Francois=-