Subject: RE: [Ieprep] requirements document(s) to SIPPING

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 16:03:39 -0400

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, October 01, 2002 2:42 PM
To: King, Kimberly S.
Cc: Ieprep (E-mail)
Subject: Re: [Ieprep] requirements document(s) to SIPPING

...

 Maintaining two (or more) queues 
instead of one isn't terribly challenging for an application, 
particularly if you don't do preemption. The pseudo is nothing but

if (incoming request has high priority)
    insert into queue1
else
    insert into queue2

and

if request is done
   pick next from queue1
   if empty, pick next from queue2

[JPG] Agree that a simple set of multiple FIFO queues is "easy".  However,
when there is a desire (based on business considerations) to "give priority
if there are only a few of them, but not let them take over everything", the
logic can become quite tortuous.  So, in making decisions, it is not safe to
ASSUME a simple queue logic.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Oct 2002 16:20:18 -0400

> ASSUME a simple queue logic.

Agreed; however, per-class "bandwidth" allocation this is a standard 
problem in networking, handled at line rates and in hardware for 
routers. Thus, this is still fairly common. (This is also fairly similar 
to CPU scheduling code, which also is fairly well understood and not 
hard for anybody who's taken OS in undergrad.)

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Thu, 10 Oct 2002 13:28:24 -0700

Janet,

I think you are right that it can become more complex very easily if one adds
factors such as time in queue, etc.  I have seen systems that work from the
highest priority queue but every so often visit the lower priority ones so that
they are not completely denied service.

I could see that becoming an interesting discussion point as to if the higher
queue priority is an absolute (one never serves an n-1 queue if there is an
entry in the n queue) or relative (after serving a handful of n queue entries,
we serve 1 from the n-1 queue. This could be recursive.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Oct 2002 16:30:52 -0400

> we serve 1 from the n-1 queue. This could be recursive.)

Before we rathole here: this is far outside the scope of the WG. This is 
an implementation issue. We're not even specifying the algorithms at 
this point, let alone the precise queueing mechanism. The discussion 
started to simply state that such differential request treatment is 
*possible*, in many different ways, none of which will likely be 
specified in the IETF.