Francis Dupont wrote:
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.
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.
=> 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).
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?
=> 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
Francis(_dot_)Dupont(_at_)enst-bretagne(_dot_)fr
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