Francois wrote:
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.
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.
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?
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