Subject: RE: [NSIS] On flow buffering and scheduling.

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 16:09:28 -0500

Sharif:

 I think you are proposing a new QoS model, based upon "priority".
It is my understanding that the common view of "priority" from a QoS
perspective is that it can always be translated to other QoS performance
parameters: more bandwidth, lower delay, less loss, lower delay jitter.
Priority queuing is just one mechanism for achieving these QoS levels.

Gary

> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:[email-masked]]
> Sent: April 3, 2002 15:54
> To: Shahrier, Sharif M.
> Cc: [email-masked]'
> Subject: [NSIS] On flow buffering and scheduling.
> 
> 
> 
> A flow is a packet stream between endpoints, with a specified 
> level of QoS.
> 
> In my last e-mail, I had suggested using priority, as the 
> level of QoS for
> the given flow stream.
> 
> I had also suggested using a 6-tuple (src addr, dst addr, src 
> prt, dst prt,
> protoid, priority) to characterize flow for NSIS purposes.
> 
> For a flow to be a member of an aggregate flow set, its 
> priority must be the
> same as all the others, of course, while src addr, dst addr may be
> different.
> 
> An important consideration is how to buffer the flows for an 
> aggregate flow
> set, so they all can have the same forwarding treatment based on their
> common priority value.
> 
> How to manage the buffers............
> 
> And how to schedule packets in the aggregate flow set for 
> transmission.
> 
> I believe these are important issues, I wanted to bring them up for
> discussion, suggesting text should be added to the 
> requirements document.
> 
> Sharif.
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Scott Brim <[email-masked]>
Date: Wed, 3 Apr 2002 16:34:50 -0500

Regardless, a flow is what QoS is applied to, therefore it cannot be
defined as having a "specified level of QoS" without circularity.