[EFM] Re: On the Worship of Speed
> Psalm 23, King Geoff Version :-)
It's nice to know that someone still have some sense of humour :-)
> 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.
There are some problems with your argument. First of all, a delay of 12ms
is tolerable; what really matters is the delay variability. If you can keep
the latency bounded in a small range, even slightly bigger values are not
really an issue.
You also assume that the 1 Mb/s is the line rate, which isn't. The line
rate is 1 Gbps for the PON. So the 1500 bytes frame will be transmitted in
12 microseconds. What happens is that the ONU will have to wait some time
to get another timeslot. The actual time depends on the implementation. A
leaky bucket algorithm can be parameterized in such a way to guarantee that
small packets get a chance to be transmitted frequently, which helps to
keep the jitter low.
A similar argument can be shown for slower P2P links, such as copper. If
the transmission rate is higher than the commited rate, it's possible to
implement a traffic shaping/queue management system that can keep the
efficiency high.
All these techniques to not solve the real issue with TDM-over-packet, that
is the behavior under congestion. Many queueing techniques are available
for use in lightly loaded networks that give good TDM performance. As soon
as you get congestion, you have to rely on complex mechanisms to keep the
services running smoothly. Some people (me included) advocate that data
networks should be overdimensioned, because it is less expensive to
increase bandwidth than to control QoS.
So in the end you're right - link speed is my shepherd :-)
Carlos Ribeiro
CTBC Telecom