Re: [RPRWG] More comments on preemption
Correction on my second statement.
Under the same assumption, I forgot that the Jumbo frame
insertion takes 10 times shorter time in 10G than in 1G,
so the jitter does get reduced and so is the anti-jitter buffer
size.
Sorry for the confusion.
William Dai
----- Original Message -----
From: "William Dai" <wdai@xxxxxxxxxxxx>
To: <stds-802-17@xxxxxxxx>
Sent: Thursday, April 19, 2001 12:18 PM
Subject: Re: [RPRWG] More comments on preemption
>
> Leon,
>
> Simulation may or may not catch the worst case situation. There are 128
> nodes in your simulation model, the sheer number of nodes which makes
> it look like the "toughest" you can get. While I believe it is good to
> evaluate
> the delay, but it make the jitter evaluation more difficult. Why ? because
> the
> the probability of getting minimum delay (packet pass through 127 nodes
> without being blocked by Jumbo frame insertion) and the probability of
> getting maximum delay (packet pass through 127 nodes and being blocked
> by Jumbo frame insertion at every node) diminish quickly as the number of
> nodes increases.
>
> Secondly, assume we're comparing a 100Mbps traffic flow going through
> 1G ring vs. 10G ring with the same number of nodes and same traffic
> generation models, AND on the other end of the anti-jitter buffer, traffic
> will be extracted out at 100Mbps for the same flow. In theory, the size
> of the anti-jitter buffer and the delay caused by the anti-buffer should
be
> the SAME. It should not be a surprise because 10G ring is only 10 times
> wider than 1G ring, not 10 times faster for the 100Mbps traffic flow.
>
> I'm not a simulation believer (although I used to be in that field), but I
> do
> respect those people who is doing that. It is just a tool used by PEOPLE.
>
>
> Best regards
>
> William Dai
>
>
> ----- Original Message -----
> From: "Leon Bruckman" <leonb@xxxxxxxxxxxxx>
> To: "'William Dai'" <wdai@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
> Sent: Thursday, April 19, 2001 4:54 AM
> Subject: 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
> >
> >
> >
> >
>
>
>