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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 21 Oct 2005 10:12:49 -0500

Hi Georgios,

Thanks for your detailed example, I think this is a good way to resolve
the issue.

> I see that this discussion does not lead anywhere!
> Maybe is a good idea to have a lot of discussions in
> Vancouver related to this issue!

OK, but let's continue on the list, and see if we can make progress.
 
> Regarding the packet classifier used in the QoS-NSLP, the 
> packet classifier should know what kind of filtering should
> use on the user data packets. This is because the created
> QoS-NSLP (RMF) reservation states (not the QoS-NSLP
> operational states) have to be associated with the user data
> packets passing through the node. Otherwise no QoS support
> can be provided.
> 
> For example:
> *  in a Intserv based model, the flow ID will be used to 
> filter the user data packets and associate them with the
> Intserv based RMF reservation state
> * in another QoS model, the combination of IP source address 
> and DSCP might be used to filter the user data packets
> and associate them with the RMF reservation state
> 
> The packet classifier can get this knowledge by:
> * local policy, configuring the node to associate the RMF 
> reservation state with all user data packets that are
> filtered based on a predefined and configured rule
> * using signaling:
> For this case consider the following:
> two QoS models, say QoS model A (that goes end-to-end) and 
> QoS model B (that goes locally: edge-to-edge) are used for
> the same session on an end to end path.
> The QNE that activates the signaling related to QoS model 
> A generates a RESERVE and is including the QSPEC (A) and
> it is also including the type of the packet classifier
> used (packet classifier (A), say flow ID.

So the QNE gets the packet_classifier information from where?  It seems
it still has to be configured according to the QoS model A that the QNE
is using, right?

> All the intermediate nodes that use QoS model (A) will 
> have to use QSPEC (A) and the packet classifier (A).
> On the end-to-end path the same session (and RESERVE 
> message) passes through a local QoS model, say QoS model B.
> In this case the QNE at the edge of the domain that
> supports the QoS model B, will have to stack its QSPEC (B)
> on top of QSPEC (A). At the same time this QNE will have to 
> include the packet classifier (B), information related to
> QoS model B, say combination of IP source address and DSCP,
> in the RESERVE message, in such a way that packet classifier
> (A) is not destroyed.

Same question the QNE gets the packet_classifier information from where?
It seems it still has to be configured according to the QoS model B that
the QNE is using, right?

> All the intermediate nodes that use QoS model B will have 
> to use QSPEC (B) and packet classifier (B).  The QNE located
> at the other edge of the domain that supports the QoS model
> B,  will have to remove QSPEC (B) and the packet classifier
> (B) from the RESERVE message.
> 
> As you can see the packet classifier information and the 
> QSPEC are very much dependent to each other.  Thus there is
> a one to one matching between the packet classifier and the 
> QSPEC.

So each QOSM I-D needs to specify what packet_classifier it will use?

> This means that the NSIS protocol suite needs to support 
> the following functionalities:
>   * packet classifier (B) information should not destroy the packet 
> classifier (A) information
>   * The packet classifier, say packet classifier (A), associated
> with a QSPEC, say QSPEC (A),  must only be used in the domains that
> are using QSPEC (A).
>   * If a QoS model does not recognize a QSPEC, say QSPEC (A) 
> then it should not do anything with its associated packet classifier,
> say packet classifier (A).
> 
> If the packet classifier information will be included in the QSPEC,
> then all the above functionalities are already provided!

Let's see if others agree with this?

Thanks,
Regards,
Jerry

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 22 Oct 2005 08:58:06 +0200 (MEST)

Hi Jerry

Please see in line!

>it still has to be configured according to the QoS model A that the QNE

Georgios: Yes, you are right, it has to be configured according to the
QoS model A, that QNE is using

>It seems it still has to be configured according to the QoS model B that

Georgios: Yes, you are right, it has to be configured according to the
QoS model B, that QNE is using

>So each QOSM I-D needs to specify what packet_classifier it will use?

Georgios: Yes, you are right, each QoSM I-D nees to specify what packet
classifier it will use!

>Let's see if others agree with this?

Best Regards,
Georgios

---

From: David R Oran <[email-masked]>
Date: Mon, 24 Oct 2005 08:57:14 -0400

>> Thanks for your detailed example, I think this is a good way to  
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: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 24 Oct 2005 22:14:55 +0200 (MEST)

Hi Dave

Please see in line!

>simple stacking of QSPECS in a single reservation/session.

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

>that I'm not sure I can engage in a rational engineering tradeoff

Georgios: I do not see any additional complexity in the NSIS protocol
suite if the packet classifier will just become an additional QSPEC
parameter.

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Tue, 25 Oct 2005 16:34:05 +0100

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

regards,
Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 25 Oct 2005 18:25:27 +0200

Hi Andrew

Please see in line!

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

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

_______

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 26 Oct 2005 09:50:16 +0100

Georgios Karagiannis wrote:
>> The different packet classifiers may be a sign that we should be using 
>> a different signalling session.
>>

OK. Examples based on using "flow ID" in one classifier, and "DSCP" in 
another had obviously misled me. I've may have got lost in the ebbs and 
flows of this thread.

However, that doesn't change my concluding thought - in fact it probably 
reinforces it, since I haven't seen any compelling examples of why 
multiple packet classifiers are required.

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

There is a fairly significant difference between signalling this 
information and leaving it up to individual nodes. Particular issues 
that come to mind:
- if you don't signal it then the QNI doesn't know what traffic will be 
treated as part of the reservation it is requesting
- it makes the definition of whether two signalling messages are about 
the same flow a local configuration (or QoS model dependent) issue
- there may be authorisation issues, in terms of what 
traffic/reservation is actually being requested and authorised by the 
authorisation information provided in the signalling

Consequently, I'm uncomfortable with leaving this totally up to local 
configuration.

Andrew

---

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

-//- snip
> information and leaving it up to individual nodes. Particular issues that 
> come to mind:

Georgios: why not?

> - it makes the definition of whether two signalling messages are about the 
> same flow a local configuration (or QoS model dependent) issue

Georgios:  Please see some previous e-mails in this thread. It is a QoS 
model
issue.

> - there may be authorisation issues, in terms of what traffic/reservation 
> is actually being requested and authorised by the authorisation 
> information provided in the signalling

Georgios: but if the node accepts the QSPEC then there is no problem!
 A node can process a QSPEC only if it is able to recognise it.
This means that the packet classifier is also configured.

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 26 Oct 2005 11:45:15 +0100

Hi Georgios,

some comments below

Georgios Karagiannis wrote:
> -//- snip
>>
>>> I think that the easier solution will just be to have a sentence in 
>>> the QOS-NSLP draft
>>> which says:
>>>
>> - if you don't signal it then the QNI doesn't know what traffic will 
>> be treated as part of the reservation it is requesting
> 
> Georgios: why not?
>

I think understand what the difference is between the 'pure local 
configuration' and 'QoS model defined' non-signalled packet classifier 
possibilities are. As I understand it, your suggestion is that the "QoS 
model" field in the QSpec object implicitly identifies the packet 
filtering rules.

Some issues that spring to mind:

- what happens for a QoS Model that can use different packet 
classifiers? e.g. in the Intserv controlled load case you could make a 
reservation relating to a pair of IP addresses, or one relating to the 
full 5-tuple, or ...

- allowing the local QoS Model to choose the packet classifier creates 
additional problem cases where the local view differs from the 
end-to-end view, e.g. you go into a domain where the QoS model uses the 
DSCP as part of the packet classifier, but the QNI hasn't included the 
DSCP in the MRI. You could possibly do some remarking, etc in this QoS 
model domain, but that would seem to be a situation where you should be 
using a separate signalling session.

- what happens in the case of an unknown QoS Model? There is supposed to 
be a mandatory subset of the QSpec objects which allows things to 
proceed even if the QoS model is not understood. What do these nodes use 
for the packet classifier?

regards,

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Oct 2005 14:46:16 +0200

Hi Andrew

Please see in line!

> model" field in the QSpec object implicitly identifies the packet 

Georgios: No, my last proposal is that we do not need to signal the packet 
classifier information at all!

> - what happens for a QoS Model that can use different packet classifiers? 
> e.g. in the Intserv controlled load case you could make a reservation 
> relating to a pair of IP addresses, or one relating to the full 5-tuple, 
> or ...

Georgios:  Well, in the previous e-mail discussions I have tried to make 
this very clear, please check the
previous e-mail of this tread!
Furthermore, the rules of this packet classifier should be rules that are 
related to the
information included in the header of the IP packets. Thus each QoS model 
can
specify any additional filtering rule (note that typically  it should use 
MRI parameters)
it wants assuming that these rules are related to the
fields of the IP header.
Please note that the responsability of assigning packet classifier rules is 
the responsability of the QoS model.

> allowing the local QoS Model to choose the packet classifier creates 
> additional problem cases where the local view differs from the end-to-end 
> view, e.g. you go into a domain where the QoS model uses the DSCP as part 
> of the packet classifier, but the QNI hasn't included the DSCP in the MRI. 
> You could possibly do some remarking, etc in this QoS model domain, but 
> that would seem to be a situation where you should be using a separate 
> signalling session.

Georgios: I do not think that you will have any problems. Please see my 
previous e-mails on this tread!

in the case of an unknown QoS Model? There is supposed to
> be a mandatory subset of the QSpec objects which allows things to proceed 
> even if the QoS model is not understood. What do these nodes use for the 
> packet classifier?

Georgios: This should be specified by the QoS model!

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 26 Oct 2005 17:55:23 +0100

Hi Georgios,

Georgios Karagiannis wrote:
>> possibilities are. As I understand it, your suggestion is that the 
>> "QoS model" field in the QSpec object implicitly identifies the packet 
>> filtering rules.
> 
> 
> Georgios: No, my last proposal is that we do not need to signal the 
> packet classifier information at all!

In that case I don't understand what you are proposing at the moment. I 
may have missed (or misunderstood) something in one of your previous 
e-mails.

Can you clarify what you mean when you say "It is a QoS model issue"? I 
can see two possibilities for this:
a) The packet classifier is determined by the QoS model used by the 
QSpec in the message
b) The packet classifier is determined by the node receiving a message 
based on the QoS model it supports

I thought you meant (a). Do you mean (b)? Or is it something else?

Andrew

> Furthermore, the rules of this packet classifier should be rules that 
> are related to the
> information included in the header of the IP packets. Thus each QoS 
> model can
> specify any additional filtering rule (note that typically  it should 
> use MRI parameters)
> Please note that the responsability of assigning packet classifier rules 
> is the responsability of the QoS model.
> 
> 
> 
>> end-to-end view, e.g. you go into a domain where the QoS model uses 
>> the DSCP as part of the packet classifier, but the QNI hasn't included 
>> the DSCP in the MRI. You could possibly do some remarking, etc in this 
>> QoS model domain, but that would seem to be a situation where you 
>> should be using a separate signalling session.
> 
> 
>> proceed even if the QoS model is not understood. What do these nodes 
>> use for the packet classifier?
> 
>

---

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

Hi Andrew

Please see in line!

----- Original Message ----- 
From: "Andrew McDonald" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 26, 2005 6:55 PM
Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

> a) The packet classifier is determined by the QoS model used by the QSpec 
> in the message

Georgios: Well I have been supporting a), but Cheng (NATP translation 
problems)
convinced me that we have to use the paramters of MRI as much as possible.
In addition we can allow QoS models to use local configuration of the packet 
classifier
rules.

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 27 Oct 2005 11:47:44 +0100

Hi Georgios,

Georgios Karagiannis wrote:
>>>> configuration' and 'QoS model defined' non-signalled packet 
>>>> classifier possibilities are. As I understand it, your suggestion is 
>>>> that the "QoS model" field in the QSpec object implicitly identifies 
>>>> the packet filtering rules.
>>>
>> In that case I don't understand what you are proposing at the moment. 
>> I may have missed (or misunderstood) something in one of your previous 
>> e-mails.
>>
>> Can you clarify what you mean when you say "It is a QoS model issue"? 
>> I can see two possibilities for this:
> In addition we can allow QoS models to use local configuration of the 
> packet classifier
> rules.

In that case, there was probably some confusion from the different way I 
phrased it.

When I said: "the "QoS model" field in the QSpec object implicitly 
identifies the packet filtering rules", what I was trying to say was 
that when a QNE receives a message it can look at the <QOSM ID> field in 
the QSpec header and then, based on its knowledge of the definition of 
that QoS model, it knows what packet classifier to use. i.e. the packet 
classifier is determined by the QoS model used by the QSpec in the message

Is that the way you believe it should work?

However, I'm still not sure I understand exactly what you mean by "In 
addition we can allow QoS models to use local configuration of the 
packet classifier rules.", which suggests that there may be something 
more than "just (a)".

I'm not sure my understanding of the phrase "local configuration" is the 
same as the way you are using it. Also, I'm not entirely clear how this 
works as an "addition" to (a). Could you clarify?

In any case, if (a) is (more or less) what we're talking about, then I 
do have problems with this:

>>>> classifiers? e.g. in the Intserv controlled load case you could make 
>>>> a reservation relating to a pair of IP addresses, or one relating to 
>>>> the full 5-tuple, or ...
>>>
>>> Georgios:  Well, in the previous e-mail discussions I have tried to 
>>> make this very clear, please check the
>>> Please note that the responsability of assigning packet classifier 
>>> rules is the responsability of the QoS model.

I'm not sure how much of a problem this one may be. As far as I can see, 
it means that only a single set of packet classifier rules can be 
defined for each QoS model. However, since that definition may be "all 
of the MRI" that might not be so much of a problem, since different 
packet classifiers can be created by setting different sets of fields in 
the MRI.

One thought that I haven't really worked out properly: Are there any NAT 
issues to this? i.e. might you need to set ports in the MRI to traverse 
a NAT properly, but only want to reserve traffic between a pair of 
addresses?

>>>> the DSCP as part of the packet classifier, but the QNI hasn't 
>>>> included the DSCP in the MRI. You could possibly do some remarking, 
>>>> etc in this QoS model domain, but that would seem to be a situation 
>>>> where you should be using a separate signalling session.
>>>
>>> Georgios: I do not think that you will have any problems. Please see 
>>> my previous e-mails on this tread!

At the moment I can't find any previous discussion addressing this 
particular issue.

As a more detailed example of the problem:

The QNI sets the MRI as:
(IP src, IP dst) and no other fields
And QoS Model X is used which defines the packet classifier as "all of 
the MRI", so all is well.

It reaches a QNE which is at an edge between regions where two different 
QoS models are being used. So, it stacks QoS Model Y on top.

A QNE receives the message and looks at the QSpec, and sees it is for 
QoS Model Y. The packet classifier for QoS Model Y uses a combination of 
IP source address and DSCP (to use one of your previous examples).

This is where we hit the problem: The MRI doesn't contain the DSCP.

What happens?

>>> Georgios: This should be specified by the QoS model!

Which QoS model?

For example:
- the message has a single QSpec. It says "QOSM ID = 3".
- the message is received by a QNE only understand QoS models 2 and 4.
Since it doesn't know what the packet classifier for "QOSM 3" is, what 
does it do?

regards,

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 27 Oct 2005 13:54:34 +0200

Hi Andrew

As I see, it will take us a lot of time to resolve this issue! I propose to 
disuss 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!

Best regards,
Georgios

----- Original Message ----- 
From: "Andrew McDonald" <[email-masked]>
To: "Georgios Karagiannis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 27, 2005 12:47 PM
Subject: Re: [NSIS] RE: PACKET_CLASSIFIER in QSPEC

> identifies the packet filtering rules", what I was trying to say was that 
> when a QNE receives a message it can look at the <QOSM ID> field in the 
> QSpec header and then, based on its knowledge of the definition of that 
> QoS model, it knows what packet classifier to use. i.e. the packet 
> addition we can allow QoS models to use local configuration of the packet 
> classifier rules.", which suggests that there may be something more than 
> "just (a)".
>
> In any case, if (a) is (more or less) what we're talking about, then I do 
> have problems with this:
>
> it means that only a single set of packet classifier rules can be defined 
> for each QoS model. However, since that definition may be "all of the MRI" 
> that might not be so much of a problem, since different packet classifiers 
> can be created by setting different sets of fields in the MRI.
>
> issues to this? i.e. might you need to set ports in the MRI to traverse a 
> NAT properly, but only want to reserve traffic between a pair of 
> addresses?
>
> And QoS Model X is used which defines the packet classifier as "all of the 
> MRI", so all is well.
>
> A QNE receives the message and looks at the QSpec, and sees it is for QoS 
> Model Y. The packet classifier for QoS Model Y uses a combination of IP 
> source address and DSCP (to use one of your previous examples).
>