Re: A question on RPR's service policy

Thank you very much.And I understand the priority queuing you talked about.
Maybe I need to explain my question this way:
In the single queue, say, the passby low priority queue, there would be different fluid flow that are classified by Source-Destination. In that sense, in the single queue, when the server take different policy, the output of the server will be different. If we analyze it in a Packet Switch way, there would be no problem to regard it as FIFO model, but when we analyze it as a fluid model, is it more convenient to let flows(different sources and destinations) share the server?

More explicitly, for example,
X1 is the low priority flow from 1-->5
X2 is the low priority flow from 2-->4
Then when looking at 3rd node, it is easy to derive d/dt(X1+X2), but what is dX1/dt and dX2/dt? It depends on how the server serve the flow...

Hope to get more idea from you..
Thanks

Best

Anthem
----- Original Message ----- 
From: "Anoop Ghanwani" <[email protected]>
To: "'Anthem ChenMin '" <[email protected]>
Sent: Sunday, February 23, 2003 10:21 PM
Subject: RE: [IPORPR] A question on RPR's service policy


> 
> This question is probably more appropriate for the IEEE 802.17
> list.  See http://www.ieee802.org/17.
> 
> To answer your question, the service discipline at a node
> depends on the transit queue architecture.  It's class-based 
> priority scheduling, rather than either FIFO or GPS.  With 
> a single transit queue, the service discipline at node is:
> 
> - Transit queue
> - Insert Class A
> - Insert Class B
> - Insert Class C
> 
> With dual transit buffer, the priority changes depending 
> on the occupancy of the secondary transit queue.
> (Class A is transported in primary transit queue
> and B and C in secondary transit queue.)
> 
> If secondary transit queue is < STQlowthresh
> 
> - Transit primary
> - Insert Class A
> - Insert Class B
> - Insert Class C
> - Transit secondary
> 
> If secondary transit queue is > STQlowthresh, but < STQFullthresh
> 
> - Transit primary
> - Insert Class A
> - Insert Class B
> - Transit secondary
> - Insert Class C
> (A node doesn't get to insert Class C traffic in this mode.)
> 
> If secondary transit queue = STQfullthresh
> 
> - Transit primary
> - Transit secondary
> - Insert Class A
> - Insert Class B 
> - Insert Class C
> (A node doesn't get to insert any traffic in this mode.)
> 
> I am not 100% sure about the scheduling rules for the 
> 2 transit queue case but the above is what I think it is.
> One thing to note is that once a frame is admitted by the
> MAC, the scheduling discipline at every node guarantees
> that it will not be dropped due to congestion.  Also
> there is no reordering of frames within a class.
> 
> Hope this helps.
> 
> -Anoop
> 
> -----Original Message-----
> From: Anthem ChenMin
> To: [email protected]
> Sent: 2/23/03 6:25 PM
> Subject: [IPORPR] A question on RPR's service policy
> 
> I have a question. If we analyze the RPR in fluid model, what is the
> service policy? FIFO? Or Generalized process sharing?
> If that is FIFO, seems like if there are different class of same
> priority packets, after passing through one node, it would be distorted
> afterwards..
>   Anyone can help me?
> Thanks
>  
> Anthem
>