Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt

From: Juha Heinanen <[email-masked]>
Date: Thu, 26 Oct 1995 21:12:09 +0200

Elastic simply means that the traffic can adapt over a very broad
   range of avilable bandwidth and take advantage of a large amount of
   available bandwidth or survive a much smaller amount.

   > so you say that rsvp doesn't have any notion of fairness built in the
   > service model.  if that is so, then it would make sense for the a to be
   > able to specify that he wants his elastic application to use a direct
   > abr vc instead of a path through rsvp routers, since he is sure that the
   > former provides isolation, but has no idea what might happen in the
   > latter case, where one udp video stream could screw up everything he
   > tried to do.  i consider this a big minus in the rsvp service model.
   > may be something can be done to fix it?

   A elastic application can specify a need for a specific minimum
   bandwidth.  Whether that minimum is insure by ABR or other means in
   part of the network is not the application's decision.  This is
   already part of rsvp/int-serv, though I don't know if a Tspec/Rspec
   has been defined or if ISI (or others) has implemented a Tspec/Rspec
   for this type of traffic.

   So this at least doesn't need fixing.

curtis,

being able to specify a minimum bandwidth has nothing to do with
isolation of flows.  a user may not want to pay for a particular minimum
rate, but wants to be sure that he gets his fair share of the bandwidth
available for elastic applications on a given path.  this is possible
with atm abr service.  it has to be possible also with the elastic
service provided by rsvp.  otherwise elastic service has very little
value.  people want to use elastic services for mbone like applications,
but don't want someone in italy messing up nasa space shuttle broadcast
in california like is happening weekly today.

so i strongly suggest that you add the concept of flow isolation within
the elastic service category in to the rsvp service model.

-- juha

---

From: [email-masked] (John Krawczyk)
Date: Thu, 26 Oct 95 17:40:35 EDT

On Thu, 26 October, Juha Heinanen ([email-masked]) wrote:

   curtis,

   
   -- juha

Hi Juha,

As a lurker on the rolc list, I've been following this thread (I'd
like to thank Curtis for making it unnecessary for me to jump in -
he's pretty much said anything I would have added!).  Now that we're
in int-serv land....

First, RSVP currently does not get involved in elastic traffic;
there's no admission component, so RSVP isn't needed.

In RFC 1633 (the somewhat aged but still useful Integrated Services
Architecture document), the discussion of elastic traffic discusses
administrative link sharing, but flow isolation (e.g. via fair
queueing) isn't mentioned (or I missed it).  I think this is what you
are looking for, right?

Int-servers: Does it make sense to add this to the discussion of
elastic traffic if/when RFC 1633 gets updated (I remember some mention
of a re-write quite a while ago...)?

(While flow isolation would help, your chances of watching the shuttle
broadcast uninterrupted are better if you actually pick a better
service class via RSVP.)

-jj