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

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 2 Nov 2006 15:00:04 +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!

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
> Sent: woensdag 1 november 2006 23: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 
> 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.

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.

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

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.

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

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

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

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

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

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

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!

> 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

Georgios: I do not agree, See above!

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

Georgios: I do not agree, See above!

> Please review and comment on the proposed changes.
> Thanks,
> Jerry, Dave, Cornelia

Best Regards,
Georgios

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