Subject: [NSIS] On the definition of QoS flow and aggregate flow.

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

In the NSIS requirement draft, I have some points for discussion on the
definition of a "flow" from the presective of NSIS, and also on the
definition of "aggregate flow".

I feel these need to be defined more fully in terms of QoS.

It is defined in the requirements draft, that:

A flow is a traffic stream between two endpoints for which "a specific level
of QoS is provided". 

My question is how to characterize such a flow in terms of quantitative QoS
parameters.

A set of QoS parameters can be standardized for a flow. These parameters
could be:

Maximum delay
Minimum throughput
Maximum response time (assuming buffering)
Maximum jitter
.......

These parameters should then be mapped to a specific "priority value", i.e.
a single parameter.

The parameter can relate directly to ABR, CBR, UBR, ......... types of flow.

A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr, protoID,
Priority) should characterize a "flow" as far as the requirements for NSIS
working group.

Having a single priority value would make it much easier to quantify QoS to
define a flow, as opposed to a whole set of parameters like delay,
throughput, jitter ............

A flow aggregate can be defined as a set of flows, where each flow has the
same QoS priority.

Thus, a coarse grain, single QoS priority for "flow" characterization can
help to readily gather flows with the same priority value into a set to form
an aggregate flow set.

Comments and feedback please.........

Sharif.

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 04 Apr 2002 15:22:26 +0200

Sharif,

I got the feeling in MPLS WG meeting that defining QoS parameters (or more 
general service descripions is currently out of scope of the NSIS work.

We even have a number of requirements in the -00 draft that are service 
specific and will be removed.

Marcus

--On Wednesday, April 03, 2002 3:27 PM -0500 "Shahrier, Sharif M." 
<[email-masked]> wrote:

> A flow is a traffic stream between two endpoints for which "a specific
> level of QoS is provided".
>
> My question is how to characterize such a flow in terms of quantitative
> QoS parameters.
>
> These parameters should then be mapped to a specific "priority value",
> i.e. a single parameter.
>
> A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr,
> protoID, Priority) should characterize a "flow" as far as the
> requirements for NSIS working group.
>
> Having a single priority value would make it much easier to quantify QoS
> to define a flow, as opposed to a whole set of parameters like delay,
> help to readily gather flows with the same priority value into a set to
> form an aggregate flow set.
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

---

From: "DJamel H. Sadok" <[email-masked]>
Date: Thu, 4 Apr 2002 08:45:43 -0300 (EST)

> throughput, jitter ............

I did not follow this thread and consequently I am not sure of what a
priority in this context is, but it seems to me
that it would mean some information that refers to a set of QoS parameters
for a given flow. So, why not consider  the use of well known
services (WKS) and defining well known service ids (WKS-IDs) as some class
of a service specification with delay, bandwidth, etc.. information and
use a flow-id or a WKS-ID to refer to it. Of course there is the problem
of having these predefined for scalability. I am using the term service
here to refer to a class of flows with some common QoS characteristics.
The goal here is NOT to define services but to identify using these
WKS-IDs some classes and build some templates for them that some domains
may aggree to use for end-to-end QoS.

So for example in the DSCP field one may have this WKS-ID that represents an
aggreagate flow class and which may locally be mapped
to any QoS domain specific technology (IntServ, DiffServ, over provisionning, ...)
Their mapping depends on the local domain policies and its QoS technology.

Flows may be aggregated at the domain for example if we have two flows
that require delay values of 10ms and 5 ms, a domain may aggregate both
specifications and offer resources for the aggregate as long as the delay
is maintained bellow 5 ms. Of course considering this field, only a
limited number of classes may be defined, so if we need to maintain
information on individual flows and not simply on their aggregates, for
example to deal with those that may breach access policies or apply
admission or other  control, then another field may be used to contain
flow ids.

Djamel