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

From: [email-masked]
Date: Fri, 8 Mar 2002 14:19:09 +0100

Hi Roland,

The idea of allowing a range for a certain QoS parameter in the request is
interesting.
You suggest that no explicit acknowledgement is needed of the reservation
request since
the actual value will be within the requested range. Hence, a simple ACK
would be sufficient.

Although I agree with the 'keep things simple' principle, there still may
be a need to explicitly
notify the QoS requester about the actual values for the QoS parameters
(e.g. delay, jitter)
that the network guarantees. In this case an application may base decisions
about
packetization delay and dejittering delay on it.

Example: for VoIP applications it is known that the maximum mouth-to-ear
delay is 150 ms.
When the application is explicitly notified about the end-to-end network
delay it can decide
how much delay budget is left for e.g. packetization delay.

Hence, I suggest the following:
- ability to request from a range of QoS parameters
- the ability to explicitly notify the QoS requester about
  the actual values of the QoS parameters

Maarten.

Roland Bless <[email-masked]> on 08/03/2002 10:42:07

 To:      [email-masked]                             
                                                              
 cc:      Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,              
          [email-masked], [email-masked],          
          [email-masked](bcc: Maarten            
          BUCHLI/BE/ALCATEL)                                  

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

Hi John,

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

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.

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

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.

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

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

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

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

---

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

Hi Maarten,

> the actual value will be within the requested range. Hence, a simple ACK

Yes (but for the ACK see below).

> packetization delay and dejittering delay on it.

Oh, you took my ACK to literally. Sure, the response should contain
the actual supplied parameter values (I assumed this implicitly :-).

>   the actual values of the QoS parameters

Sure, full agreement with my view.

Regards,
 Roland