Subject: [NSIS] jerry, dave, cornelia's proposal very confusing and not solving problem

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 03 Nov 2006 06:27:01 +0000

Hi all

After rereading the proposal of Jerry, Dave, Cornelia I have seen that the
main problem that we have had until now in the mailing discussions is not
solved. Mainly the number of mandatory parameters to interpret by all
the QNEs in the universe is not solved.

The proposal mentions in point 2) point B):

"All other QSPEC parameters are optional to include by the QNI, and may
be either mandatory or optional to interpret by downstream QNEs."

Meaning that if a QNI includes the Y.1541 class and wants that all
downstream QNEs interpret this parameter, then all downstream QNEs must
be able to strictly interpret the Y.1541 class.
Jerry, Dave, Cornelia is this true?

Meaning that all QNEs that want to use NSIS must be implemented in such a
way that if a QNI mandates the use of a parameter, e.g., Y.1541, then
the QNE must strictly interpret it, otherwise it has to reject the
parameter or the admission request.

But this is exactly the problem that we wanted to solve by having this
discussions until now. Thus the problem is not solved.

Additionaly, Jerry, Dave and Cornelia change the main concepts of QoS
based NSIS, please see my previous e-mails that I have sent yesterday on
this.

I have already proposed a solution to solve the problems that we have had
in the nsis mailing list, see a copy of that proposal below:
-------------------------

Another proposal for solving the inetroperability issue and the issue of
having too many parameters was to:
* use only one mandatory parameter, i.e., Token Bucket that could be
remapped into the peak Bandwidth parameter.
Thus except the Token Bucket parameter,
* change the QSPEC-1 parameters into QSPEC-2 parameters
* describe the remapping procedure of the Token Bucket into the peak
Bandwidth parameter in the QSPEC template draft.

After that we can submit the QSPEC template draft for last WG call. If
after the deployment phase we conclude that more mandatory parameters
are needed for interoperability then we could work on an interworking
draft.

--------------

Best Regards,
Georgios

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 3 Nov 2006 10:55:25 +0200 (EET)

Hi,

AFAICT, if the QNI _really_ wants to have an Y.1541 class supported 
(mandatory) and a QNE on the path does not support that, the reservation 
will be rejected. Tough luck for the QNI. This forces QNIs to be quite 
conservative in what they ask to be "mandatory" on the path, and suggests 
that all parameters in category B should in fact be optional.

If a QNI sets too many, and too complex mandatory objects, then it will 
not get an e2e reservation, simple.

The RMD, or any other QoS spec, does not need to support all wierd 
requests from QNIs.

Is that what the JCD-team are proposing?

Jukka

---

From: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Fri, 3 Nov 2006 04:38:54 -0600

Georgios, 

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 1:27 AM
> To: [email-masked]
> Subject: [NSIS] jerry, dave,cornelia's proposal very 
> confusing and not solving problem
> 
> Hi all
> 

It is solved.  There is only one mandatory parameter that must be
interpreted by all QNE/RMFs (traffic description = TMOD).  All other
parameters are optional to interpret and can be ignored by a QNE/RMF.
I.e., there is only one 'qspec1' parameter (although qspec1/qspec2
terminology is no longer used).
 
> Jerry, Dave, Cornelia is this true?

No.  If the Y.1541 parameter is populated by the QNI and the QNE does
not support the Y.1541 parameter then:
A) if the M flag is set by the QNI for the Y.1541 parameter, the QNE
sets the N flag for the Y.1541 parameter and rejects the reservation
B) if the M flag is not set by the QNI for the Y.1541 parameter, the QNE
sets the N flag for the Y.1541 parameter and optionally either accepts
or rejects the reservation (i.e., the QNE can simply ignore the Y.1541
parameter).
 
> discussions until now. Thus the problem is not solved.

I disagree.  All parameters except TMOD can be *not-supported* by a QNE.
If a QNI truly wants according to its QoS procedure being implemented
that a parameter must be interpreted or rejected, then no other outcome
makes sense other than to reject the reservation if a parameter is not
supported.  The QNI governs the QoS outcome of the reservation.

The proposal is also similar to an earlier suggestion (by Roland?) that
a QNI can decide which parameters are mandatory to interpret.
 
> Additionally, Jerry, Dave and Cornelia change the main concepts of QoS
> Another proposal for solving the interoperability issue and 
> the issue of

It is equivalent.  If you change Y.1541 to qspec2 and a QNE doesn't
support Y.1541, it sets the N flag and ignores the parameter.  This is
the same as the proposal as long as the QNI doesn't care whether Y.1541
is supported.  However, if the QNI does care that Y.1541 is supported,
it will reject/tear the reservation if the N flag is set.  The result is
the same as the proposal!

Jerry

---

From: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Fri, 3 Nov 2006 04:40:43 -0600

Jukka, 

> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 3:55 AM
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [NSIS] jerry, dave, cornelia's proposal very 
> The RMD, or any other QoS spec, does not need to support all weird 
> requests from QNIs.
> 

Yes, exactly, well phrased.  There is only one mandatory parameter that
all QNE/RMFs must support and are required to interpret (traffic
description = TMOD).

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 12:09:53 +0100

Hi Jerry

Thank you for the clarification!
Regarding the interpretation of the token bucket parameter 
I have another problem on understanding your proposal.

In your proposal you say:
>The TMOD parameter is a mathematically complete way to describe a 
>traffic source.  Examples will be given for setting TMOD to correspond 
>to specific cases, e.g. where only bandwidth is available (r=p; b and m 
>set to default values) and other cases (e.g., TCP).  As such, the 
>bandwidth parameter is eliminated.

Does the above mean that in specific cases a QNE can interpret only the
Token Bucket 
peak bandwdith parameter and ignore all the other Token Bucket parameters?

1) If the above is true, then how a QNI could know that a QNE used only the
Token Bucket 
Peak bandwidth parameter and another QNE used all the Token Bucket
paremeters?

2) If the above is not true then it means that a QoS model that needs to use
only 
the Token Bucket peak bandwidth parameter it will not be able to use 
the token bucket specification, thus it will not be able to use NSIS.

Which of the two alternatives is the right one?

Best Regards,
Georgios

> From: Ash, Gerald R (Jerry), NPE [mailto:[email-masked]] 
> Sent: vrijdag 3 november 2006 11:39
> To: Georgios Karagiannis; [email-masked]
> Cc: Ash, Gerald R (Jerry), NPE
> Subject: RE: [NSIS] jerry, dave,cornelia's proposal very 
> > After rereading the proposal of Jerry, Dave, Cornelia I 
> have seen that 
> > the main problem that we have had until now in the mailing 
> discussions 
> > is not solved. Mainly the number of mandatory parameters to 
> interpret 
> > by all the QNEs in the universe is not solved.
> 
> It is solved.  There is only one mandatory parameter that 
> must be interpreted by all QNE/RMFs (traffic description = 
> TMOD).  All other parameters are optional to interpret and 
> can be ignored by a QNE/RMF.
> I.e., there is only one 'qspec1' parameter (although 
> qspec1/qspec2 terminology is no longer used).
>  
> > "All other QSPEC parameters are optional to include by the QNI, and 
> > may be either mandatory or optional to interpret by 
> downstream QNEs."
> > 
> > downstream QNEs interpret this parameter, then all downstream QNEs 
> > must be able to strictly interpret the Y.1541 class.
> No.  If the Y.1541 parameter is populated by the QNI and the 
> QNE does not support the Y.1541 parameter then:
> A) if the M flag is set by the QNI for the Y.1541 parameter, 
> the QNE sets the N flag for the Y.1541 parameter and rejects 
> the reservation
> B) if the M flag is not set by the QNI for the Y.1541 
> parameter, the QNE sets the N flag for the Y.1541 parameter 
> and optionally either accepts or rejects the reservation 
> (i.e., the QNE can simply ignore the Y.1541 parameter).
>  
> > Meaning that all QNEs that want to use NSIS must be implemented in 
> > such a way that if a QNI mandates the use of a parameter, e.g., 
> > Y.1541, then the QNE must strictly interpret it, otherwise 
> it has to 
> > reject the parameter or the admission request.
> > 
> If a QNI truly wants according to its QoS procedure being 
> implemented that a parameter must be interpreted or rejected, 
> then no other outcome makes sense other than to reject the 
> reservation if a parameter is not supported.  The QNI governs 
> the QoS outcome of the reservation.
> 
> The proposal is also similar to an earlier suggestion (by 
> Roland?) that a QNI can decide which parameters are mandatory 
> to interpret.
>  
> > based NSIS, please see my previous e-mails that I have sent 
> yesterday 
> > on this.
> > 
> > I have already proposed a solution to solve the problems 
> that we have 
> > had in the nsis mailing list, see a copy of that proposal below:
> the issue 
> > of having too many parameters was to:
> It is equivalent.  If you change Y.1541 to qspec2 and a QNE 
> doesn't support Y.1541, it sets the N flag and ignores the 
> parameter.  This is the same as the proposal as long as the 
> QNI doesn't care whether Y.1541 is supported.  However, if 
> the QNI does care that Y.1541 is supported, it will 
> reject/tear the reservation if the N flag is set.  The result 
> is the same as the proposal!
> 
> Jerry
>

---

From: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Fri, 3 Nov 2006 06:59:53 -0600

Georgios, 

> Sent: Friday, November 03, 2006 6:10 AM
> To: Ash, Gerald R (Jerry), NPE; [email-masked]
> peak bandwidth parameter and ignore all the other Token 
> Bucket parameters?
> 
> parameters?

If the QNI intends that only bandwidth be specified to describe the
traffic source then it sets TMOD with r=p and b/m to default values.  If
the QNI intends that a token bucket be specified to describe the traffic
source then it sets the 4 parameters accordingly.  

The QNE is obliged to (strictly) interpret TMOD as specified by the QNI.
There is no remapping to override or replace the intent of the QNI.

Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 14:09:20 +0100

Hi Jerry

So the alternative 2) holds, meaning:
 2) If the above is not true then it means that a QoS model 
that needs to use only the Token Bucket peak bandwidth parameter it will not
be 
able to use the token bucket specification, thus it will not be able 
to use NSIS.

Thanks for the clarification!
This means that Diffserv based QoS models that need to use only bandwidth 
will not be able to use NSIS.

I really do not understand what kind of proposal is this??????

Best regards,
Georgios

> Sent: vrijdag 3 november 2006 14:00
> > Regarding the interpretation of the token bucket parameter I have 
> > another problem on understanding your proposal.
> > 
> > Does the above mean that in specific cases a QNE can interpret only 
> > the Token Bucket peak bandwidth parameter and ignore all the other 
> > Token Bucket parameters?
> > 
> > 1) If the above is true, then how a QNI could know that a QNE used 
> > only the Token Bucket Peak bandwidth parameter and another QNE used 
> > all the Token Bucket parameters?
> > 
> > 2) If the above is not true then it means that a QoS model 
> that needs 
> > to use only the Token Bucket peak bandwidth parameter it 
> will not be 
> > able to use the token bucket specification, thus it will 
> not be able 
> > to use NSIS.
> > 
> > 
> If the QNI intends that only bandwidth be specified to 
> describe the traffic source then it sets TMOD with r=p and 
> b/m to default values.  If the QNI intends that a token 
> bucket be specified to describe the traffic source then it 
> sets the 4 parameters accordingly.  
> 
> > > No.  If the Y.1541 parameter is populated by the QNI and the QNE 
> > > does not support the Y.1541 parameter then:
> parameter, the 
> > > QNE sets the N flag for the Y.1541 parameter and 
> optionally either 
> > > accepts or rejects the reservation (i.e., the QNE can 
> simply ignore 
> > > the Y.1541 parameter).
> > >  
> > > implemented that a parameter must be interpreted or 
> rejected, then 
> > > no other outcome makes sense other than to reject the 
> reservation if 
> > > a parameter is not supported.  The QNI governs the QoS outcome of 
> > > the reservation.
> > > 
> > > Roland?) that a QNI can decide which parameters are mandatory to 
> > > interpret.
> > >  
> > > support Y.1541, it sets the N flag and ignores the 
> parameter.  This 
> > > is the same as the proposal as long as the QNI doesn't 
> care whether 
> > > Y.1541 is supported.  However, if the QNI does care that 
> Y.1541 is 
> > > supported, it will reject/tear the reservation if the N 
> flag is set.  
> > > The result is the same as the proposal!
> > > 
> > > Jerry
> > >

---

From: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Fri, 3 Nov 2006 07:30:52 -0600

Georgios, 

> Sent: Friday, November 03, 2006 8:09 AM

If a QNI wants to specify TMOD as bandwidth only, there is a way to do
that as I said (see below in my previous email).  This has nothing to do
with DiffServ, I think you mean it doesn't work with the way you've
specified RMD and therefore you don't like it.
 
> I really do not understand what kind of proposal is this??????

Token bucket has always been a qspec1/mandatory parameter, and must be
interpreted as a token bucket.  That has not changed!

It seems you want RMD to ignore token bucket also and only have
bandwidth for RMD.

Please note, NSIS isn't being designed around RMD.  Please try to think
how RMD might work within the proposal rather than rejecting things that
don't immediately fit.  It might just be possible if you gave it a
little more thought.

Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 14:38:00 +0100

Hi Jerry

RMD-QOSM used the NSIS features that have been approved by NSIS WG and IESG,
see 
RFC3762.

Your proposal is not right, since it does not comply to RFC 3762.

So maybe you should think on redrawing your proposal!

Best Regards,
Georgios

> Sent: vrijdag 3 november 2006 14:31
> > This means that Diffserv based QoS models that need to use only 
> > bandwidth will not be able to use NSIS.
> 
> If a QNI wants to specify TMOD as bandwidth only, there is a 
> way to do that as I said (see below in my previous email).  
> This has nothing to do with DiffServ, I think you mean it 
> doesn't work with the way you've specified RMD and therefore 
> you don't like it.
>  
> Token bucket has always been a qspec1/mandatory parameter, 
> and must be interpreted as a token bucket.  That has not changed!
> 
> It seems you want RMD to ignore token bucket also and only 
> have bandwidth for RMD.
> 
> Please note, NSIS isn't being designed around RMD.  Please 
> try to think how RMD might work within the proposal rather 
> than rejecting things that don't immediately fit.  It might 
> just be possible if you gave it a little more thought.
> 
> Jerry
>  
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> describe the 
> > > traffic source then it sets TMOD with r=p and b/m to 
> default values.  
> > > If the QNI intends that a token bucket be specified to 
> describe the 
> > > traffic source then it sets the 4 parameters accordingly.
> > > 
> > > The QNE is obliged to (strictly) interpret TMOD as 
> specified by the 
> > > QNI.

---

From: Roland Bless <[email-masked]>
Date: Fri, 03 Nov 2006 15:57:55 +0100

Hi Georgios,

> will not be able to use NSIS.

I guess that there is a lack of understanding DiffServ here.
DiffServ is not restricted to EF-based services only. If you
perform admission control based on the peak rate only, it's
your engineering decision. Some other people may take a look
at the whole token bucket parameters and achieve higher utilization.
It's up to the signaled constraints and your local QoS model.
For other services you might be more interested in the burstiness of the
traffic, too. Depending on the constraints that are signaled,
you are free to map the request into any appropriate DiffServ
class (PDB/PHB set) that is able to meet the signaled constraints.
So I guess the new proposal is very well suited to support also
DiffServ-based QoS support in domains.

> I really do not understand what kind of proposal is this??????

If you care about stacking:
Why not defining your own QSPEC that allows to carry your
domain-specific parameters as well as the original encapsulated
external QSPEC. This would be a form of encapsulation, but it
could probably be used instead of stacking.

Regards,
 Roland

---

From: <[email-masked]>
Date: Fri, 3 Nov 2006 17:01:16 +0200

Georgios,

>RMD-QOSM used the NSIS features that have been approved by 
>NSIS WG and IESG, see RFC3762.
>

RFC3762 is "Telephone Number Mapping (ENUM) Service Registration for
H.323"
Which document do you really mean?

http://www.ietf.org/rfc/rfc3762.txt?number=3762

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 16:17:24 +0100

Hi John

Sorry, I meant RFC 3726, see below:
http://www.ietf.org/rfc/rfc3726.txt
 
Best Regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 3 november 2006 16:01
> To: [email-masked]; [email-masked]; [email-masked]
> RFC3762 is "Telephone Number Mapping (ENUM) Service 
> Registration for H.323"

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 16:27:32 +0100

Hi Roland

Please see in line!

> From: Roland Bless [mailto:[email-masked]] 
> Sent: vrijdag 3 november 2006 15:58
> To: Georgios Karagiannis
> Cc: 'Ash, Gerald R (Jerry), NPE'; [email-masked]
> confusing and notsolving problem
> 
> Hi Georgios,
> 
> For other services you might be more interested in the 
> burstiness of the traffic, too. Depending on the constraints 
> that are signaled, you are free to map the request into any 
> appropriate DiffServ class (PDB/PHB set) that is able to meet 
> the signaled constraints.
> So I guess the new proposal is very well suited to support 
> also DiffServ-based QoS support in domains.

Georgios: I agree, but it can not be used in all types of Diffserv based
domains.
The proposal restricts the possibility on performing admission control 
based on the peak rate only! That is my problem!
The proposal does not allow this kind of flexibility that 
we wanted to have in NSIS.
I remember some severe discussions on this point some years ago where we
came up
with the possibility on supporting both Token Bucket and Bandwidth
parameters.

> domain-specific parameters as well as the original 
> encapsulated external QSPEC. This would be a form of 
> encapsulation, but it could probably be used instead of stacking.

Georgios: 
This is what I want to do with stacking. Stack/encapsulate a RMD-QSPEC above
an end-to-end 
QSPEC. This is however not allowed in this proposal.

Best Regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Fri, 03 Nov 2006 17:11:31 +0100

Hi Georgios,

> with the possibility on supporting both Token Bucket and Bandwidth

I can only agree with Dave here, that bandwidth only
without specifying any time period is not really usable.

> QSPEC. This is however not allowed in this proposal.

It is allowed if you define your own RMD-QSPEC
with an encapsulation method for an e2e QSPEC.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 17:17:13 +0100

Hi Roland

> I can only agree with Dave here, that bandwidth only without 
> specifying any time period is not really usable.

Georgios: In many environments it is which will benefit
from such features.

> It is allowed if you define your own RMD-QSPEC with an 
> encapsulation method for an e2e QSPEC.

Georgios: Well, probably yes, but then all QNEs in the local domain will
have to inspect all 
QSPEC parameters including the e2e QSPEC parameters.

Best regards,
Georgios

> Sent: vrijdag 3 november 2006 17:12
> To: Georgios Karagiannis
> > Georgios: I agree, but it can not be used in all types of Diffserv 
> > based domains.
> > I remember some severe discussions on this point some years 
> ago where 
> > we came up with the possibility on supporting both Token Bucket and 
> > Bandwidth parameters.
> 
> I can only agree with Dave here, that bandwidth only without 
> specifying any time period is not really usable.
> 
> >> external QSPEC. This would be a form of encapsulation, but 
> it could 
> >> probably be used instead of stacking.
> > 
> > Georgios: 
> > This is what I want to do with stacking. Stack/encapsulate 
> a RMD-QSPEC 
> > above an end-to-end QSPEC. This is however not allowed in this 
> > proposal.
> 
> It is allowed if you define your own RMD-QSPEC with an 
> encapsulation method for an e2e QSPEC.
> 
> Regards,
>  Roland
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 03 Nov 2006 17:26:58 +0100

Hi Georgios,

> QSPEC parameters including the e2e QSPEC parameters.

I don't see any problem here, you can simply skip/ignore the
encapsulated e2e QSPEC object just as you ignore the other
stacked QSPEC in the earlier proposal.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 17:29:51 +0100

Hi Roland

But what you propose is just stacking, but with another name, i.e., 
encapsulation.
I do not think that the new proposal allows this.

Best Regards,
Georgios

> Sent: vrijdag 3 november 2006 17:27
> To: Georgios Karagiannis
> > Georgios: Well, probably yes, but then all QNEs in the local domain 
> > will have to inspect all QSPEC parameters including the e2e QSPEC 
> > parameters.
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 03 Nov 2006 17:35:08 +0100

Hi Georgios,

> I do not think that the new proposal allows this.

It's independent of the new proposal. The new QSPEC proposal
is not required to support this.
You can specify this simply and independently of other QSPECs
within your own RMD-QSPEC. No need to put it in the new e2e QSPEC.

Regards
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 3 Nov 2006 17:38:59 +0100

Hi Roland

I think it is beter to discuss this on Sonday!

What you actually say is that stacking is allowed but 
it is not specified in the QSPEC template draft.
Okay, but it then should be specified in the QoS-NSLP 
draft and in the QOSM model drafts.

Best Regards,
Georgios

> Sent: vrijdag 3 november 2006 17:35
> To: Georgios Karagiannis

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Nov 2006 11:15:26 -0800

On Nov 2, 2006, at 10:27 PM, Georgios Karagiannis wrote:
> may

If I may point out a problem...

Generally speaking, optional capabilities create a diode. Some of us  
will recall the antics os the ISO protocol suite in the 1980's. It  
was in many ways a good piece of work, and there are some bits (IS-IS  
and ASN.1 come to mind, and the conceptual carry-over of ES-IS into  
IPv6 ND) that are still in use. The big thing that made it hard to  
use and ultimately triggered its collapse was the optional sets of  
parameters - every product built was compliant under some profile of  
selected options or another, but few were really interoperable. As a  
result, at the end of the day the solution didn't work.

With something where one has multiple products from multiple vendors  
that wind up constituting a set of needles that a transaction has to  
simultaneously thread, optional capabilities are a real liability. In  
the end, it is the mandatory-to-implement-and-use subset that will be  
interoperable end to end.

I would really suggest that we use optional capabilities as an  
upgrade path - if someone doesn't understand an option it will be  
passed along unchanged - but in the general case avoid optional  
capabilities like the plague.

---

From: David R Oran <[email-masked]>
Date: Fri, 3 Nov 2006 22:04:31 -0500

> DiffServ-based QoS support in domains.
YES! Extremely well put. Thank you.

---

From: Jukka MJ Manner <[email-masked]>
Date: Sun, 5 Nov 2006 21:29:11 +0200 (EET)

Hi,

Just a note about the QSPEC discussion. We should make it clear what is a 
QSPEC issue, and what is an NSLP issue.

1. The lists of parameters, optional/mandatory, and how a QNE processes 
  them is a QSPEC issue.

2. Stacking is an NSLP feature.

Thus, it would be good, if the current discussions are structured 
(e.g. today at the meeting at 3pm) based on 

A) Issues with the current proposal for QSPEC

B) Issues with the current proposal for QoS NSLP

Jukka