Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt

From: [email-masked]
Date: Fri, 8 Mar 2002 11:25:24 +0200

Hi Roland,

> So in the request a range of acceptable parameter values is
> specified. Any value within the range will be acceptable
> for the requester, so the last dialogue of your example will
> not be necessary.

So, you would like these requirements to be:

	Ability to request from a range of QoS parameters

-> the problem is, then what is the policy in fufilling 
   the range, lowest value, highest value, medium value,
   etc. One solution is not to use absolute QoS parameters,
   but to use relative.

> So in the request a range of acceptable parameter values is
> specified. Any value within the range will be acceptable
> for the requester, so the last dialogue of your example will
> not be necessary.

Does this mean there should not be any acknowledgement
of what is then accepted?

John

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 08 Mar 2002 10:42:07 +0100

Hi John,

> 	Ability to request from a range of QoS parameters

In some sense yes, but this requirement relates to the service object
which is transparent for nsis and service dependent, so not really
in nsis scope.

>    etc. One solution is not to use absolute QoS parameters,

Oh, just as I said: Any value within the range will be fine
for the requesting party, and, thus accepted. If one needs
a specific value, you just set the interval bounds to an
equal value. 
The policy for admission control also depends on the concrete
QoS parameter (out of nsis scope). Thus, a service provider
may test for the higher bandwidth value at first and later 
for the lower value, whereas for delay it is typically the
other way round. However, this is not something we really
have to directly deal with.

> of what is then accepted?

Yes, let's keep thing simple.
The requesting party won't have to acknowledge the result 
explicitly, because  any result within the range has to be
accepted. Otherwise the requester should have specified
a different interval. However, there is always the 
possibility to abort a reservation at any time.
An explicit acknowledgement would imply that another
round trip time would be required to actually activate 
the pre-reserved resources along the path. This should be
avoided.

Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097