Subject: [NSIS] RE: Proposed Updates to the QSPEC Draft

From: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Tue, 7 Nov 2006 16:41:57 -0600

Hi All,

A number of us met on Sunday to discuss the proposed updates to the
QSPEC draft.  The discussion focused on the issues raised on the list in
the last few days regarding the proposal (see below), i.e., that it
should be possible to 'translate' the TMOD parameter to bandwidth within
a local domain (e.g., RMD domain) and that QSPEC stacking should be
retained.  

We agreed that stacking would be a desirable capability in some domains
(e.g., RMD) to simplify control plane processing.  Stacking also allows
a TMOD parameter to be 'translated' to a bandwidth equivalent TMOD
parameter within a local domain.

Attached are draft slides that I intend to discuss at the NSIS meeting
on Thursday AM.  The agreements that we made are pretty much summarized
on slide 8.

Please let us know of any comments on the slides.

Thanks,
Jerry 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS 
Sent: Wednesday, November 01, 2006 5:13 PM
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; 'David R Oran'; 'Kappler, Cornelia';
'Cornelia Kappler'
Subject: 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: "Ash, Gerald R \(Jerry\), NPE" <[email-masked]>
Date: Tue, 7 Nov 2006 19:00:11 -0600

Hi All,

Thanks,
Jerry 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS 
Sent: Wednesday, November 01, 2006 5:13 PM
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; 'David R Oran'; 'Kappler, Cornelia';
'Cornelia Kappler'

Hi All,

Eliminated:
 bandwidth
 Ctot, Dtot, Csum, Dsum

7. Editorial changes:

Thanks,
Jerry, Dave, Cornelia

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 08 Nov 2006 22:32:43 +0000

Hi Jerry

I think taht the slides encompass most of the points of the reached
consensus, except the fact that we talked about using stacking of more
than one QSPEC objects, where only one of them is the end-to-end QSPEC
and the rest are private/local QSPECs that are belonging to
hierearchical nested QoS models.
Could you please also check the 3 points of consensus that I have
summarized in the e-mail that I have sent yestrday on the nsis mailing
list.

Best Regards,
Georgios