Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 3 May 2006 13:02:25 -0500

Hi Andrew,

We're still awaiting your proposed response/resolution to this issue RE
QoS-NSLP error codes.  This is one remaining issue needing resolution
for the QSPEC I-D to be reissued, as requested by John on 10 April
http://www1.ietf.org/mail-archive/web/nsis/current/msg06158.html.   

See the attached thread, which ended with my post on 16 March,
http://www1.ietf.org/mail-archive/web/nsis/current/msg06060.html, where
I made some suggestions to resolve the issue.  We discussed this
suggestion at the NSIS breakfast meeting in Dallas, but I think you
wanted to better separate the signaling aspects of the error codes
(should be specified in QoS-NSLP) from the QSPEC/RMF aspects (which
should be specified in QSPEC).

Please let us know what you propose to resolve this issue.

Thanks,
Regards,
Jerry 

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS 
Sent: Thursday, March 16, 2006 12:42 PM
To: 'Andrew McDonald'; [email-masked]'
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]';
[email-masked]'
Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes

Hi Andrew, All,

Please see comments in line:

> -----Original Message-----
> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: Thursday, March 09, 2006 12:23 PM
> To: Jukka MJ Manner; Georgios Karagiannis
> Cc: [email-masked]
> Subject: [NSIS] QoS NSLP INFO_SPEC and error codes
> 
> A few comments in the area of the INFO_SPEC object and error codes.
> 
> Draft -10 doesn't seem to have appeared yet, but these comments apply 
> equally to -09 and -10.
> 
> Protocol errors include:
>           *  0x08 - Unknown QSPEC type: the QoS Model ID refers to a
>                     QoS Model which is not known by this QNE.
> It's not clear to me that is a protocol error. Firstly, QoS Model ID
> is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly,
> my understanding from the QSPEC template is that, in the case of an
> unknown QoS Model ID, the RMF should continue to process mandatory 
> QSPEC parameters.

Jerry> Both comments are correct.  This error subcode should probably be
deleted.  Should it be replaced by some other type of error involving
QOSM ID (none come to mind for me)?
 
> Transient failure codes include:
>           *  0x01 - Requested resources not available
>           *  0x02 - Insufficient bandwidth available
>           *  0x03 - Delay requirement cannot be met
> 
> Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since
> they directly relate to information in the QSPEC rather than the
> main QoS NSLP data?

Jerry> I agree that 0x02 and 0x03 are specific cases of 0x01, but they
are not IMO "QoS model specific" since <Bandwidth> is a mandatory QSPEC
parameter and <Path Latency> is an optional QSPEC parameter.  Similarly,
perhaps "cannot be met" error subcodes should be defined for <Path
Jitter>, <Path PLR>, and <Path PER> parameters, which are also optional
QSPEC parameters.  

Perhaps it's better to describe the '4-bit error class', '12-bit error
codes', and '8-bit QoS model-specific error subcode' in terms of
"QSPEC/RMF-specific" rather than "QoS Model specific".

So then the 4-bit error class 
"0x06 - QoS model-specific Error" 
becomes 
"0x06 - QSPEC/RMF-specific Error".

And also redefine the 
"8-bit QoS model-specific error subcode" 
as
"8-bit QSPEC/RMF-specific error subcode".

Then within the 4-bit error class "0x06 - QSPEC/RMF-specific Error" the
following 12-bit error code is defined (now a 'transient failure code"):
0x01 - Requested resources not available

And within that 12-bit error code the following "8-bit
QSPEC/RMF-specific error subcodes" are defined:

0x02 - <Bandwidth> cannot be met
0x03 - <Path Latency> cannot be met
and perhaps others, e.g.,
0xab - <Path Jitter> cannot be met
0xcd - <Path PLR> cannot be met
0xef - <Path PER> cannot be met 
etc.

These error codes pertaining to mandatory/optional QSPEC parameters
(defined within the QSPEC I-D) can either be defined in the QoS-NSLP I-D
(preferably IMO) or alternatively within the QSPEC I-D.
 
Additional 'QSPEC/RMF-specific Errors' and their '12-bit error code' and
'8-bit QSPEC/RMF-specific error subcodes' pertaining to (optional) QSPEC
parameters defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM,
etc.) should also be defined in the QOSM-specific I-Ds.

Should any of the above be identified as issues to be discussed at
IETF-65?

Please let me know what you think.

Thanks,
Regards,
Jerry

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

---

From: Andrew McDonald <[email-masked]>
Date: Mon, 08 May 2006 10:51:41 +0100

Hi Jerry,

I've been looking at some scribbled notes I've got, and subsequent
e-mails on the subject.

At the breakfast meeting, the thing I seem to have jotted down was "use
the Optional Error-Specific Information" component of the INFO_SPEC for
QSpec information.

However, in some subsequent off-list discussion, I think I went off this
idea a bit. The main problem is that you drag information about QSPEC
parameters into the NSLP. Stacking may also create issues with this.

The subsequent suggestion was, I believe, that the QoS NSLP should 
provided a limited set of error codes (e.g. "Total Success", "Partial 
Success", "Total Failure"). The QSpec parameters then have a flag to 
indicate which (if any) parameters failed to be satisfied. This is 
signalled back to the QNI in the response. The QNI then makes the 
determination about whether to continue or tear down the partial 
reservation that has been established.

Does that sound reasonable? Does it fit with other peoples thoughts?

Does the 'E' flag in the QSPEC parameters already provide the necessary 
QSpec information? (not clear if 'error' covers 'reservation could not 
be satisfied')

Something I've also noticed in looking at the QSpec template document is 
that the introduction talks about its role as a 'toolbox', but does not 
talk about the processing flexibility aspect (e.g. the fact that it 
allows for nodes that support different subsets of QSpec parameters).

Andrew

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 16 May 2006 15:56:33 -0500

Hi Andrew,

See comments below.

Thanks,
Jerry

> Sent: Monday, May 08, 2006 5:52 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [NSIS] QoS NSLP INFO_SPEC and error codes
> 
> Hi Jerry,
> 
> At the breakfast meeting, the thing I seem to have jotted down was
> "use the Optional Error-Specific Information" component of the 
> INFO_SPEC for QSpec information.
> 
> However, in some subsequent off-list discussion, I think I went
> off this idea a bit. The main problem is that you drag information
> about QSPEC parameters into the NSLP. Stacking may also create
> issues with this.
> 

This sounds reasonable to me.  We need to nail down how this error code
functionality will work.  

What is now specified in the QSPEC I-D (Section 4.5.1 in
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt) is as
follows:

"When an RMF cannot interpret the QSPEC because the coding is
   erroneous, it raises corresponding flags in the QSPEC.  The 'error
   flags' are located in each QSPEC Object and in each parameter.  If
   such a flag is set, at least one QNE along the data transmission path
   between the QNI and QNR cannot interpret a mandatory or optional
   QSPEC parameter or the QSPEC object for any reason, such as a
   protocol error, QNE fault, etc.  In this case, more detailed error
   information may be given in the QoS NSLP error message.  That is, if
   possible the RMF must communicate error details to the QoS NSLP
   processing.  QoS NSLP [QoS-SIG] describes how the erroneous message
   is handled further.

   As stated in Section 5.1.3.6 (INFO_SPEC) of [QoS-SIG]:
   "Values in the error subcode field are defined in each QOSM
   specification separately. The default value for the subcode is 0x00.
   A default value means that the QoS model does not want or does not
   need to give more information about the error/result, anything else
   in the subcode must be defined in the QoS model specification."

   That is, any additional error codes beyond those defined in [QoS-SIG]
   MUST be defined in individual QOSM specifications."

I suggest this be modified along the lines of your suggestion so that
QSPEC/RMF-specific codes are identified in the QSPEC I-D.  That is, for
example, the 4-bit error class is defined in QoS-NSLP as follows:

"0x06 - QSPEC/RMF-specific Error"
This error is set by QoS-NSLP if QSPEC/RMF sets an 8-bit
QSPEC/RMF-specific error subcode, specified below.  Perhaps other
QSPEC/RMF-specific error codes can be defined in QoS-NSLP based on
QSPEC/RMF specific failure conditions.

Within the 4-bit error class "0x06 - QSPEC/RMF-specific Error", the
"8-bit QSPEC/RMF-specific error subcodes" are defined and set by
QSPEC/RMF; for example:

These '8-bit QSPEC/RMF-specific error subcodes' pertain to QSPEC
parameters and are defined within the QSPEC I-D.  Additional '8-bit
QSPEC/RMF-specific error subcodes' pertaining to QSPEC parameters
defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should
also be defined in the QOSM-specific I-Ds.

Does this sound OK?  If not, please make a counter proposal.

> Does the 'E' flag in the QSPEC parameters already provide the 
> necessary QSpec information? (not clear if 'error' covers
> 'reservation could not be satisfied')

As above, the 'E flag' would be set by QSPEC/RMF if some error condition
arises wrt a QSPEC parameter.  The '8-bit QSPEC/RMF-specific error
subcode' is set by QSPEC/RMF to a specific value if additional
information on the error is to be conveyed to the QNI.
 
> Something I've also noticed in looking at the QSpec template 
> document is that the introduction talks about its role as a
> 'toolbox', but does not talk about the processing flexibility aspect
> (e.g. the fact that it allows for nodes that support different
> subsets of QSpec parameters).

Good point, the 'different subsets of QSPEC parameters' functionality
needs to be added in the introduction.  I think we need to revise
somewhat the 'toolbox' description to clarify.

---

From: Andrew McDonald <[email-masked]>
Date: Sat, 27 May 2006 15:13:08 +0100

Hi Jerry,

Some comments below.

> information on the error is to be conveyed to the QNI.

That doesn't really fit with what I was trying to say, obviously my
explanation was somewhat unclear. I'll try to clarify this.

As a starting point, I don't think the proposal above fully holds 
together. For  example, what happens if both Bandwidth *and* Latency 
can't be met?

My main problem with the QSpec/RMF-related error handling is that I am
still unclear what the requirements are. The two things that I can see 
at the moment are both about signalling errors about particular QSPEC 
parameters:
- parameter can't be met (e.g. can't provide the requested bandwidth)
- malformed parameter

Are there any problems other than these two that need to be signalled?

The next question is whether the 'E' flag indicate one or both of these?

My recommendation would be to get rid of the "Error subcode" in the 
INFO_SPEC entirely. At the moment, it only seems to fulfil a role in the 
special case of the QSpec/RMF errors. If something is needed there then 
this could be done in other ways; for example, by providing 
"error-specific information" (in the space provided by the INFO_SPEC).

I would suggest that the 'E' flag identifies parameters that failed to 
be met. The INFO_SPEC would simply say "Partial Success" (or "Total 
Failure") and the QSPEC would carry sufficient information (in the E 
flags) to identify where the problem was.

Where there are malformed parameters, I would suggest that this is 
signalled back by a "Malformed object" error (an additional code that is 
a bit more generic than the "Bad length", etc currently available). This 
error would also carry error specific information in the form of the 
'object value info' (p45 of qos-nslp draft -11). This means that the 
entire QSPEC would be returned with the error. This proposal for 
indicating malformed QSPEC contents does lack the ability to identify 
which parameter was malformed. If this is an issue we could probably 
address it, still with a design roughly along the same lines.

best regards,

Andrew