RE: [RPRWG] More comments on preemption
William,
Actually we are concerned about jitter. We even presented some results
during the January meeting (Gal Mor), you can see in the slides the general
assumptions made.
Further simulations that we did indicate that for 128 nodes rings operating
at 1G with jumbo frames, the added delay caused by the jitter absorption
buffer is bounded to 6 msec. For 10G rings it is bounded to 1 msec. It is
not ignorable, but it is still low. Note that the ring tested was 128 nodes,
I believe that jitter and delay sensitive services will be provided over
rings with much less nodes (SONET limits the number of nodes to 20).
You could argue that for lower rates the impact will be more significant, I
agree, but again I don't think that jitter and delay sensitive services will
be provided in low rate rings with many nodes.
Leon
-----Original Message-----
From: William Dai [mailto:wdai@xxxxxxxxxxxx]
Sent: Wednesday, April 18, 2001 11:03 PM
To: stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] More comments on preemption
For those who only concern about current market reality,
please ignore the following. Otherwise, please read on.
During the preemption discussion, the most dominating
factor people use againt preemption is that "under high
speed condition, the worst case delay increase due to
Jumbo frame is ignorable".
However, does anybody concern about JITTER and the
size requirement of the anti-jitter buffer at the receiving
end terminal of the RPR (although the anti-jiiter buffer may
not be required on the RPR node). For those who care,
let me remind you the fact that the size of the anti-jitter
buffer will increase along with JITTER, which results in
further more delay. By looking at the percentage of increase,
I'm not sure whether the word "ignorable" can be easily used
here.
One more point, I'm a cut-through advocate, not just for the
gain on the delay factor, but mainly for the gain on the jitter
factor. But for those cut-through advocates who are STRONGLY
against preemption, I would ask the question: How can we
justify the sacrifice of the hop-by-hop error checking capability
in favor of "ignorable" gains on the delay and jitter by supporting
the cut-through capability?
Best Regards
William Dai