[EFM] On the Worship of Speed
Link Speed is my shepherd, I shall not be in want.
It makes me lie down in small buffers, It leads me beside quiet networks,
It restores my cache. It guides me in paths of QoS for his name's sake.
Even though I walk through the valley of the Loss of Packets, I will fear
no Jitter, for Speed is with me; your MAC and your PHY, they comfort me.
Psalm 23, King Geoff Version :-)
In PON, the emulated point to point speed is configurable.
It could be as small as 1 Mb/s. At such speeds, large packet
induced jitter is indeed a problem. Consider a 1500 Byte
packet. It will take 12 ms to deliver over a 1 Mb/s link.
That will be an issue for TDM services.
From: carlosal@xxxxxxxxxxxxxxxxxx [mailto:carlosal@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, January 23, 2002 8:45 PM
To: Chou, Joey
Cc: Geoff Thompson; bob.barrett@xxxxxxxxxxxxxxx; mattsquire@xxxxxxx;
Subject: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
trouble shoot ing.
As you said:
> I thought there should be a need for an OAM requirement to support
> 802.1D user_priority bits to prevent voice packets from blocking
> by huge Ethernet data packets.
Assuming that the typical speed of the EFM link is going to be very high,
this blocking effect is not really an issue, as it can be solved with good
queue management. That's an implementation issue. For low speed links, this
is a serious problem, because it takes a long time to transmit a big frame.
The Frame Relay Forum took specific measures to avoid this situation; for
examplo, big frames may be fragmented before transmission. It's better to
avoid fragmentation, though, as it's a complex implementation that presents
its own set of issues to be solved.
That said, it's important to state that this is not enough to solve all
issues related to the support of TDM emulation services over EFM. Speed is
good, and may help a lot by avoiding the need for complex mechanisms such
as fragmentation, but there are other issues to watch out, specially in the
case of the P2MP implementation.