Subject: [NSIS] Proposed Updates to the QSPEC Draft

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 1 Nov 2006 16:12:45 -0600

Hi All,

Per John's suggestion below we've discussed Dave Oran's suggestions at
length and have the following proposal.  

We think the proposed changes address many concerns raised on the list
over the last few months and will require some rather basic changes in
the QSPEC document
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-12.txt.

We appreciate Dave's suggestions and careful review of the document.

Here is a summary of the proposed changes:

1. The notion of QOSMs will be played down in the updated draft.
Language to the effect that 'QNSLP/QSPEC can signal for different QOSMs
across multiple domains' will be replaced by the notion that QNSLP/QSPEC
allows different elements on the path to implement different data plane
QoS mechanisms that meets the constraints included in the QSPEC.  A QOSM
describes common capabilities among QNEs to act consistently when
requested to admit traffic and in treating admitted traffic.  A QOSM ID
need not be defined or signaled and a QNE need not support any
particular QOSM.  A 'QOSM specification' would become a 'QNSLP/QSPEC
applicability statement', which documents how a QNE/RMF interprets and
treats the various elements in a QSPEC.  

An updated QOSM definition is as follows:

QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g.,
IntServ Controlled Load.  A QOSM specifies what sub-set of QSPEC QoS
constraints and traffic handling directives a QNE implementing that QOSM
is capable of supporting and how resources will be managed by the RMF in
such a QNE.

2. The QSPEC1/QSPEC2 semantics will be replaced with Dave's a) --> d)
semantics:
A) The source traffic description is mandatory to include by the QNI and
mandatory to interpret by downstream QNEs.  The traffic description is
specified by a traffic model (TMOD) parameter consisting of 4
sub-parameters:
- rate (r)
- bucket size (b)
- peak rate (p)
- minimum policed unit (m)
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.
B) All other QSPEC parameters are optional to include by the QNI, and
may be either mandatory or optional to interpret by downstream QNEs.
That is, the QNI can explicitly specify for each constraint parameter
whether it wishes admission control to succeed or fail if that
constraint cannot be met.  A downstream QNE distinguishes whether it is
failure to understand the parameter or failure to meet the constraint
that causes the admission control failure (more detail on this below).
C) Additional QSPEC parameters can be defined in updates to the QSPEC
document (or alternatively specified in QOSM applicability statement
documents).  There is already an IANA registry established for
additional QSPEC parameters.

3. The concept of remapping QSPEC parameters is eliminated.  This
concept is ill defined and has caused much confusion (there are few if
any sensible remappings).  Rather we define 'interpret' a QSPEC
parameter to only mean what we now call 'strictly interpret' (i.e., must
conform to the RFCs defining the parameter and procedures) and eliminate
the remap option part of 'interpret'.

4. Since remapping is eliminated, the concept of stacking QSPECs is also
eliminated.  Discussion of tunneling of QNSLP messages is eliminated
since there are no impacts on tunneling required by QSPEC.

5. Current QSPEC flags are modified as follows:
A) The QNI sets the M flag for each QSPEC parameter it populates that it
intends must be interpreted or the reservation fails.  Currently the M
flag is statically set for every QSPEC parameter.
B) If the M flag is set, a downstream QNE must interpret the parameter
or the reservation fails.  If a QNE does not support the parameter with
the M flag set, it sets the N flag and rejects the reservation.  If the
QNE supports the parameter but cannot meet the parameter, it sets the E
flag and rejects the reservation. 
C) If the M flag is not set, a downstream QNE should interpret the
parameter.  If a QNE does not support the parameter, it sets the N flag
and can optionally accept or reject the reservation.  If a QNE supports
the parameter but cannot meet the parameter, it sets the E flag and
optional accepts or rejects the reservation.
D) The R (remapped parameter) flag and Q (non QOSM) flag are eliminated.

6. Summary of proposed QSPEC parameters:

Source traffic Description:
 TMOD-1 (mandatory to include)
 TMOD-2 (optional to include)

Constraints (optional to include):
 Path Latency
 Path Jitter
 Path PLR
 Path PER
 Y.1541 class (shorthand notation for above 4 parameters)
 Slack term
 Priority (Preemption, Defending, Admission, RPH Priority)
 DSTE class

Handling directives (optional to include):
 excess treatment

Traffic Classifiers (optional to include):
 PHB Class (note that PHB class is set by downstream QNE to tell QNI how
to mark traffic to ensure it will be treated as committed by admission
control)

Eliminated:
 bandwidth
 Ctot, Dtot, Csum, Dsum

7. Editorial changes:
A) rewrite description of read-only and read-write parameters to make
the rules more clear: 
- which parameters can be ro/rw (function of object in which parameter
included)
- can only increase rw values and not delete, etc.
B) eliminate the distinction of 'control' and 'qos description'
parameters and replace with suggested taxonomy, as described above
C) clarify discussion of packet outcomes from Y.1540 and place in
appropriate sections
D) clarify which parameters can be included in <QoS Desired> <QoS
Available>, <QoS Reserved>, or <QoS Minimum>

Please review and comment on the proposed changes.

Thanks,
Jerry, Dave, Cornelia

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 2:59 AM
To: [email-masked]
Subject: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft

Hi all,

We have had a very large thread on the current
draft-ietf-nsis-qspec-12.txt draft.  We don't have a clear consensus, so
I'd like to try to summarize the discussions.

Several people feel that the current draft contains too many mandatory
parameters and mapping some QoS Models to others is mixing
apples-to-oranges.  The feeling is that interoperability is hard to
achieve and therefore we should not try to gain interoperability.  Jukka
Manner's message on 17th of October proposed a way forward.
http://www1.ietf.org/mail-archive/web/nsis/current/msg06919.html

However, several (other) people feel that interoperability is important
and is needed. Giving up on interoperability would not be a good thing,
and that we are very close to a solution.  Dave Oran proposed a
mechanism to reach a solution on the 19th October:
http://www1.ietf.org/mail-archive/web/nsis/current/msg06962.html

I have asked Jerry and Dave to make a proposal along the lines of Dave's
message above, and the working group can review this, to see if we can
gain consensus on this.  I think it would be sufficient to send some
rough text to the mailing list, and if this is OK, then we can revise
the draft.

One open question to Dave/Jerry about the proposal is, in the event that
the source cannot be described a mathematically complete way, is there
any value (or does it make any sense at all) in sending an incomplete
qspec, or potentially "wildcarding" sending some of the mandatory
parameters.  I'm wondering if some sources / deployments may have
certain parameters that are relatively well defined, but not all are so
well defined.

thanks,
John

_______________________________________________
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: Jukka MJ Manner <[email-masked]>
Date: Thu, 2 Nov 2006 00:25:40 +0200 (EET)

Hi all,

After a first read through the proposed changes, I have a good fealing 
about this. I still have to re-read and think about the proposal a few 
times more, but my first impression was very positive. :)

As QoS NSLP editor and author, I'll need to remove the notion of QSPEC 
stacking from the NSLP spec, right?

Regards,
Jukka

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 Nov 2006 08:23:26 +0100

Thanks for agreeing on such a pragmatic approach. As Jukka, 
my impression by reading your message was a pretty good 
one too.

Regards,

Rudiger

|-----Original Message-----
|From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
|Sent: Wednesday, November 01, 2006 11:13 PM
|To: [email-masked]
|Cc: Ash, Gerald R (Jerry), ALABS; Cornelia Kappler; David R Oran;
|Kappler, Cornelia
|Subject: [NSIS] Proposed Updates to the QSPEC Draft
|
|
|Hi All,
|
|Per John's suggestion below we've discussed Dave Oran's suggestions at
|length and have the following proposal.  
|
|We think the proposed changes address many concerns raised on the list
|over the last few months and will require some rather basic changes in
|the QSPEC document
|http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-12.txt.
|
|We appreciate Dave's suggestions and careful review of the document.
|
|Here is a summary of the proposed changes:
|
|1. The notion of QOSMs will be played down in the updated draft.
|Language to the effect that 'QNSLP/QSPEC can signal for different QOSMs
|across multiple domains' will be replaced by the notion that 
|QNSLP/QSPEC
|allows different elements on the path to implement different data plane
|QoS mechanisms that meets the constraints included in the 
|QSPEC.  A QOSM
|describes common capabilities among QNEs to act consistently when
|requested to admit traffic and in treating admitted traffic.  A QOSM ID
|need not be defined or signaled and a QNE need not support any
|particular QOSM.  A 'QOSM specification' would become a 'QNSLP/QSPEC
|applicability statement', which documents how a QNE/RMF interprets and
|treats the various elements in a QSPEC.  
|
|An updated QOSM definition is as follows:
|
|QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g.,
|IntServ Controlled Load.  A QOSM specifies what sub-set of QSPEC QoS
|constraints and traffic handling directives a QNE implementing 
|that QOSM
|is capable of supporting and how resources will be managed by 
|the RMF in
|such a QNE.
|
|2. The QSPEC1/QSPEC2 semantics will be replaced with Dave's a) --> d)
|semantics:
|A) The source traffic description is mandatory to include by 
|the QNI and
|mandatory to interpret by downstream QNEs.  The traffic description is
|specified by a traffic model (TMOD) parameter consisting of 4
|sub-parameters:
|- rate (r)
|- bucket size (b)
|- peak rate (p)
|- minimum policed unit (m)
|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.
|B) All other QSPEC parameters are optional to include by the QNI, and
|may be either mandatory or optional to interpret by downstream QNEs.
|That is, the QNI can explicitly specify for each constraint parameter
|whether it wishes admission control to succeed or fail if that
|constraint cannot be met.  A downstream QNE distinguishes whether it is
|failure to understand the parameter or failure to meet the constraint
|that causes the admission control failure (more detail on this below).
|C) Additional QSPEC parameters can be defined in updates to the QSPEC
|document (or alternatively specified in QOSM applicability statement
|documents).  There is already an IANA registry established for
|additional QSPEC parameters.
|
|3. The concept of remapping QSPEC parameters is eliminated.  This
|concept is ill defined and has caused much confusion (there are few if
|any sensible remappings).  Rather we define 'interpret' a QSPEC
|parameter to only mean what we now call 'strictly interpret' 
|(i.e., must
|conform to the RFCs defining the parameter and procedures) and 
|eliminate
|the remap option part of 'interpret'.
|
|4. Since remapping is eliminated, the concept of stacking 
|QSPECs is also
|eliminated.  Discussion of tunneling of QNSLP messages is eliminated
|since there are no impacts on tunneling required by QSPEC.
|
|5. Current QSPEC flags are modified as follows:
|A) The QNI sets the M flag for each QSPEC parameter it 
|populates that it
|intends must be interpreted or the reservation fails.  Currently the M
|flag is statically set for every QSPEC parameter.
|B) If the M flag is set, a downstream QNE must interpret the parameter
|or the reservation fails.  If a QNE does not support the parameter with
|the M flag set, it sets the N flag and rejects the reservation.  If the
|QNE supports the parameter but cannot meet the parameter, it sets the E
|flag and rejects the reservation. 
|C) If the M flag is not set, a downstream QNE should interpret the
|parameter.  If a QNE does not support the parameter, it sets the N flag
|and can optionally accept or reject the reservation.  If a QNE supports
|the parameter but cannot meet the parameter, it sets the E flag and
|optional accepts or rejects the reservation.
|D) The R (remapped parameter) flag and Q (non QOSM) flag are 
|eliminated.
|
|6. Summary of proposed QSPEC parameters:
|
|Source traffic Description:
| TMOD-1 (mandatory to include)
| TMOD-2 (optional to include)
|
|Constraints (optional to include):
| Path Latency
| Path Jitter
| Path PLR
| Path PER
| Y.1541 class (shorthand notation for above 4 parameters)
| Slack term
| Priority (Preemption, Defending, Admission, RPH Priority)
| DSTE class
|
|Handling directives (optional to include):
| excess treatment
|
|Traffic Classifiers (optional to include):
| PHB Class (note that PHB class is set by downstream QNE to 
|tell QNI how
|to mark traffic to ensure it will be treated as committed by admission
|control)
|
|Eliminated:
| bandwidth
| Ctot, Dtot, Csum, Dsum
|
|7. Editorial changes:
|A) rewrite description of read-only and read-write parameters to make
|the rules more clear: 
|- which parameters can be ro/rw (function of object in which parameter
|included)
|- can only increase rw values and not delete, etc.
|B) eliminate the distinction of 'control' and 'qos description'
|parameters and replace with suggested taxonomy, as described above
|C) clarify discussion of packet outcomes from Y.1540 and place in
|appropriate sections
|D) clarify which parameters can be included in <QoS Desired> <QoS
|Available>, <QoS Reserved>, or <QoS Minimum>
|
|Please review and comment on the proposed changes.
|
|Thanks,
|Jerry, Dave, Cornelia
|
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] 
|Sent: Monday, October 23, 2006 2:59 AM
|To: [email-masked]
|Subject: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft
|
|Hi all,
|
|We have had a very large thread on the current
|draft-ietf-nsis-qspec-12.txt draft.  We don't have a clear 
|consensus, so
|I'd like to try to summarize the discussions.
|
|Several people feel that the current draft contains too many mandatory
|parameters and mapping some QoS Models to others is mixing
|apples-to-oranges.  The feeling is that interoperability is hard to
|achieve and therefore we should not try to gain 
|interoperability.  Jukka
|Manner's message on 17th of October proposed a way forward.
|http://www1.ietf.org/mail-archive/web/nsis/current/msg06919.html
|
|However, several (other) people feel that interoperability is important
|and is needed. Giving up on interoperability would not be a good thing,
|and that we are very close to a solution.  Dave Oran proposed a
|mechanism to reach a solution on the 19th October:
|http://www1.ietf.org/mail-archive/web/nsis/current/msg06962.html
|
|I have asked Jerry and Dave to make a proposal along the lines 
|of Dave's
|message above, and the working group can review this, to see if we can
|gain consensus on this.  I think it would be sufficient to send some
|rough text to the mailing list, and if this is OK, then we can revise
|the draft.
|
|One open question to Dave/Jerry about the proposal is, in the 
|event that
|the source cannot be described a mathematically complete way, is there
|any value (or does it make any sense at all) in sending an incomplete
|qspec, or potentially "wildcarding" sending some of the mandatory
|parameters.  I'm wondering if some sources / deployments may have
|certain parameters that are relatively well defined, but not all are so
|well defined.
|
|thanks,
|John
|
|_______________________________________________
|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: <[email-masked]>
Date: Thu, 2 Nov 2006 09:35:03 +0200

Jerry, Dave and Cornelia;

This looks like a very good simplification of the QSPEC, and I think
that is a good idea.  I think that there will be some implications to
the QoSM drafts - I think QoS Model drafts will need to contain some
more 
applicability statement type of text, along with deployment
considerations.

A plus side of this is that I think that the QoS template will become
more broadly applicable to other uses than just NSIS QoS Signaling,
so I think that is a gain as well.

I'd really like people to review this and send comments on it so that
we could really focus the discussion next week and get this work
finally resolved.

Thanks a lot for working through this, I think this is a good basis
for a proposal.

thanks,
John

>From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>Sent: 02 November, 2006 00:13
>To: [email-masked]
>Cc: Ash, Gerald R (Jerry), ALABS; Cornelia Kappler; David R 
>Oran; Kappler,Cornelia
>Subject: [NSIS] Proposed Updates to the QSPEC Draft
>
>Hi All,
>
>Per John's suggestion below we've discussed Dave Oran's 
>suggestions at length and have the following proposal.  
>
>We think the proposed changes address many concerns raised on 
>the list over the last few months and will require some rather 
>basic changes in the QSPEC document 
>Language to the effect that 'QNSLP/QSPEC can signal for 
>different QOSMs across multiple domains' will be replaced by 
>the notion that QNSLP/QSPEC allows different elements on the 
>path to implement different data plane QoS mechanisms that 
>meets the constraints included in the QSPEC.  A QOSM describes 
>common capabilities among QNEs to act consistently when 
>requested to admit traffic and in treating admitted traffic.  
>A QOSM ID need not be defined or signaled and a QNE need not 
>support any particular QOSM.  A 'QOSM specification' would 
>become a 'QNSLP/QSPEC applicability statement', which 
>documents how a QNE/RMF interprets and treats the various 
>elements in a QSPEC.  
>
>QoS Model (QOSM): A method to achieve QoS for a traffic flow, 
>e.g., IntServ Controlled Load.  A QOSM specifies what sub-set 
>of QSPEC QoS constraints and traffic handling directives a QNE 
>implementing that QOSM is capable of supporting and how 
>resources will be managed by the RMF in such a QNE.
>
>A) The source traffic description is mandatory to include by 
>the QNI and mandatory to interpret by downstream QNEs.  The 
>traffic description is specified by a traffic model (TMOD) 
>parameter consisting of 4
>sub-parameters:
>- rate (r)
>- bucket size (b)
>- peak rate (p)
>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.
>B) All other QSPEC parameters are optional to include by the 
>QNI, and may be either mandatory or optional to interpret by 
>downstream QNEs.
>That is, the QNI can explicitly specify for each constraint 
>parameter whether it wishes admission control to succeed or 
>fail if that constraint cannot be met.  A downstream QNE 
>distinguishes whether it is failure to understand the 
>parameter or failure to meet the constraint that causes the 
>admission control failure (more detail on this below).
>C) Additional QSPEC parameters can be defined in updates to 
>the QSPEC document (or alternatively specified in QOSM 
>applicability statement documents).  There is already an IANA 
>registry established for additional QSPEC parameters.
>
>3. The concept of remapping QSPEC parameters is eliminated.  
>This concept is ill defined and has caused much confusion 
>(there are few if any sensible remappings).  Rather we define 
>'interpret' a QSPEC parameter to only mean what we now call 
>'strictly interpret' (i.e., must conform to the RFCs defining 
>the parameter and procedures) and eliminate the remap option 
>part of 'interpret'.
>
>4. Since remapping is eliminated, the concept of stacking 
>QSPECs is also eliminated.  Discussion of tunneling of QNSLP 
>messages is eliminated since there are no impacts on tunneling 
>required by QSPEC.
>
>A) The QNI sets the M flag for each QSPEC parameter it 
>populates that it intends must be interpreted or the 
>reservation fails.  Currently the M flag is statically set for 
>every QSPEC parameter.
>B) If the M flag is set, a downstream QNE must interpret the 
>parameter or the reservation fails.  If a QNE does not support 
>the parameter with the M flag set, it sets the N flag and 
>rejects the reservation.  If the QNE supports the parameter 
>but cannot meet the parameter, it sets the E flag and rejects 
>the reservation. 
>C) If the M flag is not set, a downstream QNE should interpret 
>the parameter.  If a QNE does not support the parameter, it 
>sets the N flag and can optionally accept or reject the 
>reservation.  If a QNE supports the parameter but cannot meet 
>the parameter, it sets the E flag and optional accepts or 
>rejects the reservation.
>Slack term  Priority (Preemption, Defending, Admission, RPH 
>Priority)  DSTE class
>
> PHB Class (note that PHB class is set by downstream QNE to 
>tell QNI how to mark traffic to ensure it will be treated as 
>committed by admission
>control)
>
>Eliminated:
> bandwidth
> Ctot, Dtot, Csum, Dsum
>
>7. Editorial changes:
>A) rewrite description of read-only and read-write parameters 
>to make the rules more clear: 
>C) clarify discussion of packet outcomes from Y.1540 and place 
>in appropriate sections
>draft-ietf-nsis-qspec-12.txt draft.  We don't have a clear 
>consensus, so I'd like to try to summarize the discussions.
>
>Several people feel that the current draft contains too many 
>mandatory parameters and mapping some QoS Models to others is 
>mixing apples-to-oranges.  The feeling is that 
>interoperability is hard to achieve and therefore we should 
>not try to gain interoperability.  Jukka Manner's message on 
>17th of October proposed a way forward.
>However, several (other) people feel that interoperability is 
>important and is needed. Giving up on interoperability would 
>not be a good thing, and that we are very close to a solution. 
> Dave Oran proposed a mechanism to reach a solution on the 
>19th October:
>I have asked Jerry and Dave to make a proposal along the lines 
>of Dave's message above, and the working group can review 
>this, to see if we can gain consensus on this.  I think it 
>would be sufficient to send some rough text to the mailing 
>list, and if this is OK, then we can revise the draft.
>
>One open question to Dave/Jerry about the proposal is, in the 
>event that the source cannot be described a mathematically 
>complete way, is there any value (or does it make any sense at 
>all) in sending an incomplete qspec, or potentially 
>"wildcarding" sending some of the mandatory parameters.  I'm 
>wondering if some sources / deployments may have certain 
>parameters that are relatively well defined, but not all are 
>so well defined.
>
>thanks,
>John
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Nov 2006 12:00:23 +0100

Hi John

I have just come back from a trip and I have just look into point 4):
> >4. Since remapping is eliminated, the concept of stacking QSPECs is 
> >also eliminated.  Discussion of tunneling of QNSLP messages is 
> >eliminated since there are no impacts on tunneling required by QSPEC.

QSPEC stacking is one of the significant concepts in the QoS based NSIS
solution.
This concept provides the additional flexibility that is missing from RSVP.
Furthermore, all the work that we have done until now is based on 
the concept of QSPEC stacking. Thus what you actually say is to just 
forget the work that we have done
until now, in e.g.the RMD-QOSM draft, and start from the beginning.

The main problem that we have had until now was not the QSPEC stacking
issue,
but it was the huge number of mandatory paremeters. Actualy I consider the
issue of removing the 
QSPEC stacking concept a much more severe problem on achieving the
flexibility 
that we wanted to achieve with NSIS than the huge number of mandatory
parameters.

Therefore, I am severely against removing the QSPEC stacking concept!

Best Regards,
Georgios

> Sent: donderdag 2 november 2006 8:35
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [NSIS] Proposed Updates to the QSPEC Draft
> 
> This looks like a very good simplification of the QSPEC, and 
> I think that is a good idea.  I think that there will be some 
> implications to the QoSM drafts - I think QoS Model drafts 
> will need to contain some more applicability statement type 
> of text, along with deployment considerations.
> 
> A plus side of this is that I think that the QoS template 
> will become more broadly applicable to other uses than just 
> NSIS QoS Signaling, so I think that is a gain as well.
> 
> I'd really like people to review this and send comments on it 
> so that we could really focus the discussion next week and 
> get this work finally resolved.
> 
> Thanks a lot for working through this, I think this is a good 
> basis for a proposal.
> 
> thanks,
> John
> 
> >Cc: Ash, Gerald R (Jerry), ALABS; Cornelia Kappler; David R Oran; 
> >Kappler,Cornelia
> different QOSMs 
> >across multiple domains' will be replaced by the notion that 
> >QNSLP/QSPEC allows different elements on the path to implement 
> >different data plane QoS mechanisms that meets the 
> constraints included 
> >in the QSPEC.  A QOSM describes common capabilities among 
> QNEs to act 
> >consistently when requested to admit traffic and in treating 
> admitted 
> >traffic.
> >A QOSM ID need not be defined or signaled and a QNE need not support 
> >any particular QOSM.  A 'QOSM specification' would become a 
> >'QNSLP/QSPEC applicability statement', which documents how a QNE/RMF 
> >interprets and treats the various elements in a QSPEC.
> >
> >constraints and traffic handling directives a QNE implementing that 
> >QOSM is capable of supporting and how resources will be 
> managed by the 
> >RMF in such a QNE.
> >
> >A) The source traffic description is mandatory to include by the QNI 
> >and mandatory to interpret by downstream QNEs.  The traffic 
> description 
> >is specified by a traffic model (TMOD) parameter consisting of 4
> >sub-parameters:
> >- rate (r)
> >- bucket size (b)
> >- peak rate (p)
> QNI, and 
> parameter 
> the QSPEC 
> >This concept is ill defined and has caused much confusion (there are 
> >few if any sensible remappings).  Rather we define 
> 'interpret' a QSPEC 
> >parameter to only mean what we now call 'strictly interpret' (i.e., 
> >must conform to the RFCs defining the parameter and procedures) and 
> >eliminate the remap option part of 'interpret'.
> >
> >4. Since remapping is eliminated, the concept of stacking QSPECs is 
> >also eliminated.  Discussion of tunneling of QNSLP messages is 
> >eliminated since there are no impacts on tunneling required by QSPEC.
> >
> populates that 
> >it intends must be interpreted or the reservation fails.  
> Currently the 
> >M flag is statically set for every QSPEC parameter.
> parameter 
> >Priority (Preemption, Defending, Admission, RPH
> >Priority)  DSTE class
> >
> > PHB Class (note that PHB class is set by downstream QNE to tell QNI 
> >how to mark traffic to ensure it will be treated as committed by 
> >admission
> >control)
> >
> >Eliminated:
> > bandwidth
> > Ctot, Dtot, Csum, Dsum
> >
> >7. Editorial changes:
> consensus, 
> >so I'd like to try to summarize the discussions.
> >
> mandatory 
> >achieve and therefore we should not try to gain interoperability.  
> >Jukka Manner's message on 17th of October proposed a way forward.
> >and that we are very close to a solution.
> > Dave Oran proposed a mechanism to reach a solution on the 19th 
> >October:
> >I have asked Jerry and Dave to make a proposal along the lines of 
> >Dave's message above, and the working group can review this, 
> to see if 
> >we can gain consensus on this.  I think it would be 
> sufficient to send 
> >some rough text to the mailing list, and if this is OK, then we can 
> >revise the draft.
> >
> >One open question to Dave/Jerry about the proposal is, in the event 
> >that the source cannot be described a mathematically 
> complete way, is 
> >there any value (or does it make any sense at
> >all) in sending an incomplete qspec, or potentially "wildcarding" 
> >sending some of the mandatory parameters.  I'm wondering if some 
> >sources / deployments may have certain parameters that are 
> relatively 
> >well defined, but not all are so well defined.
> >
> >thanks,
> >John
> >

---

From: David R Oran <[email-masked]>
Date: Thu, 2 Nov 2006 08:57:10 -0500

I think some detailed discussion of this is going to be needed,  
because after considerable pondering the three of us could not at all  
figure out what either remapping or QSPEC stacking was good for. It  
certainly introduces a vast amount of complexity and confusion as  
currently formulated.

It appears at least to me that one of three situation obtains:
(a) we (well, at least I) don't understand RMD
(b) there is some general QoS concept that we are missing - we went  
through some complex scenarios like reservation aggregation any  
multiple QOSMs chained together and still could not figure out how  
one needed either stacking or remapping of QSPEC parameters
(c) RMD is really a completely different QoS signaling architecture  
from the rest of NSIS and is being shoehorned in by complicating  
QNSLP and QSPEC to allow multiple QoS signaling schemes to masquerade  
as a single architecture.

I really hope it's (a) or (b) since then we can probably resolve this  
by either putting back the missing functionality or figuring out  
another simple way to accommodate RMD. What I'm most afraid of is  
that this is really (c).

 From the little I understand RMD, it's really like mapping onto a  
custom L2 QoS scheme like ATM or DOCSIS, and that rather than doing  
the mapping the way any conventional L3 RMF would do it, you co- 
mingle RMD's model with NSIS's model.

But, I could of course be wildly wrong here.

Dave.

On Nov 2, 2006, at 6:00 AM, Georgios Karagiannis wrote:

>>> 2. The QSPEC1/QSPEC2 semantics will be replaced with Dave's a) -- 
>>> > d)
>>> semantics:

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Nov 2006 14:38:37 +0100

Hi Jerry, Dave and Cornelia

Here are some more detail comments on your proposal!

This proposal actually changes completely the QOS based concept 
of NSIS and not only the QSPEC draft. Therefore, I do not agree 
with the proposal.

The problems that we have had until now, in the nsis mailing discussions,
were
related to the huge number of mandatory parameters that all nodes in the
universe had to support. 
This proposal proposes only one parameter Token Bucket, which is good, but 
it removes the possibility from NSIS to use QoS signaling for Diffserv
domains, 
which is against the NSIS charter specification.

Moreover, the remapping possibility from the peak bandwidth (Token Bucket)
value to 
the Bandwidth value that can be used in RMD-QOSM aware like nodes is
eliminated.
I do not understand why, since we have had a consensus on this point in the
nsis
mailing list.
This proposal also removes the QSPEC stacking concept, which 
is one of the most significant concepts in the QoS based NSIS solution.
This concept provides the additional flexibility that is missing from RSVP.
Furthermore, all the work that we have done until now is based on the 
concept of QSPEC stacking. Thus what you actually say is to just forget 
the work that we have done until now, in e.g.the RMD-QOSM draft, 
and start from the beginning.

Furthermore, I wonder why Attila Bader has been left out of the 
discussions that you have had to come up to this proposal.
>From what I know Jerry, Cornelia and Attila were the editors of the 
QSPEC template draft.

More comments in line!

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: woensdag 1 november 2006 23:13
> To: [email-masked]
> the list over the last few months and will require some 
> rather basic changes in the QSPEC document 
> meets the constraints included in the QSPEC.  A QOSM 
> describes common capabilities among QNEs to act consistently 
> when requested to admit traffic and in treating admitted 
> traffic.  A QOSM ID need not be defined or signaled and a QNE 
> need not support any particular QOSM.  A 'QOSM specification' 
> would become a 'QNSLP/QSPEC applicability statement', which 

Georgios: This is a severe change in the NSIS QoS based concept, 
which we have agreed 
4/5 years ago to use in our work.
The current agreed concept compared to RSVP provides a 
flexibility advantage that is missing from RSVP.

> of QSPEC QoS constraints and traffic handling directives a 
> QNE implementing that QOSM is capable of supporting and how 
> describe a traffic source.  Examples will be given for 
> setting TMOD to correspond to specific cases, e.g. where only 
> and other cases (e.g., TCP).  As such, the bandwidth 
> parameter is eliminated.

Georgios: What you actually now say is that a Diffserv domain cannot 
use NSIS for QoS signaling. As you probably know the NSIS charter 
specifies that NSIS should provide QoS signaling for Diffserv domains.
This is actually against the NSIS charter specification.

> admission control failure (more detail on this below).

Georgios: In other words, RMD-QOSM cannot any more use NSIS for QoS
signaling ???

> the parameter and procedures) and eliminate the remap option 

Georgios: Again the peak bandwidth in the Token Bucket parameter can be 
remapped to Bandwidth. Many people already agreed with this.
 Thus I do not see why you do not want to support this feature.
Probably, because in this way you will actually exclude the use and the
application 
of the RMD-QOSM work ???

> messages is eliminated since there are no impacts on 
> tunneling required by QSPEC.

Georgios: 

QSPEC stacking is one of the significant concepts in the QoS based NSIS
solution.
This concept provides the additional flexibility that is missing from RSVP.
Furthermore, all the work that we have done until now is based on the 
concept of QSPEC stacking. Thus what you actually say is to just forget 
the work that we have done until now, in e.g.the RMD-QOSM draft, 
and start from the beginning.
The main problem that we have had until now was not the QSPEC stacking
issue, 
but it was the huge number of mandatory paremeters. Actualy I consider the 
issue of removing the QSPEC stacking concept a much more severe problem on 
achieving the flexibility that we wanted to achieve with NSIS than the huge 
number of mandatory parameters.
> reservation fails.  Currently the M flag is statically set 
> for every QSPEC parameter.
> parameter or the reservation fails.  If a QNE does not 
> support the parameter with the M flag set, it sets the N flag 
> and rejects the reservation.  If the QNE supports the 
> parameter but cannot meet the parameter, it sets the E flag 
> and rejects the reservation. 
> C) If the M flag is not set, a downstream QNE should 
> interpret the parameter.  If a QNE does not support the 
> parameter, it sets the N flag and can optionally accept or 
> reject the reservation.  If a QNE supports the parameter but 
> cannot meet the parameter, it sets the E flag and optional 
> accepts or rejects the reservation.

Georgios: I do not agree to completely remove the remapping, see the reason
given on the previous points
 and I also disagree to remove the R and Q flags listed above!

> tell QNI how to mark traffic to ensure it will be treated as 

Georgios: I do not agree, See above!

> C) clarify discussion of packet outcomes from Y.1540 and 
> place in appropriate sections

Georgios: I do not agree, See above!

Best Regards,
Georgios

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Fri, 3 Nov 2006 09:35:47 +0100

Hi All, I disagree with the proposal below. 

This would remove the flexibility to develop and define new QoS models. Actually the proposal supports only the Intserv model. Stacking and remapping have been fundamental features. 

I think that the best solution would be not to mandate parameters and have only optional one. If we want to distinguish Intserv as e2e QoS model, it is OK to mandate token bucket parameters, but remapping it to other parameters and stacking it should be allowed.

Best regards, Attila

>Sent: Wednesday, November 01, 2006 11:13 PM
>To: [email-masked]

---

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

Hi all,

I tend to agree with Attila here that stacking is a new concept and is 
important to have. E.g., it allows a domain to add QoS information that is 
only relevant to the domain itself, an ingress QNE pushes a new QSPEC into 
the NSLP message, and the egress QNE of the domain just pops it out. A 
domain isnt't required to do so, but allows new kinds of QoS management 
options.

Jukka

On Fri, 3 Nov 2006, Attila Báder (IJ/ETH) wrote:

> This would remove the flexibility to develop and define new QoS models. 
> Actually the proposal supports only the Intserv model. Stacking and 
> remapping have been fundamental features.
> 
> I think that the best solution would be not to mandate parameters and 
> have only optional one. If we want to distinguish Intserv as e2e QoS 
> model, it is OK to mandate token bucket parameters, but remapping it to 
> other parameters and stacking it should be allowed.
> 
> Best regards, Attila
> 
>

---

From: Lars Westberg <[email-masked]>
Date: Fri, 03 Nov 2006 10:56:56 +0100

Let's start with the historic aspect of QoS. Since ATM was defined 
during beginning of 90, the discussion about traffic managment (QOS) 
started to explode. Since then,  all standardization organization has 
tried to defined QOS-parameters based on their own scenario. The same 
happends in IETF with RSVP and Int.serv. We have today parameters and 
signalling sequence diagram defined differently in each standards-body 
especially for different access networks.

Another problem that we experiencing is that the application programmer 
do not understand QoS-API. They actually do not know how to set the 
parameters.
The basic problem is that the QNI will not generate appropriate 
parameter set given the functionality in the sub-path the signalling is 
traversing.
so, the reason for QoS-model stacking is to allow a network entity to 
introduce more advanced QoS-functionality that is required for the 
specific sub-path.

However, the specificly added parameters may also be needed between two 
sub-paths i.e. different access networks with a backbones (Internet?) in 
between.
   
so I recommend that the stacking feature should be a part of the 
QoS-spec template so we can allow for new usage scenario of the NSIS. If 
it is taken away, I do not se any difference between RSVP and NSIS.

I do not understand how the process works. Should we now start a 
blank-sheet argue functionality from beginning ?????

the main reason for bringing the discussion of parameters has nothing to 
with RMD. It is an arhitectural limitation. Just compared it to RSVP. 
RSVP do not have any hardcoded QoS-paraneters into the core part of the 
protocol specification, while NSIS has????
Given the present proposal in the QoS-spec, the architecture is much 
less open for new use than RSVP. Should NSIS make the same mistake as RSVP ?

comment about RMD:

the design target for RMD is twofold:
    a) support for PCN-like bandwidth management.
    b) scalable per-flow reservation.

during many years of discussion, we can conclude that additional 
functionality like RSVP-aggregation have ben design to cope with the 
state-explosion for per-flow reservation. RMD is developed to solve it 
inother approach: scalable per-flow reseravtion with the simillar 
resource guarantee as RSVP.

Our target was actually to improve RSVP more improved scalabillity to 
solve a problem within the mobile access network. But, NSIS becomes the 
answer to the standardization discission so we introduced it in this 
context instead.

regards Lasse

---

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

Jukka, 

> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 4:48 AM
> To: Attila Báder (IJ/ETH)
> Cc: Ash, Gerald R (Jerry), NPE; [email-masked]; Kappler, 
> Cornelia; David R Oran; Cornelia Kappler
> domain isn't required to do so, but allows new kinds of QoS 
> management options.

Without remapping of parameters being allowed, I don't know what a stacked QSPEC would do?  Let's take an example, e.g., the QNI sets
TMOD (M flag set)
Parm A (M flag set)
Parm B (M flag not set)

In the local domain the edge QNEs must interpret TMOD and must interpret Parm B, otherwise the reservation is rejected.  Parm B can either be supported or ignored by the edge QNEs.

What might a stacked qspec accomplish differently in the local domain?  Perhaps a new Parm C is pushed onto the local QSPEC, or what?  And if so, what would that accomplish?

IMO we need a concrete example of how stacking would be useful if remapping is not allowed.  All our prior examples of stacking involved some kind of remapping of parameters from the initiator qspec to a local qspec.  Without that, I don't see what a stacked qspec accomplishes.

Dave also asked for a concrete example of how stacking is useful (when remapping is not possible) in one of his posts yesterday.

Thanks,
Jerry

P.S. Note that the only example of remapping that we ever discussed was token bucket to bandwidth.  All other examples of remapping were trying to map apples to oranges, and causing great confusion.  The concept of remapping is rightfully rejected.

---

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

Hi Jerry

QSPEC Stacking is not needed  for remapping.
For more details on QSPEC stacking please check Section 3.2.8 in:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt

Please note that QSEPC stacking is needed for stacking 
local objects needed by a local (intra-domain) 
QoS model that has different characteristics 
than an end-to-end QoS model together with the end-to-end objects 
needed by the end-to-end QoS model (see also requirement 5.4.2 in RFC3762).
Examples of such intra-domain QOS models are models such as Diffserv based, 
MEF (Metro Ethernet Forum) based and 3GPP based. 
An example of an end-to-end QoS model is the Intserv model.

Please also note that the remapping ptoblem from Token Bucket to 
Bandwidth is not yet solved by your proposal.
 
Best regards,
Georgios

> From: Ash, Gerald R (Jerry), NPE [mailto:[email-masked]] 
> Sent: vrijdag 3 november 2006 11:42
> To: Jukka MJ Manner
> Cc: Ash, Gerald R (Jerry), NPE; [email-masked]
> > Cc: Ash, Gerald R (Jerry), NPE; [email-masked]; Kappler, Cornelia; 
> > David R Oran; Cornelia Kappler
> > important to have. E.g., it allows a domain to add QoS information 
> > that is only relevant to the domain itself, an ingress QNE pushes a 
> > new QSPEC into the NSLP message, and the egress QNE of the 
> domain just 
> > pops it out. A domain isn't required to do so, but allows 
> new kinds of 
> > QoS management options.
> 
> Without remapping of parameters being allowed, I don't know 
> what a stacked QSPEC would do?  Let's take an example, e.g., 
> the QNI sets TMOD (M flag set) Parm A (M flag set) Parm B (M 
> flag not set)
> 
> In the local domain the edge QNEs must interpret TMOD and 
> must interpret Parm B, otherwise the reservation is rejected. 
>  Parm B can either be supported or ignored by the edge QNEs.
> 
> What might a stacked qspec accomplish differently in the 
> local domain?  Perhaps a new Parm C is pushed onto the local 
> QSPEC, or what?  And if so, what would that accomplish?
> 
> IMO we need a concrete example of how stacking would be 
> useful if remapping is not allowed.  All our prior examples 
> of stacking involved some kind of remapping of parameters 
> from the initiator qspec to a local qspec.  Without that, I 
> don't see what a stacked qspec accomplishes.
> 
> Dave also asked for a concrete example of how stacking is 
> useful (when remapping is not possible) in one of his posts yesterday.
> 
> Thanks,
> Jerry
> 
> P.S. Note that the only example of remapping that we ever 
> discussed was token bucket to bandwidth.  All other examples 
> of remapping were trying to map apples to oranges, and 
> causing great confusion.  The concept of remapping is 
> rightfully rejected.
> 
> > 
> > Jukka
> > 
> suggestions 
> > > >at length and have the following proposal.
> > > >
> > > >We think the proposed changes address many concerns 
> raised on the 
> > > >list over the last few months and will require some rather basic 
> > > >changes in the QSPEC document 
> different 
> > > >QOSMs across multiple domains' will be replaced by the 
> notion that 
> > > >different data plane QoS mechanisms that meets the constraints 
> > > >included in the QSPEC.  A QOSM describes common 
> capabilities among 
> > > >QNEs to act consistently when requested to admit traffic and in 
> > > >treating admitted traffic.
> > > >support any particular QOSM.  A 'QOSM specification' 
> would become a 
> > > >'QNSLP/QSPEC applicability statement', which documents how a 
> > > >QNE/RMF interprets and treats the various elements in a QSPEC.
> > > >
> > > >IntServ Controlled Load.  A QOSM specifies what sub-set of QSPEC 
> > > >QoS constraints and traffic handling directives a QNE 
> implementing 
> > > >that QOSM is capable of supporting and how resources will be 
> > > >managed by the RMF in such a QNE.
> > > >
> > > >A) The source traffic description is mandatory to include by the 
> > > >QNI and mandatory to interpret by downstream QNEs.  The traffic 
> > > >description is specified by a traffic model (TMOD) parameter 
> > > >consisting of 4
> > > >sub-parameters:
> > > >- rate (r)
> > > >- bucket size (b)
> > > >- peak rate (p)
> 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.
> > > >B) All other QSPEC parameters are optional to include by 
> the QNI, 
> > > >and may be either mandatory or optional to interpret by 
> downstream 
> > > >QNEs.
> > > >parameter whether it wishes admission control to succeed 
> or fail if 
> > > >that constraint cannot be met.  A downstream QNE distinguishes 
> > > >whether it is failure to understand the parameter or failure to 
> > > >meet the constraint that causes the admission control 
> failure (more 
> > > >detail on this below).
> > > >C) Additional QSPEC parameters can be defined in updates to the 
> > > >QSPEC document (or alternatively specified in QOSM applicability 
> > > >statement documents).  There is already an IANA registry 
> > > >established for additional QSPEC parameters.
> > > >
> > > >This concept is ill defined and has caused much confusion (there 
> > > >are few if any sensible remappings).  Rather we define 
> 'interpret' 
> > > >a QSPEC parameter to only mean what we now call 'strictly 
> > > >interpret' (i.e., must conform to the RFCs defining the 
> parameter 
> > > >and procedures) and eliminate the remap option part of 
> 'interpret'.
> > > >
> > > >A) The QNI sets the M flag for each QSPEC parameter it populates 
> > > >that it intends must be interpreted or the reservation fails.  
> > > >Currently the M flag is statically set for every QSPEC parameter.
> support the 
> > > >parameter with the M flag set, it sets the N flag and 
> rejects the 
> > > >reservation.  If the QNE supports the parameter but 
> cannot meet the 
> > > >parameter, it sets the E flag and rejects the reservation.
> interpret the 
> > > >parameter.  If a QNE does not support the parameter, it 
> sets the N 
> > > >flag and can optionally accept or reject the 
> reservation.  If a QNE 
> > > >supports the parameter but cannot meet the parameter, it 
> sets the E 
> > > >flag and optional accepts or rejects the reservation.
> > > > Y.1541 class (shorthand notation for above 4 parameters) Slack 
> > > >term  Priority (Preemption, Defending, Admission, RPH
> > > >Priority)  DSTE class
> > > >
> > > > PHB Class (note that PHB class is set by downstream QNE to tell 
> > > >QNI how to mark traffic to ensure it will be treated as 
> committed 
> > > >by admission
> > > >control)
> > > >
> > > >Eliminated:
> > > > bandwidth
> > > > Ctot, Dtot, Csum, Dsum
> > > >
> > > >7. Editorial changes:
> > > >A) rewrite description of read-only and read-write parameters to 
> > > >make the rules more clear:
> interoperability is 
> > > >hard to achieve and therefore we should not try to gain 
> > > >interoperability.  Jukka Manner's message on 17th of October 
> > > >proposed a way forward.
> > > >important and is needed. Giving up on interoperability 
> would not be 
> > > >a good thing, and that we are very close to a solution.
> > > >Dave's message above, and the working group can review 
> this, to see 
> > > >if we can gain consensus on this.  I think it would be 
> sufficient 
> > > >to send some rough text to the mailing list, and if this is OK, 
> > > >then we can revise the draft.
> > > >
> complete way, 
> > > >is there any value (or does it make any sense at
> "wildcarding" 
> > > >relatively well defined, but not all are so well defined.
> > > >
> > > >thanks,
> > > >John
> > > >

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Fri, 3 Nov 2006 12:32:51 +0100

Hi Jukka, 

when you say "new information", would this be information not included in the original reservation? I.e. would the stacked QSPEC then be able to reserve something "different" from the initiator QSPEC? E.g. the original QSPEC just contains the TMOD parameter, and the stacked QSPEC additionally contains delay. If yes then we just need to agree whether we want this. 

Couldnt stacking anyways always be replaced by tunnelling through a domain - i.e. the ingress QNE tunnels the incoming message to the end of the domain and generates a new message through the domain. So no real need to have the feature!? 

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Jukka MJ Manner [mailto:[email-masked]] 
> Gesendet: Freitag, 3. November 2006 10:48
> An: Attila Báder (IJ/ETH)
> Cc: Ash, Gerald R \(Jerry\), ALABS; [email-masked]; Kappler, 
> Betreff: RE: [NSIS] Proposed Updates to the QSPEC Draft
> 
> 
> Hi all,
>

---

From: <[email-masked]>
Date: Fri, 3 Nov 2006 13:35:32 +0200

Hi Georgios

>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt

The text in that section says the following:

   When a domain wants to apply a certain QoS model to an incoming per-
   flow reservation request, each edge of the domain is configured to
   map the incoming QSPEC object to a local QSPEC object and push that
   object onto the stack of QSPEC objects. QNEs inside the domain look
   at the top of the QSPEC object stack to determine which QoS model to

Manner et al.              Expires March 2007                  [Page 15]

Internet-Draft                  QoS NSLP                    October 2006

   apply for the reservation.

This is clearly remapping from the e2e QSPEC to the local QSPEC, right?
since this is the case, could not the local QoS domain just re-use the
existing (e2e) QSPEC - or does the local QoS domain need to add
additional
parameters?  I feel like I'm missing something from you description.

thanks,
John

---

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

Hi Cornelia

Please note that QSEPC stacking is needed for stacking local 
objects needed by a local (intra-domain) QoS model that 
has different characteristics than an end-to-end QoS 
model together with the end-to-end objects needed by the 
end-to-end QoS model (see also requirement 5.4.2 in RFC3762).
Examples of such intra-domain QOS models are models such as 
Diffserv based, MEF (Metro Ethernet Forum) based and 3GPP based. 
An example of an end-to-end QoS model is the Intserv model. 

Thus these stacking issues are already approved by the NSIS WG and IESG, 
before RFC3762 had been published.

Best Regards,
Georgios

> From: Kappler, Cornelia [mailto:[email-masked]] 
> Sent: vrijdag 3 november 2006 12:33
> To: Jukka MJ Manner; Attila Báder (IJ/ETH)
> Cc: Ash, Gerald R \(Jerry\), ALABS; David R Oran; [email-masked]
> Subject: AW: [NSIS] Proposed Updates to the QSPEC Draft
> 
> Hi Jukka, 
> 
> when you say "new information", would this be information not 
> included in the original reservation? I.e. would the stacked 
> QSPEC then be able to reserve something "different" from the 
> initiator QSPEC? E.g. the original QSPEC just contains the 
> TMOD parameter, and the stacked QSPEC additionally contains 
> delay. If yes then we just need to agree whether we want this. 
> 
> Couldnt stacking anyways always be replaced by tunnelling 
> through a domain - i.e. the ingress QNE tunnels the incoming 
> message to the end of the domain and generates a new message 
> through the domain. So no real need to have the feature!? 
> 
> Cornelia
> 
> > pops it out. A domain isnt't required to do so, but allows 
> new kinds 
> > of QoS management options.
> > 
> > Jukka
> >

---

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

Hi John

The text that you have used talks about remapping and for 
that case QSPEC stacking can be applied for this purpose,
but the main need for QSPEC stacking is given by the
 requirement 5.4.2 in RFC 3762.
Furthermore, in the same section 3.2.8, you could also 
find the text that does not talk about remapping:

  "By using QSpec staking, an increase in flexibility, modularity and
   signaling performance an be achieved. The flexibility and modularity
   increase can be achieved by providing the possibility to any existing
   or future QoS model applied in a local QoS NSLP aware domain to use
   and stack any required local QoS model information on QoS NSLP
   signaling messages passing through the local domain (see requirement
   5.4.2 in RFC3762).

   The signaling performance increase can be achieved by reducing the
   number of required local QoS NSLP signaling messages, when local QoS
   model information is stacked on the QoS NSLP signaling messages that
   are passing through the local domain."

Best regards,
Georgios

> Sent: vrijdag 3 november 2006 12:36
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> > 
> since this is the case, could not the local QoS domain just 
> re-use the existing (e2e) QSPEC - or does the local QoS 
> domain need to add additional parameters?  I feel like I'm 
> missing something from you description.
> 
> thanks,
> John
>

---

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

Georgios,

>objects needed by a local (intra-domain) QoS model that has 
>different characteristics than an end-to-end QoS model 
>together with the end-to-end objects needed by the end-to-end 
>QoS model (see also requirement 5.4.2 in RFC3762).

For stacking, is there any relation between the two QSPECs?  If
so, how are they related?  I am having trouble seeing the relation
between the two QSPECs.

thanks,
JOhn

---

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

Hi John 

Of course the two QoS models are related to each other. So the end-to-end
QSPEC 
will activate some events and the local QoS model can include local QOS
parameters, in a
local QSPEC, please see requirement 5.4.2 in RFC3762.

Please note that a QSPEC can include besides the traffic description 
(i.e., Token Bucket, Bandwidth) also other QoS parameters that are needed 
for the local QoS model and are not needed for the end-to-end QoS model. 
In this case stacking is very useful, because the local QSPEC can be
interpreted 
only by the local QoS model and removed at the edges of the local QOSM aware
domain.

Best Regards,
Georgios

> Sent: vrijdag 3 november 2006 13:02
> >Please note that QSEPC stacking is needed for stacking local objects 
> >needed by a local (intra-domain) QoS model that has different 
> >characteristics than an end-to-end QoS model together with the 
> >end-to-end objects needed by the end-to-end QoS model (see also 
> >requirement 5.4.2 in RFC3762).
> >Examples of such intra-domain QOS models are models such as Diffserv 
> >based, MEF (Metro Ethernet Forum) based and 3GPP based.
> For stacking, is there any relation between the two QSPECs?  
> If so, how are they related?  I am having trouble seeing the 
> relation between the two QSPECs.
> 
> thanks,
> JOhn
>

---

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

Hi Jerry

Another model that will need stacking is for example the ITU-T RACF model,
see:
http://www.ietf.org/internet-drafts/draft-zhang-nsis-interdomain-qosm-03.txt

I think however that your question is wrong!

NSIS is designed to allow modularity, such new QoS models can be 
developed in the future.
Today only three QoS models are specified and it does not mean 
that because two of them do not neeed to use stacking (Y.1541 and 
Controlled load) it does not mean that 
none of the future QoS models will not need to use stacking.

Best Regards,
Georgios

> Sent: vrijdag 3 november 2006 14:01
> To: Georgios Karagiannis; [email-masked]; 
> [email-masked]
> > From: Georgios Karagiannis [mailto:[email-masked]]
> > Sent: Friday, November 03, 2006 7:16 AM
> > To: [email-masked]; Ash, Gerald R (Jerry), NPE; 
> > [email-masked]
> > Cc: [email-masked]
> > Of course the two QoS models are related to each other. So the 
> > end-to-end QSPEC will activate some events and the local 
> QoS model can 
> > include local QOS parameters, in a local QSPEC, please see 
> requirement 
> > 5.4.2 in RFC3762.
> > 
> > (i.e., Token Bucket, Bandwidth) also other QoS parameters that are 
> > needed for the local QoS model and are not needed for the 
> end-to-end 
> > QoS model.
> > interpreted only by the local QoS model and removed at the edges of 
> > the local QOSM aware domain.
> 
> You haven't given any concrete example of how the second 
> QSPEC should be used and why.
> 
> If you are referring to RMD using the second QSPEC to 
> piggyback certain control parameters, applicable only to RMD, 
> inside a local domain, then that isn't a justification for 
> stacking a QSPEC.
> 
> Please provide a concrete example of QSPEC stacking that 
> justifies the need, where no remapping of qspec parameters is allowed.
> 
> Jerry
> 
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > local objects

---

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

Georgios, 

> only by the local QoS model and removed at the edges of the 
> local QOSM aware domain.

You haven't given any concrete example of how the second QSPEC should be
used and why.

If you are referring to RMD using the second QSPEC to piggyback certain
control parameters, applicable only to RMD, inside a local domain, then
that isn't a justification for stacking a QSPEC.

Please provide a concrete example of QSPEC stacking that justifies the
need, where no remapping of qspec parameters is allowed.

Jerry

---

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

Hi Lars,

> protocol specification, while NSIS has????

No, NSIS signaling carries the QSPEC which is opaque for the protocol.

> less open for new use than RSVP. Should NSIS make the same mistake as RSVP ?

It is not less open.

> resource guarantee as RSVP.

Actually I don't see why RMD is more scalable than RSVP aggregation
(at least if reservation-based mode of RMD is considered).
If compared to RSVP aggregation, RMD generates more signaling messages.
If I understood the RMD-draft correctly, every inter-domain/external
RESERVE message causes the QNE Ingress node to send an intra-Domain
RESERVE. Thus, interior nodes have to process per-(micro)flow signaling
messages which is avoided in the RSVP aggregation if the aggregate
reservation capacity is not adapted with every flow.

> answer to the standardization discission so we introduced it in this

What is the intended status of RMD? Informational or PS?

Regards,
 Roland

---

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

Hi Lars,

It is not less open.

Regards,
 Roland

---

From: David R Oran <[email-masked]>
Date: Fri, 3 Nov 2006 07:32:21 -0500

On Nov 3, 2006, at 4:56 AM, Lars Westberg wrote:

> during beginning of 90, the discussion about traffic managment  
> (QOS) started to explode. Since then,  all standardization  
> organization has tried to defined QOS-parameters based on their own  
> scenario. The same happends in IETF with RSVP and Int.serv. We have  
> today parameters and signalling sequence diagram defined  
> differently in each standards-body especially for different access  
> networks.
>
Are you saying this is good,or bad, or what? The IETF is about  
interoperability, not defining shell standards into which the widest  
possible variety of non-interoperable things can be accommodated. In  
the world of transports, we certainly could have defined stackable  
transports, with remapping of the transport semantics at various  
domain points, and had something that worked sometimes. But, the end- 
to-end nature of the architecture would have been compromised and I  
think taking the same complex view in NSIS is well along that road.

I'm quite cognizant that some of this stuff goes counter to  
agreements that have been close to consensus in the working group for  
a long time, and had we not all come to logger-heads over the issue  
of mandatory QoS parameters this might have sailed through (at least  
until it hit the IESG). My assessment (again - let me emphasize that  
it's a personal view) was that the lack of closure over the  
parameters in fact revealed some deeper architectural difficulties,  
especially around QOS models and the role they play in the NSIS NSLP  
and QSPEC design.

So, if the WG wants to go back to the prior direction, I'll just  
crawl back in my hole and apologize for rocking the boat.

I happen to fundamentally disagree with the notion that different QoS  
models require different traffic descriptions by the traffic source.  
The traffic generation process is what it is, and defining different  
QoS models that preserve the exact source traffic generation pattern  
at the receiver to differing degrees of accuracy is perfectly  
appropriate. However, if you alter the source traffic description in  
the middle through stacking or remapping this property is lost.

I think that the the situation where "We have today parameters and  
signalling sequence diagram defined differently in each standards- 
body especially for different access networks" is a problem, not a  
good thing, and the way to deal with it is not to import every one of  
those into NSIS, but rather to map "down" to the particular domain's  
model in individual QNEs. If they in turn need to do some private  
signaling among themselves (e.g. DOCSIS, 802.11e) that's their business.

I also disagree with the notion that by choosing a 4-parameter  
traffic model for describing traffic sources somehow means that you  
are constrained to an INTSERV QOS model in terms of the QNEs and  
their RMFs that actually admit and handle the traffic. The QOSM (to  
my way of thinking) defined by what constraints and handling  
directives can be accommodated for the stated traffic description,  
not that it imposes a traffic model or description on the source.

>
> Another problem that we experiencing is that the application  
> programmer do not understand QoS-API. They actually do not know how  
> to set the parameters.
This is an independent problem but I'll observe that by having a  
large number of parameters, all optional, with no understanding of  
what they are and how they relate to how the application generates  
its traffic cannot possibly make it easier for the programmer to  
understand QoS. This argues for a single, mathematically complete and  
consistent method of describing a traffic source that all application  
scan use.

> parameter set given the functionality in the sub-path the  
> signalling is traversing.
I agree that the QNI will not, but further that it should not, and  
further that we should not have parameters in NSIS that   don't  
relate to providing end-to-end QoS.

> so, the reason for QoS-model stacking is to allow a network entity  
> to introduce more advanced QoS-functionality that is required for  
> the specific sub-path.
>
This is what aggregation and tunneling are for, no?

> However, the specificly added parameters may also be needed between  
> two sub-paths i.e. different access networks with a backbones  
> (Internet?) in between.
>
Can you give an example? In the multi-domain models I'm familiar  
with, the domain-specific parameters are computed on domain entry and  
are not tunneled because the domain boundaries always or nearly  
always also correspond to trust boundaries (i.e. if you have a domain  
path A-X-B with A and be using the same QoSM, B will not believe QoSM- 
specific parameters passed from A through X anyway).

> QoS-spec template so we can allow for new usage scenario of the  
> NSIS. If it is taken away, I do not se any difference between RSVP  
> and NSIS.
>
There are a lot of differences, some in form and some in function,  
but one thing I agree with is that the general RSVP model of  
separating traffic description from QoS admission and data plane  
functions and treating the traffic description as end-to-middle-to- 
end is not broken and that there's no reason for NSIS to deviate from  
it.

> blank-sheet argue functionality from beginning ?????
Of course not.

> the main reason for bringing the discussion of parameters has  
> nothing to with RMD. It is an arhitectural limitation. Just  
> compared it to RSVP. RSVP do not have any hardcoded QoS-paraneters  
> into the core part of the protocol specification, while NSIS has????
Maybe to do a better job?

> Given the present proposal in the QoS-spec, the architecture is  
> much less open for new use than RSVP. Should NSIS make the same  
> mistake as RSVP ?
>
RSVP's problems had little to do with its QoS description  
capabilities, but arguing the fate of RSVP is unlikely to help us  
resolve the general architectural questions that have come up as a  
result of not being able to reach closure on the QSPEC draft.

> functionality like RSVP-aggregation have ben design to cope with  
> the state-explosion for per-flow reservation. RMD is developed to  
> solve it inother approach: scalable per-flow reseravtion with the  
> simillar resource guarantee as RSVP.
>
Understood. However, what I read into this is that RMD is a QoS  
signaling architecture of its own and the desire is to co-mingle it  
with NSIS. That runs counter to the goal of universal  
interoperability, IMO.

> Our target was actually to improve RSVP more improved scalabillity  
> to solve a problem within the mobile access network. But, NSIS  
> becomes the answer to the standardization discission so we  
> introduced it in this context instead.
>
Also understood, and other things being equal, a worthy endeavor.

Cheers, Dave.

>> QSPECs is
>> support
>> QNE/RMF
>> e.g.,
>> the QNI
>> >> correspond
>> (there are
>> QSPECs is
>> the
>> tell QNI
>> event

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 3 Nov 2006 20:31:43 -0500

Inline [RRR]

________________________________

From: [email-masked] on behalf of David R Oran
Sent: Fri 11/3/2006 7:32 AM
To: Lars Westberg
Cc: NSIS Group
Subject: Re: [NSIS] Proposed Updates to the QSPEC Draft

My assessment (again - let me emphasize that 
it's a personal view) was that the lack of closure over the 
parameters in fact revealed some deeper architectural difficulties, 
especially around QOS models and the role they play in the NSIS NSLP 
and QSPEC design.

[RRR] Here we are loosing our sights. We have generalized all QOS Models in the "same" level. It is the root cause of all problems. We must NOT treat "apple" and "oragnge" in the same level.

[RRR] Let me ask one fundamental question: What are the properties of a given QOS model that characterize it as QOS model? If we do not analyze this fundamental problem, then we will NEVER be able be to solve any QOS problems.

[RRR] Did you ever has the chance to comapre the properties of so-called QOS models: Y.1541, 3GPP/Y.1541, and DSTE (group I)? Do they the same properties like those of RSVP, DiffServ, and IntServ (Group II)? Are the properties of this group I not fundamentally different?

[RRR] Again, all QOS models of Group II (RSVP, DiffServ, and IntServ) interwork among themselves. So, their QSPEC spec also interwork among theselves. So, it is the perfect goal of the IETF and NSIS WG and we are done.

[RRR] All QOS models of Group I (Y.1541, 3GPP/Y.1541, and DSTE) do not interwork among themselves. So, their QSPEC spec will also NEVER work among themselves. The interworking anomg Groups I and II QOS models is a DREAM to internity.

[RRR] What is the conclusion after 2 yeasrs of hard works of all members? The answer is this: Drop all bad apples of QOS models of Group I (Y.1541, 3GPP/Y.1541, and DSTE ) from the QSPEC draft.

[RRR] You did a very hard work. What you need to suggest is this: Drop all bad apples of QOS models of Group I (Y.1541, 3GPP/Y.1541, and DSTE ) from the QSPEC draft. Work with only Group II QoS models (RSVP, DiffServ, and IntServ).

[RRR] May also suggest: Do individual QSPEC drafts for Y.1451 and DSTE.

Cheers, Dave.

---

From: Roland Bless <[email-masked]>
Date: Sat, 04 Nov 2006 22:15:18 +0100

Hi,

David R Oran wrote:
> IESG). My assessment (again - let me emphasize that it's a personal
> view) was that the lack of closure over the parameters in fact revealed
> some deeper architectural difficulties, especially around QOS models and
> the role they play in the NSIS NSLP and QSPEC design.

Exactly.

> models require different traffic descriptions by the traffic source. The
> traffic generation process is what it is, and defining different QoS
> models that preserve the exact source traffic generation pattern at the
> receiver to differing degrees of accuracy is perfectly appropriate.
> However, if you alter the source traffic description in the middle
> through stacking or remapping this property is lost.

Yep.

> especially for different access networks" is a problem, not a good
> thing, and the way to deal with it is not to import every one of those
> into NSIS, but rather to map "down" to the particular domain's model in
> individual QNEs. If they in turn need to do some private signaling among
> themselves (e.g. DOCSIS, 802.11e) that's their business.

Agree.

> I also disagree with the notion that by choosing a 4-parameter traffic
> model for describing traffic sources somehow means that you are
> constrained to an INTSERV QOS model in terms of the QNEs and their RMFs
> that actually admit and handle the traffic. The QOSM (to my way of
> thinking) defined by what constraints and handling directives can be
> accommodated for the stated traffic description, not that it imposes a
> traffic model or description on the source.

Yes.

> signaling architecture of its own and the desire is to co-mingle it with
> NSIS. That runs counter to the goal of universal interoperability, IMO.

That matches nearly exactly my opionion which I expressed once at
the first interim meeting in Helsinki back in 2002. I said that this
doesn't need to be standardized in NSIS in the first place, because
it's intra-domain edge-to-edge signaling where you can use any
proprietary protocol. I felt that NSIS would tackle also more the
inter-domain issues in QoS signaling (at least when reading the old
charter).

Regards,
 Roland

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 5 Nov 2006 10:57:19 -0500

Inline [RRR]

From: [email-masked] on behalf of Roland Bless
Sent: Sat 11/4/2006 4:15 PM
To: David R Oran
Cc: Lars Westberg; NSIS Group
Subject: Re: [NSIS] Proposed Updates to the QSPEC Draft

Hi,

Exactly.

[RRR] Now it reveals the fact that there is no socpe for interoperability in using different QOS models. If it is so, did Dave and Roland analyze the root cause of this interoperability problem?

[RRR] If you folks do not analyze for each QOS model and want to generalize for all QOS models, you are NOT doing your technical analysis correctly and are sending the WRONG message to the entire NSIS technical community mixing apples and oragnes as if all QOS models have the same properties.

[RRR} Did you folks know that RSVP, DiffServ, and IntServ QOS models interowrk among themselves using QSPEC template with NSIS QOS signaling messages. If so, why are you not ponting out this?

[RRR} Is it not the case the so-called QOS models like Y.1451, 3GPP/Y.1541, and DSTE that do NOT qualify to be QOS models in the first place are the root cause of all problems? Why do you not speak out for these cases specifically? What is your problem?

Yep.

[RRR] Again, it is a too general statement. Let us taken an example and analyze for each QOS model and examine where and how each QOS model fails. If we do not do this, there is no clear conlusion in support of this to "generic" statement.

[RRR] If you analyze each QOS model, you can easilty see the three QOS mdoels RSVP, IntServ, and DiffServ are in synch in all respects. There are no ambigutiies to deal with either with traffic descriptions or or any QOS parameters because they have standardized the basic QOS characteristics for which there are proper mapping can be done. In fact, it is happening since their inception. NSIS QOS signaling is jus doing fine with these three QOS models. Do you see what has been the basic objective of NSIS QOS signaling? Is it not that the NSIS QOS signaling is the SECOND vesrion of RSVP with more "scalability" for end-to-end QOS signaling?

[RRR] If you folks forget these basic objectives of NSIS QOS signaling and want create unnecessary problems bring the so-called hard-coded some implementation-specific QOS parameters with any fundamental QOS properties like Y.1541 and DSTE, how can you be "objective" in solving the QOS interoperability problem for e2e QOS in NSIS for which it is being standardized?

Agree.

[RRR] It is not true when it is gemeralized with the things mixing between "apples" and "oranges." Kindly see the technical explanations as ststed above.

Yes.

[RRR] Can you provide an example taking the RSVP, IntServ, and DiffServ and show where are the problems and we can understand more clearly?

[RRR] I do not see this as it is explaned here. The basic idea of NSIS QOS signaling protocol has been end-to-end signaling. NSIS charter is clear about this. No only this, NSIS has clear code points how each application will be able to signal its desired QOS in NSIS upper layer. The specific application sitting in both ends of the network will be able to communicate transparently for providing the end-to-end QOS. As I explained to Ronald last time, NSIS is not just e2e network layer signaling.

[RRR] If NSIS is NOT developing the e2e QOS between the application connected to the two ends of the network, there will probably no need for another protocol like NSIS QOS signaling because the traditional QOS signaling with RSVP/IntServ in the access network and DiffServ in the backbone network is doing just fine.

[RRR] After all these years of hard works when NSIS signaling is robust enough to provide the end-to-end QOS signaling, and QSPEC templates that are quite OK for the RSVP, IntServ, and DiffServ QOS models for interoperability, why you two folks want to turn the wheels back?

[RRR] Can you two folks provide specific clarifications why you think that the so-called QOS models like Y.1541, 3GPP/Y.1451 and DSTE have the smae properties like those of RSVP, IntServ, and DiffServ? If not, why do you two folks just say the the obvious truth that these Y.1541, 3GPP/Y.1541, and DSTE are NOT be considered as QOS models?

[RRR] If you two folks want to generalize mixing apples and oranges together, there will be no e2e QOS or no QOS interoperability, and NSIS QOS signaling will be of little for using for any practical purpose.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Sun, 05 Nov 2006 20:15:27 +0100

Hi Radhika,

I'm always a little bit puzzled by your postings, but
I'll try to provide answers inline nevertheless.

> [RRR] Now it reveals the fact that there is no socpe for
> interoperability in using different QOS models. If it is so, did Dave
> and Roland analyze the root cause of this interoperability problem?

I guess that it's not generally possible to map any arbitrary QoS
model to all others.

> [RRR] If you folks do not analyze for each QOS model and want to
> generalize for all QOS models, you are NOT doing your technical
> analysis correctly and are sending the WRONG message to the entire
> NSIS technical community mixing apples and oragnes as if all QOS
> models have the same properties.

Sorry, but I guess you are completely misled here.
The idea is to have something like a generic QSPEC which
allows to map to all models. Example:
An end-host signals a Generic QSPEC that
specifies Traffic source (token bucket)
and Constraints, e.g., packet loss or allowed deviation
from average throughput.
So if the first domain now supports Y.1541, you have to define a mapping
in this particular QoS model, e.g. you must choose the appropriate QoS
class to put this reservation in while satisfying the constraints.
If the next domain then supports a QoS model consisting of the
12 DiffServ classes according to RFC4594 this domain must map the
generic QSPEC request to a particular service class in its own domain.
The same procedure will be repeated until you hit the other end host.
However, each QoS model must define a mapping from the generic QSPEC
to its own QoS model (e.g. service classes).

> [RRR} Did you folks know that RSVP, DiffServ, and IntServ QOS models
> interowrk among themselves using QSPEC template with NSIS QOS
> signaling messages. If so, why are you not ponting out this?

Its difficult to put all QoS models into one QSPEC because you
must also define the appropriate mapping between all. This is
difficult because there are some service classes that cannot
be easily mapped to the classes of the another QoS model. Therefore
this huge set of mandatory parameters which leads to nowhere.
Its easier to use a generic QSPEC like the one proposed by Dave
and to let each QoS model map this to its own service classes.
This appears to be more viable to me than the previous approach.

> [RRR} Is it not the case the so-called QOS models like Y.1451,
> 3GPP/Y.1541, and DSTE that do NOT qualify to be QOS models in the
> first place are the root cause of all problems? Why do you not speak
> out for these cases specifically? What is your problem?

Y.1541 is a valid QoS model that a domain may provide. No problem
with this.

> [RRR] Again, it is a too general statement. Let us taken an example
> and analyze for each QOS model and examine where and how each QOS
> model fails. If we do not do this, there is no clear conlusion in
> support of this to "generic" statement.

It's not about failure of QoS models.

> [RRR] If you analyze each QOS model, you can easilty see the three
> QOS mdoels RSVP, IntServ, and DiffServ are in synch in all respects.
> There are no ambigutiies to deal with either with traffic
> descriptions or or any QOS parameters because they have standardized
> the basic QOS characteristics for which there are proper mapping can
> be done. In fact, it is happening since their inception. NSIS QOS
> signaling is jus doing fine with these three QOS models. Do you see
> what has been the basic objective of NSIS QOS signaling? Is it not
> that the NSIS QOS signaling is the SECOND vesrion of RSVP with more
> "scalability" for end-to-end QOS signaling?

Mapping between these models may be easier than between other models.

> [RRR] If you folks forget these basic objectives of NSIS QOS
> signaling and want create unnecessary problems bring the so-called
> hard-coded some implementation-specific QOS parameters with any
> fundamental QOS properties like Y.1541 and DSTE, how can you be
> "objective" in solving the QOS interoperability problem for e2e QOS
> in NSIS for which it is being standardized?

We are not proposing to throw out any existing QoS models.
If you want to use Y.1541, fine. However, you will not be
able to directly signal QoS in your Y.1541 specific manner
from end to end or between domains using different QoS models.
You should stick to the generic QSPEC instead.

>> signalling sequence diagram defined differently in each
>> standards-body especially for different access networks" is a
>> problem, not a good thing, and the way to deal with it is not to
>> import every one of those into NSIS, but rather to map "down" to
>> the particular domain's model in individual QNEs. If they in turn
>> need to do some private signaling among themselves (e.g. DOCSIS,
>> 802.11e) that's their business.
> 
> Agree.
> 
> 
> [RRR] It is not true when it is gemeralized with the things mixing
> between "apples" and "oranges." Kindly see the technical explanations
> as ststed above.

???

> [RRR] Can you provide an example taking the RSVP, IntServ, and
> DiffServ and show where are the problems and we can understand more
> clearly?

I gave an example above.

> That matches nearly exactly my opionion which I expressed once at the
> first interim meeting in Helsinki back in 2002. I said that this 
> [RRR] I do not see this as it is explaned here. The basic idea of
> NSIS QOS signaling protocol has been end-to-end signaling. NSIS
> charter is clear about this. No only this, NSIS has clear code points

Yes and that's what I'm saying. So NSIS is about end-to-end QoS
signaling. However, what you signal in your own domain may use
NSIS or something completely different.

> how each application will be able to signal its desired QOS in NSIS
> upper layer. The specific application sitting in both ends of the
> network will be able to communicate transparently for providing the
> end-to-end QOS. As I explained to Ronald last time, NSIS is not just
> e2e network layer signaling.

It's not? No you also can signal end-to-edge, edge-to-edge,
middle-to-end, end-to-end whatever...

> [RRR] If NSIS is NOT developing the e2e QOS between the application
> connected to the two ends of the network, there will probably no need
> for another protocol like NSIS QOS signaling because the traditional
> QOS signaling with RSVP/IntServ in the access network and DiffServ in
> the backbone network is doing just fine.

No it's not, that's why NSIS was initiated.
Probably you should go back and read RFCs 3726, 4094, and 3583.

> [RRR] After all these years of hard works when NSIS signaling is
> robust enough to provide the end-to-end QOS signaling, and QSPEC
> templates that are quite OK for the RSVP, IntServ, and DiffServ QOS
> models for interoperability, why you two folks want to turn the
> wheels back?

No, we don't want to turn wheels back. We want to move the work forward.

> [RRR] Can you two folks provide specific clarifications why you think
> that the so-called QOS models like Y.1541, 3GPP/Y.1451 and DSTE have
> the smae properties like those of RSVP, IntServ, and DiffServ? If
> not, why do you two folks just say the the obvious truth that these
> Y.1541, 3GPP/Y.1541, and DSTE are NOT be considered as QOS models?

Using Y.1541 is just fine. No problem.

> [RRR] If you two folks want to generalize mixing apples and oranges
> together, there will be no e2e QOS or no QOS interoperability, and
> NSIS QOS signaling will be of little for using for any practical
> purpose.

That's jsut the goal. We are trying to avoid ending up with
a non-interoperable e2e QoS signaling.

Roland (not Ronald) ;^)

---

From: Roland Bless <[email-masked]>
Date: Mon, 06 Nov 2006 05:11:14 +0100

Hi Jerry and all,

after todays discussion, please see my comments below.

> Please review and comment on the proposed changes.

That's a step in the right direction.
I'd like to go a little bit further and propose the following
(after some more discussion with Jukka):
1. Remove even the QoS model specific stuff from the current QSPEC,
   e.g. Y.1541, DSTE, DiffServ classes/PHB-IDs, IntServ classes etc.

2. Call the new proposal "Generic QSPEC" or "E2E-QSPEC" which
   must be understood by any QoS model (that's why I call it generic).
   and expresses what end-to-end QoS requirements a QNI has.
   This is necessary in order to have a clear distinction from the
   QOSM-specific QSPECs as introduced next.

3. Defining QOSM-specific QSPECs if the E2E-QSPEC is not sufficient for
   admission control or must be treated in a special way.
   BUT: each QoS model must "preserve" the E2E-QSPEC and define how
   to map it to its own QoS model (e.g. which service class should be
   used in order to fulfill an E2E-QSPEC), and, if defined, how the
   QOSM-specific QSPEC is built.
   This QOSM-specific QSPEC would be created by ingress nodes and
   terminated by egress nodes of a domain.
   For example we will have an RMD-QSPEC to signal PHR specific stuff
   or a Y1541-QSPEC for signaling the chosen Y.1541 class and other
   specific parameters. So internal nodes may perform easier
   admission control by only looking at these parameters that were
   set by the edge node and ignoring what's in the E2E-QSPEC.

4. Remove QSPEC stacking from QoS-NSLP. We will have only
   one QSPEC object which is passed to the RMF. But due to the
   requirement that the E2E-QSPEC must be preserved it may be
   necessary for an edge node to "encapsulate" the E2E-QSPEC
   in the QOSM-specific QSPEC. So an RMD-QSPEC may simply include
   the E2E-QSPEC, but mainly for carrying to the egress node
   transparently, i.e. internal nodes will ignore the content of
   the E2E-QSPEC and only pay attention to the RMD-QSPEC-specific
   stuff (aggregate bandwith etc.). The edge nodes may interpret
   and modify the E2E-QSPEC as required (e.g. set QoS available etc.).
   The egress node will pass only the E2E-QSPEC in the RESERVE
   to the next domain. Furthermore we will have the possibility
   to introduce a type of local QSPECs (non-standardized) that
   do not have to be registered at IANA.
   A specific QSPEC may also carry more than the E2E-QSPEC, e.g.,
   as Dave mentioned some additional L2-QSPEC.
   I guess Jukka and I have identified a few advantages for
   QoS NSLP processing if we do it this way. QoS NSLP will
   basically only specify a QSPEC common header that contains an
   ID for the QSPEC-type.

This would boil down to the following:
- the E2E-QSPEC must be understood by every QoS model, thus
  it is always signaled inter-domain.
- the E2E-QSPEC may be remapped to some internal QoS model
  parameters at the edge of a domain. These parameters may
  be signaled internally via some QOSM-specific QSPEC.
  Semantics and content of the E2E-QSPEC must be preserved
  tough.
- The QoS NSLP implementation doesn't have to care about
  stacked QSPECs or which QSPEC object is actually relevant
  or of interest for the RMF, so we can easily support
  different QOSMs in a QNE providing different RMFs.
- QoS model specific stuff is removed from the current
  QSPEC template document and goes into the QoS model
  definition documents.
- The new approach allows to use and deploy new QoS models
  easily without changing the overall E2E-QSPEC definition.

Example for two different domains using their own QOSM-QSPEC
which will simply include QOSM-specific parameters as well
as the E2E-QSPEC.

                     RMD                        Y.1541
               +-------------+             +-------------+
    E2E-QSPEC /   RMD-QSPEC   \ E2E-QSPEC /  Y.1541-QSPEC \ E2E-QSPEC
QNI---------->QNE--->QNE--->QNE---------->QNE--->QNE--->QNE---------->QNR
              \               /           \               /
               +-------------+             +-------------+
Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 6 Nov 2006 06:45:41 +0200 (EET)

After long discussions with Roland, I see the benefits in Roland's ideas, 
and support this proposal.

Jukka