RE: [RPRWG] Question about B EIR and C priority
Jiang Zhou,
1) You found a bug! Thank you! We'll see if we can get it fixed in the next draft via any comments filed this time.
2) Based on comments I've seen on Draft 2.2, I think that shaperC will either be modified substantially from its current form or will be removed.
jl
-----Original Message-----
From: Jiang zhou [mailto:zjiang@xxxxxxxxxxxxxxxxxxx]
Sent: Saturday, May 17, 2003 12:01 AM
To: John Lemon; RPRWG (E-mail)
Subject: Re: [RPRWG] Question about B eir and C priority(My last mail have wrong text arrange)
Hi,John Lemon:
Thank your indicator. I have only find the difference in the chart and state
machine table. So I have this question.
But in Draft 2.2 I also can't understand the follow points:
1) When to subtract creditD?
When stage queue send a frame it subtract creditA,creditB,creditC
respectively.
But I don't find creditD is subtracted in the whole document.From the define
of
shapeD, it should subtract by all transmit bytes except A0.
When transmit a frame in STQ, does it need subtract creditD?
If so, creditD maybe less zero. Because transimt STQ frame don't check
passD.
2) The rate of shapeC is MAX_ALLOWED_RATE. It provide a burst over a short
time but over long time is allowedRate
The shapeD rate is unreseveredRate. In the Draft there is no define of
MAX_ALLOWED_RATE.
I think using a large hiLimitC to meet the burst for fairness eligible frame
is good chose than large rate.
It is like a single rate with two color shape in RFC2697. Set the burst size
in the second credit bulk or set a
large credit in single credit bulk.
Best Regards
Jiangzhou
zjiang@xxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "John Lemon" <JLemon@xxxxxxxxxxxx>
To: "Jiang zhou" <zjiang@xxxxxxxxxxxxxxxxxxx>; "RPRWG (E-mail)"
<stds-802-17@xxxxxxxx>
Sent: Saturday, May 17, 2003 4:58 AM
Subject: RE: [RPRWG] Question about B eir and C priority(My last mail have
wrong text arrange)
Jiangzhou,
Firstly, note that the flow chart is a simplification to give an overview of
the process. The details are in the state machine. Please read the state
machine to gain more than a cursory understanding of the protocol.
Secondly, note that the stage queue state table was modified for Draft 2.2
to correct a bug that could have allowed classC frames to sometimes gain
priority over classB EIR frames.
Finally, classB (CIR or EIR) always has priority over classC, when they are
allowed to transmit. If classB CIR is limited by its allocated rate, then
sendB will be false. If sendC is true, then any classB frames that are
available can be sent as classB EIR (in other words, classB with fe
(fairness eligible) set to true), with higher priority than classC.
jl
-----Original Message-----
From: Jiang zhou [mailto:zjiang@xxxxxxxxxxxxxxxxxxx]
Sent: Friday, May 16, 2003 3:24 AM
To: RPRWG (E-mail)
Cc: Jiang Zhou
Subject: [RPRWG] Question about B eir and C priority(My last mail have wrong
text arrange)
Hi,all:
I have find something wrong in stage queue flow chart.
The follow is from the Draft 2.1 stage queue flow chart
(START)
|
(CLASSA)
classA entry && sendA ----yes--> select classA frame--->space in stage queue
| &&PHY is ready-->start
|
|
(CLASSB)
classB entry && sendB ----yes-->select classB frame---->space in stage queue
| &&PHY is ready-->start
|
|
(CLASSC)
classC entry && sendC ----yes-->select classC frame---->space in stage queue
| &&PHY is ready-->start
|
|
no frame selected
|
(START)
If the current status:
Both B frame and C frame are in client queue
sendB is false and sendC is 255.
So it will chose C frame to trasmit not the B frame.
Therefore, it violates priority. Because B traffic has high priority than C
traffic.
From my understand, I think that B traffic in CIR profile has high prioriy
than C traffic and both B traffic exceed CIR and C has the same priority,
they share the spare link capcity.
Can some one give a explain about the prioriy of B EIR traffic and C
traffic?
Best Regards
Jiangzhou
zjiang@xxxxxxxxxxxxxxxxxxx