Subject: [NSIS] QoS-NSLP, QSPEC, and QoS Model

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 10 Oct 2005 11:14:00 -0400

Hi, John, George, and all:

We are extremely confused to see the discussions that QSPEC and QoS
models are used in the same breadth in providing the examples of packet
classifiers of QoS-NSLP. For example, when it is said that one QoS model
is used end-to-end and while other goes to edge-to-edge in the name of
QSPEC.

Let us go back to QSPEC for a while. QSPEC provides the "generalized"
templates for using different QoS parameters (e.g., delay, delay jitter,
packet loss). It does not "standardize" any specific values, end-to-end,
edge-to-edge, backbone node-to-backbone node, or access node-to-access
node, etc.

A QoS model may specify many things that are implementation specifics,
and may contain the followings:

1.	Specific value of each QoS parameter (e.g., delay, delay jitter,
packet loss). Note: If any value of any parameter is changed, it will
NOT be the same QOS model.
2.	Specific QoS domain (e.g., end-to-end, edge-to-edge, backbone
node-to-backbone node, or access node-to-access node, etc.). Note: If
the definition of the domain is changed, it will NOT be the same QOS
model.

So, we have also seen that each QoS model that will use the
"generalized" QSPEC templates needs to have the separate draft
(http://www1.ietf.org/mail-archive/web/nsis/current/msg05366.html and
related threads).

The conclusion is this: 
a.	Any references of QoS models in the QoS-NSLP discussions must
NOT refer QSPEC.
b.	Any references of QSPEC in the QoS-NSLP discussions must NOT
refer QoS models.

That is, any references to QSPEC do NOT mean QoS model and vice versa.

Also, it is again clear why any references of QoS model in the QSPEC
draft must be removed. The latest the QSPEC draft has NOT taken care of
this.

If anyone does takes any specific examples using the specific network,
end-to-end codecs, specific QoS values, QSPEC templates, QoS models, and
domains can discover the above findings very easily. 

The best way is to start with SIP call flows and then integrate with the
NSIS QoS-NSLP, QSPEC, and QoS model signaling messages step-by-step. It
is technical, nothing magical.

Any comments?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Monday, October 10, 2005 7:28 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP

Hi John

I do not have any problem on including this object in the QSPEC.

Please note that the packet classifier functionality is strict
associated with a QoS model. A PACKET_CLASSIFIER object specifies which
filter should be used by the packet classifier functionlaity on
filtering the user data packets.
Suppose now that for the same session two qos models are used, one that
goes end-to-end and the other one that goes edge to edge within a
domain. Note that this is the case when stacking of QSPEC's is used.
If the PACKET_CLASSIFIER object is a QOS-NSLP object, which filter
information should this object contain, the filter information required
by the end-to-end QoS model or the edge-to-edge QoS model?

In this case this problem can be solved by making the PACKET_CLASSIFIER 
object in  the
stackable!
Do we want this?

Another solution is to introduce the PACKET_CLASSIFIER object into the 
QSPEC.

Best regards,
Georgios

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 10, 2005 12:46 PM
Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP

> whether this data should be in the qos-nslp or qspec is less
> clear to me. the concept in my head has always been that the
> qos-nslp carried everything about *what* resource reservation
> action you wanted to carry out, and the qspec was about how
> much "stuff" you actually wanted to reserve. the packet classifier
> needs to be given in every message about a transaction, whereas
> the "how much" information only in some; and the classifier can
> probably be universal, whereas the qspec need not be. I don't
> see why having it in the qos-nslp is hard.
>
> This is where I thought we left it after the interim meeting. I guess
> if we remove it, I'd like to have some more reasoning behind the
> removal.
>
> John
>
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis