Subject: [NSIS] On flow buffering and scheduling.

From: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 3 Apr 2002 15:53:55 -0500

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: "Shahrier, Sharif M." <[email-masked]>
Date: Wed, 3 Apr 2002 16:35:47 -0500

Gary:
 
            Priority is not a "new QoS model". It is already defined in the
IETF. For example Differentiated Services can map from service parameters
such as delay, throughput, etc. to a number of discrete codepoints, known as
Differentiated Services CodePoints (DSCPs). Thus, the idea of translating
from service specific  QoS parameters to priority values exists already.
 
I was suggesting the re-use of this concept to characterize a flow from the
NSIS prespective.
 
Sharif.
 
-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 4:09 PM
To: 'Shahrier, Sharif M.'
Cc: [email-masked]'
Subject: RE: [NSIS] On flow buffering and scheduling.
 
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]
<mailto:[email-masked]> ] 
> Sent: April 3, 2002 15:54 
> To: Shahrier, Sharif M. 
> Cc: [email-masked]' 
> Subject: [NSIS] On flow buffering and scheduling. 
> 
> 
> 
<https://www1.ietf.org/mailman/listinfo/nsis>

---

From: Bob Braden <[email-masked]>
Date: Wed, 3 Apr 2002 22:02:14 GMT

*> From [email-masked]  Wed Apr  3 13:38:03 2002
  *> From: "Shahrier, Sharif M." <[email-masked]>
  *> To: "'Gary Kenward'" <[email-masked]>,
  *>    "Shahrier, Sharif M."
  *> 	 <[email-masked]>
  *> Cc: "[email-masked]'" <[email-masked]>
  *> Subject: RE: [NSIS] On flow buffering and scheduling.
  *> Date: Wed, 3 Apr 2002 16:35:47 -0500 
  *> MIME-Version: 1.0
  *> X-Mailman-Version: 1.0
  *> List-Id: Next Steps in Signaling <nsis.ietf.org>
  *> X-BeenThere: [email-masked]
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> Gary:
  *>  
  *>             Priority is not a "new QoS model". It is already defined in the
  *> IETF. For example Differentiated Services can map from service parameters
  *> such as delay, throughput, etc. to a number of discrete codepoints, known as
  *> Differentiated Services CodePoints (DSCPs).

I would be very interested to read that the RFC that defines a mapping
of QoS parameters to code points, or that says anything specific about
priority queueing.

Thanks,

Bob Braden