Subject: [NSIS] PACKET_CLASSIFIER in QSPEC

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 18 Oct 2005 06:56:52 +0200 (MEST)

Dear all

>From the discussion that we have had in the NSIS mailing list, one can
deduce that the PACKET_CLASSIFIER object cannot be carried as a pure
QOS-NSLP object. The reason is that this will not work when QSPEC
stacking is used.
There are two solutions that one can apply:
* Local configuration by each node, where the filters will be
pre-configured by each QoS model

* signaling using QSPEC; PACKET CLASSIFIER will be a QSPEC parameter!

>From what I have understood, most of the participants in the discussion
would prefer the signaling using QSPEC solution!

Is this acepted by the NSIS WG?
Best Regards,
Georgios

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

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 18 Oct 2005 15:09:04 +0200

Hi All,

Since the PACKET_CLASSIFIER is different in different QoS domains it seems resonable to include it in the QSpec Template as control info. I prefer this solution to configuring it in each node by filters.

Anyway we will keep it as an open QSpec template issue until consensus is reached.

Best regards, Attila

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2005 6:57 AM
> To: [email-masked]; Attila Báder (IJ/ETH); [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: PACKET_CLASSIFIER in QSPEC
> 
> 
> 
> Dear all
>

---

From: [email-masked]
Date: Fri, 21 Oct 2005 10:09:16 +0300

Hi all,

>Since the PACKET_CLASSIFIER is different in different QoS 
>domains it seems resonable to include it in the QSpec Template 
>as control info. I prefer this solution to configuring it in 
>each node by filters.

Well, I'd think that if we left it as local configuration, we
wouldn't be doing our job.  We are working on QoS signaling,
and my assumption is that PACKET_CLASSIFIER is part of that.
I'm not suggesting that we would not allow local configuration,
but to insist on it would not be sensible, IMO.

I think we should resolve the issue where the PACKET_CLASSIFIER
belongs, so I'll see if I can see if we are heading to consensis
on this or not.

John

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 24 Oct 2005 15:49:44 -0400

The way I see the problems are as follows:
1.	The scope of NSIS spec is so generic that can (will be able to)
accommodate all QoS models either end-to-end and/or a combination of
edge-to-middle/middle-to-edge/edge-to-edge over all transport layers
(Datagram mode, Connection mode).
2.	There is not a generalized QoS model that can be used, and NSIS
can take care of that model.
3.	To accommodate multiple QoS models in a single session will
always invite complexity whether packet filter classifications and
others that are needed for the implementation-specific QoS models are
done in QSPEC or otherwise.
4.	To invite comparison NSIS with RSVP is a good one as a starting
point, however, items 1-3 show that we have to explore much more complex
situations what have never been envisioned in RSVP.

The best way to assure that NSIS signaling (QoS, Others) applications
will work is to do some analysis with use cases as follows:
a.	Use a single QoS model on end-to-end (e.g., IntServ).
b.	Use multiple QoS models on end-to-end (e.g., IntServ at edges,
DiffServ in Backbone).
c.	Use Y.xxxx model in combinations with items a and/or b (Note:
Y-model can be used in addition to IntServ and/or DiffServ restricting
only the values of QoS parameters).

Will it be too complex to get the right answer to remove Dave's
concerns?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David R Oran
Sent: Monday, October 24, 2005 8:57 AM
To: nsis Group
Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

On Oct 22, 2005, at 2:58 AM, Georgios Karagiannis wrote:

>
> Hi Jerry
>
> Please see in line!
>
> On 10/21/2005, "Ash, Gerald R (Jerry), ALABS" <[email-masked]> wrote:
>
>
>> Hi Georgios,
>>
>> Thanks for your detailed example, I think this is a good way to  
>> resolve
>> the issue.
>>
Well, I'm still shaking my head over this entire thread. I simply  
can't imagine how it would be useful for a single NSIS session, with  
or without multiple stacked QSPECs or other amazing complexity, to  
have that session apply to different packets at different points  
along the path. How the heck would I debug this? Let's see. Not only  
can I have multiple flows mapped to a single NSIS session (for  
resource sharing), but I can't even tell whether a given packet will  
be afforded particular treatment unless I can peer inside local state  
at every hop on the NSIS path.

I could certainly see why a node might decide to install a data plane  
packet classifier which covers a larger equivalence class of packets  
than the control plane packet classifier provided through NSIS. It  
might need to do this to avoid state explosion, or want to live  
dangerously by playing some statistical/queueing-theory games, or  
because it knows certain degrees of freedom will never occur in  
practice.

What I can't for the life of me follow is the benefit of allowing any  
arbitrary packet classifier to be associated with a segment of the  
end to end (or edge to edge path) simply by stacking QSPECS.

The only application which even remotely touches on such complexity  
would be session tunneling, as is done with RSVP aggregation. But in  
that case the packet classifier used inside the tunnel is associated  
with a completely independent RSVP session is isn't some kind of  
simple stacking of QSPECS in a single reservation/session.

I'm so completely blown away by the gratuitous complexity this allows  
that I'm not sure I can engage in a rational engineering tradeoff  
discussion.

Of course, I'm one who argued against stacked QSPECs in the first  
place...

Dave.

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 25 Oct 2005 11:30:31 +0800

Hi Roland and Georgios, and all,

The packet_classifier is indeed pretty much depending on the QoS Model
in use. As point out by Georgios, the QoS Model may dictate what is the
proper information to use for the packet_classifier. 

Regarding the packet_classifier, I have two question/issue to clarify.

Firstly, I am wondering, since the packet_classifier is QoS Model
dependent, does the packet_classifier still need to be general (format)
or it can be QoS Model specific? 

Secondly, regarding placing the packet_classifier in QSPEC, it may place
certain requirement on the NAT traversal. For example, a QoS NSLP
message is send from QNE-A to QNE-B passing throgh a NAPT, the
packet_classifier needs to change. Before the NAPT, the port address is
not used for the packet classification, and therefore is no set. After
the NAPT, the port number is definitly required for the packet
classification, and should be set. In this case, if the packet
classifier is in the QSPEC, the NAPT needs to be able to process the
message so that it can parse the QSPEC, and update it. Is this an
acceptable requirement on the NAT traversal?

Regarding stacking the packet_classifier, I am not sure what is the
problem in the implementation. It seems that the operation only needs to
be synchronized with that applied on the QSPEC. (Sorry for my ignorance
about the implemenation issues) It doesn't seems like a major problem to
me. 

cheers

Cheng Hong

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roland Bless
> Sent: Monday, October 24, 2005 9:01 PM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]; Georgios Karagiannis; 
> [email-masked]; [email-masked]
> 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
>

---

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

Hi Andrew,

Thanks a lot for summarizing the issue. That is really helpful. Please
see some comments inline:

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

You are right. The major issue regarding this case is the NAT traversal.
So far, we havn't seen a very good solution for that (some possibility
are mentioned in other emails of this thread). 

However, there are some instances that may benefit from including more
information than that is carried in the MRI (as also discussed in the
other thread).  I think this is the major issue the group need to sort
out.

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

Agree. 

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

Similar to the QSPEC stacking: the top MRI will be used for routing. 

Well, I am not really proposing this (it would be a nightmare for
implementation). Just would like to point out that if the QSPEC stacking
is to be support, as pointed out by Georgios, using only MRI for the
packet classification may also face the same issue (stacking of MRI
since it equals to the packet_classifier in that case)

cheers

Cheng Hong

> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Wednesday, October 26, 2005 5:40 PM
> To: Cheng Hong
> Cc: Georgios Karagiannis; [email-masked]; 
> [email-masked]; Takako Sanda
> Hi Cheng Hong,
> some comments below
> Cheng Hong wrote:
> >>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.
> 
> 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.
> 
> > 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).
> 
> 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
>

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 27 Oct 2005 07:36:37 -0500

Hi Georgios, Andrew, All,

> As I see, it will take us a lot of time to resolve this
> issue! I propose to discuss this in more detail during
> the IETF meeting in Vancouver!
> For the time being it is okay with me that this issue
> is considered as an QSPEC/QoS-NSLP open issue!

That's all well and good.  But IMO we're still lacking a practical,
realistic example of a flow (signaled by NSIS) that would require 2 (or
more) packet_classifiers within the same flow.  We keep mentioning
hypothetical examples and realize that these are complex (or perhaps
impossible).

Can someone give a real example, this will help the discussion in
Vancouver (and on the list).  If it's been given before, please just
give it again (I can't find it now in this long thread).

If we can't come up with a real example, then maybe we don't have an
issue.  

Thanks,
Regards,
Jerry

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 28 Oct 2005 18:31:44 +0800

Hi Jerry, and all,

I think a few things have been mixed together here. First issue is that
the MRI not able to signal all the information for packet
classification, e.g. when it needs to signal a port range, etc.
Therefore, it is necessary to have some additional information to be
signalled at NSLP layer. This is more about why/how the
packet_classifier is introduced.

Another issue is that when the additional information (say,
packet_classifier) is used in NSLP layer, how the relevant issues should
be resolved, e.g. NAT traveral, QSPEC stacking support (i.e. where to
place it). Andrew has a very good summary of the issue in an earlier
email.

And only the second part is relevant to whether there require 2 or more
packet_classifiers. Example for this case is the QSPEC stacking
(assuming that MRI is not adequate, and packet_classifier has to exist).

As Georgios suggested, tt would be good to have some face to face
discussion during the Vancouver meeting. It may be earlier with some
pirctures and drawings...

cheers

Cheng Hong

> Behalf Of Ash, Gerald R (Jerry), ALABS
> Sent: Thursday, October 27, 2005 8:37 PM
> To: Georgios Karagiannis; Andrew McDonald; [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: [NSIS] RE: PACKET_CLASSIFIER in QSPEC
> 
> > As I see, it will take us a lot of time to resolve this issue! I 
> > propose to discuss this in more detail during the IETF meeting in 
> > Vancouver!
> > For the time being it is okay with me that this issue is 
> considered as 
> > an QSPEC/QoS-NSLP open issue!
> 
> That's all well and good.  But IMO we're still lacking a 
> practical, realistic example of a flow (signaled by NSIS) 
> that would require 2 (or
> more) packet_classifiers within the same flow.  We keep 
> mentioning hypothetical examples and realize that these are 
> complex (or perhaps impossible).
> 
> Can someone give a real example, this will help the 
> discussion in Vancouver (and on the list).  If it's been 
> given before, please just give it again (I can't find it now 
> in this long thread).
> 
> If we can't come up with a real example, then maybe we don't 
> have an issue.  
> 
> Thanks,
> Regards,
> Jerry
>