Re: DISCUSS Comments from Tim Polk on QSPEC Draft

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

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