Subject: [NSIS] DISCUSS Comments from Tim Polk on QSPEC Draft

From: Gerald Ash <[email-masked]>
Date: Sat, 23 Jan 2010 11:43:29 -0800 (PST)

All,
 
Here are DISCUSS comments from Tim Polk on his review of the QSPEC draft.  Below I give proposed responses.  Please let me know of any comments.
 
Thanks,
Jerry
 
1. Tim Polk DISCUSS comment:
"The implications of making Minimum QoS optional are not clear to me.  Does a
QNE that does not support Minimum QoS ignore this object or reject the message?
If the object is ignored, the QNI could receive a RESPONSE where QoS Reserved
is less than Minimum QoS.  If the message is rejected, the QNI may be denied
service where acceptable levels of service were available."
 
Jerry:
Tim Polk has a valid point.  I don't recall all the discussion regarding why Minimum QoS was made optional.  I think initially a more complex version of Minimum QoS was being proposed (by Roland perhaps?) and folks didn't want to require that for all implementations.  However, the complex version was not specified and I don't see Minimum QoS processing, as currently specified, as being any more complicated that Available QoS processing.  My suggestion is to require that Minimum QoS MUST be supported along with the other 3 QSPEC objects.  Otherwise, if Minimum QoS is optional, behaviors clearly must be specified for when it is not supported.  IMO the simplest approach would be to have the reservation aborted if Minimum QoS is included by the QNI but not supported by a QNE.  It's unclear, however, if that makes sense for the QUERY step in Case 2 described in Section 4.3.2.  In any case, keeping Minimum QoS as optional and specifying
 behaviors will get complex and permeate many parts of the QSPEC.  I strongly suggest we require that Minimum QoS must be supported.
 
Proposed response:
Good point.  Clearly the behaviors for when Minimum QoS is not supported would need to be specified.  However, if Minimum QoS is not supported by a QNE, either aborting a reservation or ignoring the object lead to undesired consequences, as you point out.  We propose to require that Minimum QoS must be supported along with the 3 other QSPEC objects.
 
2. Tim Polk DISCUSS comment:
"Section 4.3.2, Case 3 implies an overloading of the QoS Available semantics in
the absence of a Minimum QoS object:

   Some parameters in the QoS Available object may the same as in the
   QoS Desired object.  For these parameters the implicit message is
   that the sender would be satisfied by a reservation with lower
   parameter values than specified in QoS Desired.

Differentiating this overloading from a case where the QNI does not support
Minimum QoS is not straightforward to this reader, or how this would change the
behavior of a QNE processing the message."
 
Jerry:
It appears that making support of Minimum QoS mandatory will eliminate this concern.
 
Proposed Response:
We propose to make support of the Minimum QoS object mandatory, which should eliminate this concern.

---

From: Roland Bless <[email-masked]>
Date: Mon, 25 Jan 2010 11:26:13 +0100

Hi Jerry,

Gerald Ash wrote:
> All,
>  
> Here are DISCUSS comments from Tim Polk on his review of the QSPEC
> draft.  Below I give proposed responses.  Please let me know of any
> comments.
>  
> Thanks,
> Jerry
>  
> Tim Polk has a valid point.  I don't recall all the discussion regarding
> why Minimum QoS was made optional.  I think initially a more complex
> version of Minimum QoS was being proposed (by Roland perhaps?) and folks
> didn't want to require that for all implementations.  However, the

Yes, I suggested adding the ability to specify an interval
and I think that you're correct that someone tried to make it
optional.

> complex version was not specified and I don't see Minimum QoS
> processing, as currently specified, as being any more complicated that
> Available QoS processing.  My suggestion is to require that Minimum QoS
> MUST be supported along with the other 3 QSPEC objects.  Otherwise, if
> Minimum QoS is optional, behaviors clearly must be specified for when it
> is not supported.  IMO the simplest approach would be to have the
> reservation aborted if Minimum QoS is included by the QNI but not
> supported by a QNE.  It's unclear, however, if that makes sense for the
> QUERY step in Case 2 described in Section 4.3.2.  In any case, keeping
> Minimum QoS as optional and specifying behaviors will get complex and
> permeate many parts of the QSPEC.  I strongly suggest we require that
> Minimum QoS must be supported.

I agree. Usually one would always request a minimum QoS and
if it cannot be admitted, the reservation will fail. So the
desired QoS bound is something that would be nice to have,
but anything between min and desired would be acceptable.
So in this case the min QoS would be always required and the
desired QoS would be an optional upper bound. In any way
both bounds must be supported and understood by implementations.

> Proposed response:
> Good point.  Clearly the behaviors for when Minimum QoS is not supported
> would need to be specified.  However, if Minimum QoS is not supported by
> a QNE, either aborting a reservation or ignoring the object lead to
> undesired consequences, as you point out.  We propose to require that
> Minimum QoS must be supported along with the 3 other QSPEC objects.

Roland