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

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

Hi Dave

You mention that remapping of the Token bucket to bandwidth is not allowed
but it is allowed 
to interpret the peak bandwidth parameter value.

Do you mean that a QNE can use the peak bandwidth parameter and ignore 
all the other Token Bucket parameters?

Regarding the signifficance of the QSPEC stacking please refer to Section
3.2.8 in:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt

Best Regards,
Georgios

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: donderdag 2 november 2006 15:21
> To: Georgios Karagiannis
> Cc: 'Ash, Gerald R (Jerry), ALABS'; [email-masked]; 'Cornelia 
> Kappler'; 'Kappler,Cornelia'; 'Attila Báder (IJ/ETH)' ; 'Lars 
> Westberg (KI/EAB)'; 'Magnus Westerlund'; 'Lars Eggert'; 
> [email-masked]; [email-masked]
> Subject: Re: [NSIS] Proposed Updates to the QSPEC Draft
> 
> 
> On Nov 2, 2006, at 8:38 AM, Georgios Karagiannis wrote:
> 
> > 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.
> >
> How do you reach this conclusion? Could you give an example 
> of what doesn't work for diffserv?
> 
> > 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.
> Yes, this was intentional. There is no need to remap in the 
> NSIS signaling. A given QOSM's RMF can simply interpret the 
> peak bandwidth parameter as their 
> admitted/shaped/policed/queued bandwidth. This behavior would 
> be documented in the QOSM application document for RMD.
> 
> > I do not understand why, since we have had a consensus on 
> this point 
> > in the nsis mailing list.
> What seems to have happened (at least from my vantage point 
> as a long- time lurker and occasional contributor) is that as 
> we got down to reach closure on issues around the mandatory 
> nature of QSPEC parameters and why certain QOSMs wanted 
> certain parameters for certain purposes, we got to a 
> deadlock. Removing the deadlock simply by blowing away any 
> common interoperable behavior for NSIS (by declaring 
> everything optional) would likely have run straight into a 
> brick wall in the IESG. This prompted my, Jerry and Cornelia 
> to take a step back, put our heads together, and try to 
> figure out what the underlying problems were. Our assessment, 
> captured in the proposal we just made, was that in order to 
> maintain flexibility but still have global interoperability 
> we needed to step back and rethink some of the more complex 
> and confusing parts of the QSPEC design. We did that and you 
> see the result. It's a matter of point of view whether one 
> considers this "big change" or "valuable simplification".
> 
> > This proposal also removes the QSPEC stacking concept, 
> which is one of 
> > the most significant concepts in the QoS based NSIS solution.
> So, we clearly missed the significance, so perhaps you need 
> to go back and re-educate us. No other QOSM I know of other 
> than RMD claims to need this functionality.
> 
> > 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.
> >
> Not necessarily. What we may need to do is rethink a bit how 
> RMD integrates with NSIS as a QOSM. the other possibility is 
> for the WG to reject our approach and stay with what's in the 
> QPSEC draft today.
> 
> > 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.
> >
> It is a change/simplification. What I don't get (I won't 
> speak for Jerry or Cornelia, but neither of them could come 
> up with a succinct explanation when we discussed this) is 
> exactly what this flexibility is and why it matters.
> 
> >
> >
> >> 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.
> >
> I'm lost. what leads you to this conclusion?
> 
> >
> >> 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 ???
> >
> >
> Possibly, since I'm not sure the goal of NSIS was ever to be 
> just a schematic shell for inserting individual QOSM-specific 
> signaling protocols. If it was, then clearly my understanding 
> of the NSIS architecture and what I read in the NSIS charter 
> does not correspond to the WG consensus our changes to the 
> QSPEC draft would be ill-advised.
> 
> >
> >> 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.
> If you mean "interpreted by the RMD QOSM as bandwidth" then 
> we are in agreement. If you mean "modified in the NSLP 
> signaling and QSPEC by replacing the <peak bandwidth 
> parameter> with a <bandwidth> parameter, possibly stacking 
> the new QPEC with <bandwidth> instead of <peak bandwidth>" 
> then that's where we disagreed with the current approach in 
> fact departed from the current spec.
> 
> The problem with both remapping and stacking is that they do 
> not constrain the semantics of the end-to-end signaling, and 
> introduce considerable complexity into the protocol.
> 
> >  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

---

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

> to interpret the peak bandwidth parameter value.
Correct.

> all the other Token Bucket parameters?
If the QNE deterministically has enough buffering to absorb any  
burst, and its scheduling accuracy is sufficient to not worry about  
the distortions of having a non-zero minimum-policed unit, and that  
it prefers to be pessimistic in admission control by considering only  
peak and not average rate, then yes.

> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt
I'll go back and read that again. Thanks.