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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, Juha Heinanen writes:
>    As I understand it, no assumption is made about how the traffic is
>    actually treated.  RSVP simply communicates traffic characterizations
>    and requirements.  What implementation do with that will vary.  Best
>    effort usually carries no reservation, as it is the default.  What the
>    router does to accomodate best effort traffic is outside of the scope
>    of int-serv or rsvp.  Of course some treatments will provide better
>    service than others in terms of fairness, goodput, delay, etc.
> 
>    Perhaps you mean elastic traffic rather than best effort?
> 
> yes, i forgot that "elastic" was the closest rsvp term to "best effort".

Elastic means something very different than best effort.  The
commonality is that elastic traffic without any minimum rate
requirement can survive all but the very worst "best effort" service.

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.

> -- juha

Curtis

ps- we really should move further discussion to int-serv.  I just
wanted to clarify this, so others would not assume this
misunderstanding of elastic applications and best effort service was
fact.