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
>
> [EMAIL PROTECTED]
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
