Subject: Controlled-Load comments

From: "Tim O'Malley" <[email-masked]>
Date: Tue, 13 Feb 1996 18:49:19 -0500

hola.

[These comments come from discussions with other people.  If they are
salient points, then I give all the credit to them.  Otherwise, assume
all brain-damage is with me.]

1. What happens to a Controlled-Load service when receivers request
   varying TSpecs?

When receivers request a variety of traffic levels, at what rate does
the sender transmit the data?  Assuming that the sender transmits at the
highest specified rate, won't much of the packets arrive out-of-order at
the smaller-Tspec receivers?

Is this poor handling of heterogeneous Tspecs? Am I missing something?

2. Why not export the token bucket values?

Under the current description, a receiver can not determine the size of
his reservation.  If we export the r,b numbers, then RSVP can include
them in an ADSPEC message.

.....................................................................
.                  .   For every problem, there is one              .
.   happy daze     .   solution which is simple, neat and wrong.    .
.        -tim O    .         -- H.L. Mencken (1880-1956)            .
.....................................................................

---

From: John Wroclawski <[email-masked]>
Date: Wed, 14 Feb 1996 17:08:36 -0500

From: "Tim O'Malley" <[email-masked]>

Hi Tim,

For a service like controlled-load, heterogeneous tspecs basically
make sense when you have multiple senders. Consider the usual lame
teleconference example. There are 20 senders. I have a thin pipe into
the net, and besides can't really understand more than 2 people at a
time anyway, so I make a reservation for 2 senders worth of
traffic. If more than two people talk at once, I lose, but I don't
care much. You have a fat pipe, and besides you are archiving the
conversation as well as participating in it, so you make a reservation
for 20 senders worth of traffic so you can be confident of getting
everyone at once.

For other, more complex services, the answer might be different, of
course.

I just know I don't understand what you're really asking about here,
so this is probably the answer to some other question entirely...  But
with C/L (and RSVP), each receiver puts a tspec in their request, and
the requests may merge upstream. If there is only one receiver, and it
does not get an error, then the reservation is the size the receiver
asked for. If there are many reservations merged upstream, then the
-minimum- reservation in place anywhere along the path is still what
the receiver asked for. Only if several different-sized reservations
successfully merge at the first hop will a receiver not have exactly
the reservation it asked for in place at at least one point along the
path (even if there are larger ones elsewhere). 

(there's a little more to this answer, but I'd like to be sure I
understand your question better first..)

		-john