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

From: "Shahrier, Sharif M." <[email-masked]>
Date: Thu, 4 Apr 2002 15:21:32 -0500

Marcus,

The question was how to derive the QSCs, and I suggested that the QSCs can
be mappable from a set of performance metrics that capture the constraints
on the QoS.

My understanding from your message is that NSIS is not required to come up
with a standardized performance metrics?

However, the notion of QSCs are in the draft, which I support, and hoping to
send text shortly to the list on its classification.

Sharif.

 -----Original Message-----
From: 	Marcus Brunner [mailto:[email-masked]] 
Sent:	Thursday, April 04, 2002 8:22 AM
To:	Shahrier, Sharif M.
Cc:	[email-masked]
Subject:	Re: [NSIS] On the definition of QoS flow and aggregate flow.

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:

> 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

--------------------------------------
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

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

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 05 Apr 2002 13:12:43 +0200

Actually, we do not want to go down the path of defining nore standardizing 
QoS service classes or something the like. I think the definition of QSC 
might vanish, or at least not further defined nor any requirements are 
listed concerning the QSC. Actually, we most likly remove some 
requirements, which seam to be very service-specific.

Marcus

--On Thursday, April 04, 2002 3:21 PM -0500 "Shahrier, Sharif M." 
<[email-masked]> wrote:

> However, the notion of QSCs are in the draft, which I support, and hoping
> to send text shortly to the list on its classification.
>
> 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.
>
>> A flow aggregate can be defined as a set of flows, where each flow has
>> the same QoS priority.
>>