Subject: Re: comments on rsvp spec

From: [email-masked] (Francois Toutain)
Date: Mon, 3 Apr 95 15:03:36 +0200

>	Also, the possibility of "existing reservation failure" isn't
>	mentioned.  Policy guidelines might require the "bumping" of certain
>	reservations when a "more important" request comes through.  An
>	administrator may also decide that too many of their precious
>	resources are being used for reserved traffic (best-effort users are
>	complaining) and therefore reduce the amount of reservable resources,
>	requiring the termination of one or more reservations.
	
How high do you think users are willing to be charged if their
reservations may be subject to such abrupt termination ? Which criteria
should be used to select the unlucky reservations ? How could request
"importance" be characterized ? Why should a reservation be broken when
the others are full quality streams (could be degradated, perhaps) ?

Very interesting topic, indeed...

Francois Toutain

----- End Included Message -----

----- Begin Included Message -----

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 3 Apr 95 11:27:49 -0400

From: [email-masked] (Francois Toutain)

    > Policy guidelines might require the "bumping" of certain reservations
    > when a "more important" request comes through.

    How high do you think users are willing to be charged if their
    reservations may be subject to such abrupt termination?

I expect that would be part of the pricing policy agreed to between the
customer and the provider. I.e. reservations are X cents per megabit/minute,
if you allow yourself to be preempted, or X+Y cents if you don't allow
preemption. In other words, you, the customer, get to make the cost/benefit
tradeoff, and you pay more for the higher grade of service.

    Why should a reservation be broken when the others are full quality
    streams (could be degradated, perhaps)?

It depends on the application. I assume you're not using a reservation of
Z mbits/second unless your application is inelastic, and needs that much
bandwidth before it will run. If so, the pricing structure above is the one
that is of interest to you.

If, on the other hand, your application has *some* elasticity, maybe there's a
third class of service, priced in between the other two, that says you always
get a minimum bandwidth, but you aren't always guaranteed to get the maximum
you need.

Exactly which out of the many classes of service we can dream up will be
useful in practise, and how many it will be economical to provide, are I
suspect things that experience will teach us, but will be hard to predict up
front.

I expect Scott Shenker or some of the other Int-Serv experts have thought
through this a lot further, so perhaps they have something more definite to
say about that.

	Noel

----- End Included Message -----

----- Begin Included Message -----