Variation in Delay (jitter) may be an important motivation
to bound the size of the MTU on FTTH. If one wishes to
do voice (or other delay critical service) across this link,
then one cannot use large playback buffers to mask jitter.
A data under-run caused by a delay excursion would then result
Stephen M. Bellovin wrote:
>If you're doing
>uncompressed voice (compression makes this effect worse), a 1500 byte
>packet holds 214 ms of voice at the (U.S.) standard rate of 56K bps.
>That's already beyond the delay budget, just for that one hop,
On the other hand, that's assuming POTS-grad
> 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
On Friday, February 22, 2002, at 09:51 , [EMAIL PROTECTED] 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. There is a strong likelyhood
> that 802.3ah may req
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 t
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 (
In message <[EMAIL PROTECTED]>, "Tony Hain" writes
:
>n 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.
It's not just intuitive, it's quantitative. If you're doing
FTTH = Fiber to the home...
> then you'll be
> increasing the size
> of the last-hop MTU without increasing the MTUs on
> intermediate hops, so
> you won't gain much. Might be more important to preserve the
> 1500 byte
The reason to increase the MTU anywhere in the network must originate
fr
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
On Fri, 22 Feb 2002 09:51:57 EST, [EMAIL PROTECTED] said:
> 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 authe
> over multiple Ethernet frames without
> using IPv6 packet fragmentation mechanisms.
One thing to remember is that IPv6 routers don't do fragmentation
(RFC-2460, section 4.5). If FTTH (sorry, I don't recognize the acronym)
gets used mostly as a LAN technology, then you'll be increasing the si
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
12 matches
Mail list logo
