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

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

Hi Georgios, and Andrew, and all,

> I think that the easier solution will just be to have a 
> sentence in the QOS-NSLP draft which says:
> 
> "The QOS-NSLP nodes SHOULD use one or more parameters 
> included in the MRI for packet classification."
> 

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. 

However, this may result in an increment in the signaling
session/messages when the MRI cannot provide enough information for the
packet classification. Therefore, it would be a tradeoff between the
signaling efficiency and complexity. 

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."

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. 

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. If the intension is to preserve
the packet classification information for a stacked QSPEC (which is
different from the current MRI), the MRI itself also needs to be
stackable (if it is the sole source of packet classification
information). 

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Georgios Karagiannis
> Sent: Wednesday, October 26, 2005 12:25 AM
> To: Andrew McDonald
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> 
> Hi Andrew
> 
> Please see in line!
> 
> >> Georgios: agree, but in the case of RSVP aggregation the used user 
> >> plane is the same as the user plane used by the end to end 
> session, 
> >> but this user plane uses different packet classifiers in the 
> >> different end to end path locations!
> >> The described  case in the thread allows a higher degree of 
> >> modularity (i.e., since this is one of the main goals of NSIS).
> >
> > The different packet classifiers may be a sign that we 
> should be using 
> > a different signalling session.
> >
> > If we take RMD as an example, the per domain (i.e. end-to-end) 
> > reservation and the per hop (i.e. aggregate-related) 
> reservation are 
> > based on different subsets of information in the MRI, and 
> so require 
> > different PACKET_CLASSIFIERs. The end-to-end signalling performs 
> > per-microflow reservations based on something like the 5-tuple. The 
> > aggregate uses a packet classifier which is just the DSCP.
> >
> > However, RMD (looking at, for example, figure 3 in the RMD 
> draft) uses 
> > separate signalling sessions for its 'per domain' and 'per hop'
> > reservations, so only a single PACKET_CLASSIFIER is needed for each 
> > session.
> >
> > Allowing multiple classifiers seems possible, but does look like 
> > unnecessary complexity.
> 
> Georgios: Exactly this discussion is not related to the RMD concept!
> 
> 
> I think that the easier solution will just be to have a 
> sentence in the QOS-NSLP draft which says:
> 
> "The QOS-NSLP nodes SHOULD use one or more parameters 
> included in the MRI for packet classification."
> 
> In this way we will also allow nodes to use other types of 
> parameters for packet classification, by e.g., using local 
> node configuration.
> 
> Please note that in this way the packet classification will 
> work fine, it will be simple and it will solve the NAT 
> translation problems mentioned by Cheng!
> 
> Please note that something similar is proposed in the 
> NAT./Firewall NSLP draft!
> Hannes also proposed the above the above solution in one of 
> first e-mails relatted to this thread!
> 
> 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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Oct 2005 10:15:17 +0200

Hi Cheng

Please see in line.
----- 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 5:39 AM
Subject: RE: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

> the packet classification. Maybe that is what the PACKET_CLASSIFIER is

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.

>> in QoS-NSLP, the additional object should be used for packet

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.

> 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!

> 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.

> stackable (if it is the sole source of packet classification

Georgios: No, please see my comment above!

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 26 Oct 2005 10:39:57 +0100

Hi Cheng Hong,

some comments below

> and also the recently discussed metering-NSLP.

There are a couple of cases to consider when thinking about how the 
packet classifier may deviate from the MRI.

In the first case you want more information for the packet classifier 
than is carried by the MRI. One issue with this is that of message 
routing - would the extra fields cause a divergence from the MRI-based 
path, e.g. if you provide a 'port range' then would some load balancer 
route the traffic all the same way? Also, adverse NAT-effects may be 
caused e.g. if you identify ports above the GIST layer, then an 
'NSIS-aware NAT' has to look at more than just GIST.

The nature of on-path signalling makes this one difficult for the 
obvious things you might want to do. There may be some cases where it 
will work where the additional information is from higher layers which 
you are certain do not affect the routing and NATs do not touch.

In the second case you want less information than is carried within the 
MRI, though actually this still requires some additional information: 
i.e. which bits of the MRI should be used. As you say, this is what the 
current 'packet classifier flags' are doing. You don't have any NAT 
issues at the NSLP, since the NAT-relevant information is all carried in 
the GIST layer.

> stackable (if it is the sole source of packet classification

I have no idea what a "stackable MRI" means in the context of GIST. MRI 
= message routing information. If you have one message with two MRIs, 
which way do you route it?

regards,
Andrew