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

From: "Cheng Hong" <[email-masked]>
Date: Wed, 26 Oct 2005 17:39:41 +0800

Hi Georgios,

Please see some comments below:

> Georgios: Why?
> A QoS model can configure locally a node to use the MF 
> classifier for packet classification.

Yes. That is to be defined by the QoS Model. 

> Another case will be that the QOS model will configure the 
> edge of the QoS model to use the MF classifier and that then 
> this edge will signal this information to all intermediary 
> nodes (that are using the same QoS model) to use this 
> information for packet classification.

You mean there would be a separate (local) signaling session between
QNEs of same QoS Model to dynamically setup which field of the MF
classifier should be used for packet classification? 

> > If every NSLP has the same format, the NAT doesn't need to 
> > understand/know which NSLP is that. It only process the common 
> > formated information element for the packet_classifier if it is 
> > present. (well, that may require an indicator for its presence be 
> > placed in the common header, not tied to message type)
> 
> Georgios: Not sure if this can be applied.
> The NATP has to recognise all types of NSLSP messages in 
> order to do that.
> Thus it should be all-NSLP aware.

If there is an indicator in the header to specify if there is an packet
calssification object contained in the message (of a fix position), the
NAT doesn't have to the x-NSLP aware. That is what I meant with the
words in the bracket. It may not be that good, but it is a possible
solution.

> Georgios: Well each QoS model will choose the required 
> parameters from the MRI.
> Thus QoS model A will choose some parameters from MRI and QoS 
> model B will choose other parameters from the same MRI. Thus 
> MRI does not need to be stackable!

This is only when the QoS Model A and QoS Model B uses the same
information for the packet classification (from different parts of the
MRI). However, if they use different info, that may not work. That is
when the MRI needs to be stackable (when classifier A and classifier B
cannot be represented by the same MRI).

cheers

Cheng Hong

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Wednesday, October 26, 2005 5:09 PM
> To: Cheng Hong; Andrew McDonald
> Cc: [email-masked]; Takako Sanda; [email-masked]
> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> 
> Hi Cheng
> 
> Please see in line!
> 
> ----- Original Message -----
> From: "Cheng Hong" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>; "Andrew 
> McDonald" 
> <[email-masked]>
> Cc: <[email-masked]>; "Takako Sanda" 
> <[email-masked]>; <[email-masked]>
> Sent: Wednesday, October 26, 2005 10:38 AM
> Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> 
> 
> > Hi Georgios,
> >
> > Please see some comments below:
> >
> > <snip>
> >> >
> >> > This would be an easy way to address the NAT issue. We may
> >> also need
> >> > to identify how to indicate that "one or more parameters"
> >> to be used
> >> > for the packet classification. Maybe that is what the 
> >> > PACKET_CLASSIFIER is meant for.
> >>
> >> Georgios: This will have to be defined by the used QoS model, and 
> >> should not be signaled.
> >> If a QoS model needs to use other parameters then it will 
> be able to 
> >> configure them!
> >> This is up to the QoS model.
> >
> > You are right that the QoS Model needs to define what should to be 
> > signaled. The concern is that what the QoS Model defined may not be 
> > able to be signaled by using the MRI only. The QoS Model 
> can define a 
> > format, no the contents, because the actual packet classificaiton 
> > information (defined within a QoS Model) could be affected by the 
> > operation. As what we discussed earlier, for example, a QoS Model 
> > could define that a MF classifier is needed, however, it cannot 
> > predict that whether the port number should be wildcarded or a 
> > specific port should be used. Whether to use the port number (or 
> > multiple port number) still needs to be signaled over 
> between QNEs (by using something else than MRI).
> 
> Georgios: Why?
> A QoS model can configure locally a node to use the MF 
> classifier for packet classification.
> Another case will be that the QOS model will configure the 
> edge of the QoS model to use the MF classifier and that then 
> this edge will signal this information to all intermediary 
> nodes (that are using the same QoS model) to use this 
> information for packet classification.
> In both approaches the QoS model has to configure that!
> 
> 
> >
> > <snip>
> >> > My feeling is that we at least need to allow some extra
> >> information to
> >> > be included in the QoS-NSLP to complement the MRI for the packet 
> >> > classification. So, how about changing the sentence to:
> >> >
> >> >> "The QOS-NSLP nodes SHOULD use one or more parameters of
> >> the MRI, as
> >> >> indicated by PACKET_CLASSIFIER, for packet
> >> > classification.
> >> >> When PACKET_CLASSIFIER indicates an additional packet
> >> classification
> >> > object included
> >> >> in QoS-NSLP, the additional object should be used for packet
> >> > classification."
> >>
> >> Georgios: The stacking problems will not allow to just use 
> a PACKET 
> >> CLASSIFIER QoS-NSLP object. You have either to generate a stacked 
> >> PACKET_CLASSIFIER QOS-NSLP object or you have to included in the 
> >> QSPEC.
> >> But as I mentioned above, this information does not have to be 
> >> signaled.
> >
> > Yes. If the QSPEC stacking is to be supported, the object has to be 
> > stackable also, as we discussed before. Maybe a simple way 
> out of this 
> > is to limit the stackable option of the QSPEC (disallow 
> that), if we 
> > want to avoid the problem. Even if we limit the information to the 
> > MRI, we still may face the problem for the stackable issue on MRI. 
> > (please see comments below regarding the stackable MRI issue)
> 
> Georgios: Well I do not thing that this is the right solution.
> I do not understand why you think that stacking is needed.
> 
> We do not need to stack the MRI. Each QoS model will choose 
> the parameters from ther MRI!
> 
> >
> >> > As for the NAT traversal problem, I think it would not be
> >> an issue if
> >> > we can make the indicator for this additional object and 
> the object 
> >> > itself common for all the NSLPs (as a common function of all the 
> >> > NSLP). In this case, the NAT doesn't need to be specific
> >> NSLP aware to
> >> > do the update of the object (same as treating the MRI). 
> So far, I 
> >> > think this additional packet classification information is
> >> useful for
> >> > QoS-NSLP, NAT/FW-NSLP, and also the recently discussed
> >> metering-NSLP.
> >>
> >> Georgios: But this solution will only work if we mandate that the 
> >> NATP is NAT-NSLP aware, QoS-NSLP-aware, ...-NSLP aware, etc..
> >> I think we do not want to impose such requirements!
> >
> > If every NSLP has the same format, the NAT doesn't need to 
> > understand/know which NSLP is that. It only process the common 
> > formated information element for the packet_classifier if it is 
> > present. (well, that may require an indicator for its presence be 
> > placed in the common header, not tied to message type)
> 
> Georgios: Not sure if this can be applied.
> The NATP has to recognise all types of NSLSP messages in 
> order to do that.
> Thus it should be all-NSLP aware.
> 
> >
> >> > For the stackable QSPEC issue raised by Georgios earlier in this 
> >> > thread, I am not sure how it could be solved by limiting 
> the packet 
> >> > classification information to the MRI.
> >>
> >> Georgios: It can be solved since the GIST should update 
> the MRI, if 
> >> the GIST session traverses a NATP that modifies the 
> >> source/destination port and addresses, then GIST  should 
> modify ther 
> >> MRI.
> >> All the NSLPs are using the MRI that is provided by GIST. In this 
> >> case the described problem by you will be solved.
> >
> > Please note that this is not about the NAT issue. It is on the 
> > stacking support of the QSPEC you mentioned earlier:
> 
> 
> Georgios: Well each QoS model will choose the required 
> parameters from the MRI.
> Thus QoS model A will choose some parameters from MRI and QoS 
> model B will choose other parameters from the same MRI. Thus 
> MRI does not need to be stackable!
> 
> Best regards,
> Georgios
> 
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Oct 2005 11:56:22 +0200

Hi Cheng

 I do not understand what you mean bty stacked MRI?
I think that we do not need such a fature!

> cannot be represented by the same MRI).

Georgios: No, each QoS model can select to use other MRI parameters.

Best Regards,
Georgios

----- Original Message ----- 
From: "Cheng Hong" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>; "Andrew McDonald" 
<[email-masked]>
Cc: "Takako Sanda" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, October 26, 2005 11:39 AM
Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC