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
