Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

From: "Kappler, Cornelia" <[email-masked]>
Date: Wed, 2 Nov 2005 18:15:35 +0100

Dear all, 

I would like to argue two points:

(1) "stacked classfiers" as well as "each QoS model can select to use
other MRI parameters" may lead to a single QoS NSLP session reserving
resources for two or more separate flows.

This has been pointed out by several people. Obviously, this is a bad
thing. So in consequence, we should agree there is only one valid packet
classifier for a given session. 

(2) the packet classifier depends rather little on the QoS Model.  

I am aware Georgios, Roland,...said the opposite. However, I think there
is exactly one parameter in the packet classifier that to some extent is
QoS Model dependent, namely DSCP! Any DiffServ-based QoS Model is likely
to use the DSCP as a packet classifier. And if this DiffServ QoS Model
is used somewhere in the middle of a data path, whereas the QNI didnt
foresee usage of DSCP, we do have an issue. 

Vice versa however, I can imagine any other QoS Model to include the
DSCP in its packet classifier. And, checking all other parameters (IP
source / dest, etc) they are not at all QoS Model specific. 

So I think we need to rephrase the question: Should we accomodate a
scenario where a (edge) QNE is allowed to change the flow identifier
because it appears more suitable to its QoS Model? In my mind, we
shouldnt, because of (1). What the QNE should do in this case is tunnel
the ongoing NSIS session and set up a new one with a packet classifier
to its liking.

(This argument implies there is no reason to place the packet classifier
in the QSPEC)

Best regards, Cornelia

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: Montag, 24. Oktober 2005 15:01
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Georgios Karagiannis; [email-masked]; Kappler, 
> Cornelia; [email-masked]
> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> 
> 
> Hi Jerry,
> 
> Ash, Gerald R (Jerry), ALABS write:
> > It appears that the packet_classifier could be done either 
> in QoS-NSLP
> > or QSPEC.  However, Cornelia had concerns about putting it 
> in QSPEC so I
> > think we should hear from her again on this (I believe she 
> is away at
> > the moment).  Robert also expressed some concerns I believe.
> > 
> > It still seems to me that the packet_classifier identifies 'what'
> > reservation is being made, and does not identify 'how much stuff' is
> > reserved.  By that distinction, it belongs in QoS-NSLP 
> (this is John's
> > and Robert's logic also).  I also don't understand why putting the
> > packet_classifier in QoS-NSLP is any more complex or prone to errors
> > than putting it in QSPEC.
> 
> And Georgious point was that the packet classifier depends
> probably on the QoS model or is at least somehow related to
> it. So if put into QoS NSLP you possibly end up with a stack
> of packet classifiers in addition to the QSPEC stack.
> Integrating packet classifiers into QSPECs would remove the need
> to support also a separate stack of packet classifiers.
> If thinking about it from a DiffServ perspective I would support
> the view that a packet classifier is probably QoS model dependent.
> However, in DiffServ you also need additional elements like markers
> or droppers for a useful traffic conditioning mechanism.
> 
> Regards,
>  Roland
> 

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

---

From: Xiaoming Fu <[email-masked]>
Date: Thu, 03 Nov 2005 09:14:30 +0100

Hi Cornelia,

I just read thru this thread and support your observations.
Xiaoming

---

From: Roland Bless <[email-masked]>
Date: Mon, 07 Nov 2005 14:51:43 +0100

Hi Cornelia,

> resources for two or more separate flows.

I'm really not in favor of stacked classifiers, but I think that
there are cases when you really need a reservation for two flows,
e.g., in case of a handover. But I guess that you are referring to
the case when MRI and packet classifiers are "inconsistent". In my point
of view the QoS model should derive the packet classifiers from the MRI.
You only need to signal separate packet classifier information when it
is not possible to derive the classifier settings from the MRI somehow.

> classifier for a given session.

I agree if you meant that there may be inconsistencies by signaling
different opaque classifiers. I'm not sure that we need to signal a
classifier at all. If it is signalled, one must check the packet
classifier and MRI "match" somehow before blindly setting or activating
the classifier. However, in case of handovers or aggregation it is
likely that you need to use different classifiers for the same session
(usually we have two different MRIs which describe partially overlapping
flow paths).

> source / dest, etc) they are not at all QoS Model specific. 

Then the MRI is sufficient to derive classification information
from it. My point was that the QoS model needs to determine not
only the corresponding packet classifier but also any further
traffic conditioning elements like markers, droppers etc.

> because it appears more suitable to its QoS Model? In my mind, we

The confusion is here that we have two things that "identify" a flow.
As far as I understood, the only reliable description for a flow is
the MRI which must be carried in GIST. If you need a packet classifier
it must be related to the MRI

> (This argument implies there is no reason to place the packet classifier

I don't see this point as counter-argument against placement of a
classifier into the QSPEC rather than against stacking things :-)
As I said above: I'm not really sure that we need such thing at all.
If not, the QoS model must derive the corresponding MRI->classifier
mapping anyway. If yes, I think that it probably belongs more into the
QSPEC than into the QoS-NSLP.

Regards,
 Roland