RE: [RPRWG] rate control and policing
Anil,
See my comments below.
> 1) RPR document section 5.7.3.1, says that
> HP,MP,LP will have tokens and if tokens
> expire, then RPR MAC will generate STOP_HI,
> STOP_LO, STOP_MED signals accordingly.
> But if the Client choses to disregard the
> feedback from RPR MAC on service availability,
> then RPR MAC may not schedule the client until
> the token bucket has token in it.
> But, I am not seeing such thing being taken
> into account in the flowchart on page no.48,
> section 6.2.2 for High priority transmit traffic.
In the flow chart, the questions in the diamond
boxes, inquiring if xP packet is available?, is after
the policing function. This was clarified during today's
comment-resolution session. Hence, if everything is within
provisioned limits (enforced by the policers) the unconditional
denial of priority to HP and yielding to LP traffic when LPTB
is almost full is where the problem lies.
The real decision before us is: Should the low priority traffic
suffer some packet loss to continue serving HP consistently with
the same priority. Or, to have a loss less ring jeopardize HP
traffic. To loose or not-to-loose packets is the question.
BTW, as the wording stands in the current draft the ring
could be lossy for low priority.
> 2)In section 8.2.5, the definition of IOP bit
> says that for excess Medium traffic, IOP bit
> is set,indicating out of profile traffic.
> But, in flowchart on page no.48, this bit
> is always set whenever MP transmit traffic is
> sent.
>
> Please clarify on this.
See my comment on the reflector before. This has been
addressed in the comments.
raj