Subject: [IPORPR] A question on RPR's service policy

From: "Anthem ChenMin" <[email-masked]>
Date: Sun, 23 Feb 2003 21:25:19 -0500

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

---

From: "Anthem ChenMin" <[email-masked]>
Date: Mon, 24 Feb 2003 00:35:01 -0500

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-masked]>
To: "'Anthem ChenMin '" <[email-masked]>
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-masked]
> 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
> 
_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr