From: asadovnikov (asadovnikov@comcast.net)
Date: Wed Jun 09 2004 - 00:37:23 GMT-3
Not really semantics. Policing is a limiting factor not a priority factor,
although the effect of better service can sometimes be similar, that is why
I have pointed it out. No dual queue structure though, during congestion
the excess is dropped.
The way better service would apply is that for paid-for-calls you can commit
enough bandwidth to carry say 10 calls, then for not-paid-for-calls you can
commit enough for 2 calls. If bandwidth available (unless otherwise
restricted) either class can make whatever number of calls. If congestion
arrives then only committed is delivered. Say both paying and non-paying
had 8 calls active, paid-for calls will sustain the conditions and
non-paid-for would not. If somebody pays you for ability to place 10 calls
they will be happy at all times irrespective of how many calls non-payers
have at that point in time. If you had one queue for 12 calls (same example
as above) then all paid-for and non-paid-for calls would degrade.
Effectively using different classes you can make independent promises and
deliver upon them (assuming total promise can be delivered). There is only
one LLQ though, and for all packets in it fifo will be used.
I am not exactly sure what do you mean by 'strict priority is in effect
always'. This does sound like semantics to me. If there is no congestion
every packet would have strict priority, such as pushed to interface tx ring
on arrival, as nothing to wait for. Congestion is required for queuing to
kick in. As well when no congestion is present the policing component of
strict priority class does not kick in.
Best regards,
Alexei
-----Original Message-----
From: GAD [mailto:gad@gad.net]
Sent: Tuesday, June 08, 2004 10:54 PM
To: asadovnikov
Cc: ccielab@groupstudy.com
Subject: RE: Sort of OT: Hardware Queues on Serial Interfaces
On Tue, 8 Jun 2004, asadovnikov wrote:
> Even that it would not prioritized one on top of the other (see reply
> from Scott), in your example during congestion money making calls will
> be policed at higher rate then non-money-making calls and as a result
> of such higher permitted rate have better service.
Hmmm... Semantics?
Seems to be sort of a custom queueing within the priority queue then...
If the queue is policed 10x as much for the MoneyMaking calls than the Admin
calls, then as you say, the MoneyMaking calls would have "better service".
Arent' we in effect QOSing (new word) within QOS?
Another related question - normally QOS is important during congestion, but
the strict priority queue is in effect always. Would my config apply always
or only during congestion? Since both classes police to the Priority queue,
and the priority queue always is processed before the others, would not I
have then classified a sort-of BEST priority and PLAIN priority if you will
- all of which will be processed before the rest of the class-maps are even
considered?
Help me to understand...
GAD
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:36 GMT-3