RE: A question on RPR's service policy

The only way to control dx1/dt, dx2/dt versus d(x1+x2)/dt is to have a
virtual or physical queue per x at ingress, all transit nodes as well as the
egress port. CBQ by definition can not separate the flows and a flow
approaching its peak rate will cause second flow to fall below its committed
rate (unless network is provisioned for the peak rate). 

The other approach is Virtual WFQ at each congestion point and a closed loop
flow control. This requires per flow queues at the ingress/egress of each
node, but a queue-less transit. With this approach only committed rate
provisioning is required for the network. In other words Sigma(CIR) can
approach link Capacity C, while sigma(PIR) >> C.

Regards,

Nader

-----Original Message-----
From: raj sharma [mailto:[email protected]]
Sent: Monday, March 03, 2003 10:41 PM
To: Anthem ChenMin; Anoop Ghanwani
Cc: [email protected]
Subject: Re: [IPORPR] A question on RPR's service policy


So, as I embellish the response of my esteemed 
and learned colleague,
I may come across as purist or even a fundamentalist
of Class Based QOS (CBQOS).

CBQOS systems expect a deterministic per-hop
behavior. This is fundamental to the principle of
classifying traffic to aggregate classes and 
fixing a deterministic behavior of each class 
through network nodes. If this principle is violated
CBQOS is of minimal value - perhaps relegated to a 
marketing slide!

In a class based system it is accepted if transit
traffic is given a higher egress scheduling priority
than the *same* class of traffic added at that node.
But, a lower class traffic allowed to transit first
than a higher priority traffic waiting to enter
creates
a *quota system* in a class based system.
To be explicit, a single transit queue RPR node 
*always* give transit traffic the highest priority
regardless of the class.
Calling this class based QOS is speculative at best. 
IMHO, the single transit queue design in RPR is a
dead duck ! You can use is as a decoy but it has 
very little value beyond that:) It somehow comes
across as *cheap* due to low transit path buffering
requirements.

While, a single transit queue acts like a *dumb
repeater* the dual transit queue design is not very 
noble either when you consider the IEEE 802 shackles
it
has around. This shackle is that: in IEEE 802 networks

it is a taboo (usually associated with religions
we talk about at an arm's length)to loose packets
between the transmit side of one MAC and the receive
side of another. Consequentially, in 802.17, one
cannot loose packets while they are in *transit*.
The result is that imminent packet loss throws 
class based scheduling out of the door to meet this
new *congressional* mandate. So, Best Effort
traffic (which interne t considers to be discardable)
is not in RPR) impacts the behavior of Express 
Forwarded (EF) traffic.
If BE traffic as an impact on EF and one calls it
CBQOS - this makes me dyslexic;(

Bottom line, your fluid will have turbulance
in it when it goes through implementations that
either have a one or two transit queues.
Now, the landscape is much different when the number
of
classes and the number of transit queues is the same!!

What is your opinion of:
Either making RPR having one or two classes
or making RPR having any number of classes.
One class of service is like thick net- 10 Mbps
Ethernet- either you can go or you cannot.
Or,
2 class of service - either you have
have confirmed tickets or your on standby.
Is it palatable for a multi-hop standby passenger 
to blow way confirmed seat holders at transit points?

raj


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


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
_______________________________________________
IPORPR mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/iporpr