Subject: AW: [NSIS] remove packet_classifier object from QoS-NSLP

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 7 Oct 2005 22:40:30 +0200

hi jukka, 

i do not understand why define information at the qos nslp that is already available from the lower layer (gist). 
in the natfw nslp we reuse the lower layer information. we only discussed the ability to extend the mrm when it is not sufficient. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Jukka MJ Manner
> Gesendet: Freitag, 7. Oktober 2005 21:13
> An: Georgios Karagiannis
> Cc: [email-masked]
> Betreff: Re: [NSIS] remove packet_classifier object from QoS-NSLP
> 
> 
> 
> Hi Georgios, all,
> 
> If people would rather see the packet classifier removed from 
> the QoS-NSLP 
> spec, then I would still like to see it defined in the QSPEC 
> template. It 
> would be good from an implementation point of view, and 
> implementation 
> effort, if there was a single suggestion on how to specify packet 
> classifiers in QoS models.
> 
> Still, I'd like to hear other views on what to do with the classifier.
> 
> Cheers,
> Jukka
> 
> On Fri, 7 Oct 2005, Georgios Karagiannis wrote:
> 
> > Dear all
> > 
> > After trying to incorporate the QoS-NSLP PACKET_CLASSIFIER  
> object, in 
> > our implementation, we have seen that the need of using 
> such an object for 
> > filtering and packet classification is not needed.
> > 
> > The main reason for that is that the RMF is responsible for 
> modifying/interacting
> > with the packet classification function, see Figure 1 in 
> QoS-NSLP draft. Both 
> > functions are not QoS-NSLP functions.
> > Thus I do not understand why we have to generate such an 
> object, since
> > the QoS model, used in each node, should actually specify 
> by using a local policy on each node,
> > which filters and how such filters must be used.
> > Therefore I propose to remove the PACKET_CLASSIFIER from the 
> > QOS-NSLP specification.
> > 
> > 
> > Best regards,
> > Georgios
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 11 Oct 2005 08:46:04 -0400

Hi, all:
 
QSEPC is the "generalized" QoS templates and does not deal with anything beyond that per charter of NSIS protocol. There should be nothing beyond that. For example, NSIS signaling protocol does not deal with any domain or restrictions on values on QoS parameters. There is nothing e2e QSPEC vs domain-specific QSPEC.
 
The "use" of QoS models is a separate thing, and it has created confusions for NSIS signaling protocols, like RSVP or DiffServ, are "generic" and does not deal with implementation specific QoS models that are limited by specific values and/or domains.
 
It is interesting to see that the co-authors of the QSPEC have come forward to defend their wisdom for using of implementation-specific, incomplete QoS models extensions described in "generalized" QSPEC. Now, they are saying Georgios, why he is proposing e2e QSPEC vs domain specific QSPEC.
 
The answer is as follows:

1.	
	The use of QSPEC will be treated in the context of the generalized NSIS signaling protocol that does not restrict with e2e or domain.
2.	
	Any implementations can be any QoS model specific and/or Domain specific.
3.	
	Confusions come when people mix item 1 with item 2.
4.	
	Present (latest version) QSPEC draft itself is source of all confusions. Present QSPEC draft mixes item 1 with item 2. So, this draft needs to delete any references to item 2. Item 2 needs to have separate drafts how to deal with specific implementations of QoS signaling models using the generalized QSPEC templates.
5.	
	In implementations, there can be a combination of many things: a. e2e (codec-to-codec from application point of view), b. edge-to-edge, c. Backbone network (excluding access networks), and/or others. Here comes all sorts of implementation complexities.

Item 5 shows why e2e NSIS protocol may need to deal with different things that may consist of both e2e and non-e2e. 

In the discussions, let us focus on what we are going to deal with. Let us NOT confuse ourselves like the latest QSPEC draft that deals with both generalized QSPEC and implementation-specific QoS models.

Best regards,

Radhika

________________________________

From: [email-masked] on behalf of Kappler, Cornelia
Sent: Tue 10/11/2005 5:42 AM
To: Georgios Karagiannis
Cc: [email-masked]
Subject: FW: [NSIS] remove packet_classifier object from QoS-NSLP

Hi Georgios,

if indeed the packet classifier is QSPEC / QoS Model dependent, and we
would need stacked packet classifiers as well as stacked QSPECs it would
make sense to include it in the QSPEC.

However I dont understand why you would use separate packet classfiers
for stacked QSPECs (one of them e.g. e2e QSPEC, the other a
domain-specific RMD QSPEC). The packet classfier specifies what packets
receive the treatment described in the QSPEC. I'd rather expect that for
a given QoS NSLP message, the packets being singled out for treatment
are always the same (no matter what QoS Model is used to reserve
resources).

Can you make your example more concrete?

Cornelia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Georgios Karagiannis
> Sent: Montag, 10. Oktober 2005 13:28
> To: [email-masked]; [email-masked];
> Tschofenig, Hannes; [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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 11 Oct 2005 09:20:08 -0400

Hi, Georgios:

You are right.

Then the basic question comes: Can we have a "generalize" QoS model like
generalized QSPEC template through which proper packet-classifiers can
be used?

If not, can coauthors of the QSPEC draft defend their wisdom why they
have included implementation-specific QoS models in the generalized
QSPEC draft and creating confusions for all of us?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Tuesday, October 11, 2005 8:53 AM
To: Kappler, Cornelia
Cc: [email-masked]
Subject: Re: [NSIS] remove packet_classifier object from QoS-NSLP

Hi Cornelia

Please see in line!

----- Original Message ----- 
From: "Kappler, Cornelia" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 11, 2005 1:26 PM
Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP

> Hi Georgios,
>
> when including two or more packet filters, how do we make sure that
for
> a single QoS NSLP  session, it is always the same set of packets which
> is receiving the reservation benefits?

Georgios: In a domain that supports a QoS model we should use only one 
filter/packet classifier.

> If filtering is based on DSCP/source address in one domain, and based
on
> the flow ID in another domain, it might well happen that a specific
> packet receives QoS only in one domain.

Georgios: this occurs in the case when during an end to end path more
than 
one heterogeneous
QoS models are used.
If a QoS model supports aggregation and another does not then a
different 
type of filtering/packet classification
must be used.

This means that different filters/packet classifiers should be used per
QoS 
model!

Best Regards,
Georgios