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

From: "Cheng Hong" <[email-masked]>
Date: Mon, 10 Oct 2005 14:56:41 +0800

Hi Georgios,

As described in the previous email, there are advantage and disadvantage for doing that. The disadvantage of including the PACKET_CLASSIFIER object into the QSPEC is that the NSIS node needs to be specific QOS-Model aware to process the packet classification information. This will be a hard requirement for the address boundary nodes to meet, e.g. NAT. Having that object in NSLP layer or NTLP layer will make it easier. Where to place the information element is a trade off between different implementation aspects. It just seems that this aspects leads to placing PACKET_CLASSIFIER outside of the QSPEC. Personally, I don't have strong preference of where to place it. 

cheers

Cheng Hong

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Monday, October 10, 2005 2:20 PM
> To: Cheng Hong; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP
> 
> 
> Hi Cheng
> 
> Agree with you that the QSPEC has to be associated with a 
> PACKET_CLASSIFIER object, then why not include the 
> PACKET_CLASSIFIER object intothe QSPEC object?
> 
> Best Regards,
> Georgios
> 
> On 10/10/2005, "Cheng Hong" <[email-masked]> wrote:
> 
> >Hi Georgios,
> >
> >The scenario you raised is an important case to consider. 
> However, I would like to clarify if over the same section of 
> the path, both of the PACKET_CLASSIFIERs (end2end and 
> edge2edge) would be used by the QNE at the same time. For 
> example, in the stacking case, path within a domain probably 
> would only be applicable with the edge2edge PACKET_CLASSIFIER 
> (and the end2end PACKET_CLASSIFIER would be transparent).
> >
> >It seems to me that the QSPEC has to be associated with a 
> PACKET_CLASSIFIER object. This is to be interpreted by the 
> RMF.  Whether the PACKET_CLASSIFIER object is to be included 
> inside the QSPEC or as a QoS-NSLP object it is up to 
> discussion. There are advantage and disadvantage for both 
> options. Placing the PACKET_CLASSIFIER object as a QoS-NSLP 
> object has the advantage of being QoS model independent, 
> which means the nodes can process the information element 
> without being QoS model aware, e.g. at address boundaries 
> nodes. Also, I tend to agree with Robert's reasoning on the 
> place of the object.
> >
> >For the QSPEC stacking case, the PACKET_CLASSIFIER object in 
> the QOS-NSLP could also be made stackable. Thus, the 
> corresponding PACKET_CLASSIFIER could correspond to the 
> correct QSPEC. Implementation wise, do you think this is feasible?
> >
> >Just my 2cents
> >
> >Cheng Hong
> >
> >
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Georgios Karagiannis
> >> Sent: Monday, October 10, 2005 1:28 PM
> >> To: [email-masked]; [email-masked]; 
> >> [email-masked]
> >> Cc: [email-masked]
> >> Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP
> >>
> >>
> >> Hi Robert
> >>
> >> The problem is 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?
> >>
> >> Best Regards,
> >> Georgios
> >>
> >>
> >>
> >> On 10/9/2005, "Hancock, Robert" <[email-masked]> wrote:
> >>
> >> >IIRC the issue (raised at the Munich interim) is that it 
> may be that 
> >> >the MRI at the GIST level can't be constructed that exactly
> >> matches the
> >> >packet classifier needed. there are two cases:
> >> >
> >> >- that the packet classifier needs to be more specific, i.e.
> >> >taking into account more data than could ever be relevant
> >> for message
> >> >routing.
> >> >
> >> >- that the packet classifier needs to be less specific. the
> >> particular
> >> >example is where you want to do something like
> >> >rfc3175 where the only relevant part is the 
> ingress/egress interface 
> >> >and DSCP.
> >> >
> >> >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.
> >> >
> >> >r.
> >> >
> >> >> -----Original Message-----
> >> >> From: [email-masked] [mailto:[email-masked]]
> >> On Behalf
> >> >> Of Tschofenig, Hannes
> >> >> Sent: 07 October 2005 21:41
> >> >> To: Jukka MJ Manner; Georgios Karagiannis
> >> >> Cc: [email-masked]
> >> >> Subject: AW: [NSIS] remove packet_classifier object 
> from QoS-NSLP
> >> >>
> >> >>
> >> >> 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
> >> >>
> >>
> >> _______________________________________________
> >> 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: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 10 Oct 2005 11:17:20 +0200

Hi Cheng

The main disadvantage, of not including this object  in the QSPEC,
is that the PACKET_CLASSIFIER object in  the QOS-NSLP should be made 
stackable.
Do we want this?

Best Regards,
Georgios

----- Original Message ----- 
From: "Cheng Hong" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 10, 2005 8:56 AM
Subject: RE: [NSIS] remove packet_classifier object from QoS-NSLP

> Hi Georgios,
>
> As described in the previous email, there are advantage and disadvantage 
> for doing that. The disadvantage of including the PACKET_CLASSIFIER object 
> into the QSPEC is that the NSIS node needs to be specific QOS-Model aware 
> to process the packet classification information. This will be a hard 
> requirement for the address boundary nodes to meet, e.g. NAT. Having that 
> object in NSLP layer or NTLP layer will make it easier. Where to place the 
> information element is a trade off between different implementation 
> aspects. It just seems that this aspects leads to placing 
> PACKET_CLASSIFIER outside of the QSPEC. Personally, I don't have strong 
> preference of where to place it.
>
> cheers
>
> Cheng Hong
>
>