Subject: repost from rolc regarding rsvp/atm discussion

From: Juha Heinanen <[email-masked]>
Date: Thu, 26 Oct 1995 18:47:56 +0200

In message <[email-masked]>, Juha Heinanen writes:
   
   > curtis,
   > 
   > is the fairness assumption built in into int-serv/rsvp, i.e., are the
   > routers required to isolate flows of "best effort" category from each
   > other?  also, is it possible in int-serv/rsvp to specify a weight for a
   > best effort flow relative to other flows sharing the same path?
   > 
   > -- juha
   
   Juha,
   
   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?
   
   Curtis

yes, i forgot that "elastic" was the closest rsvp term to "best effort".

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?

-- juha

---

From: Craig Partridge <[email-masked]>
Date: Thu, 26 Oct 95 11:05:38 -0700

> best effort flow relative to other flows sharing the same path?

Juha:

The model is that best effort flows are just that -- best effort.  So they
can be squeezed by other best effort traffic, according to whatever the
rules for best effort service is (and the current standard, which we aren't
proposing to change, is you get whatever you get).

If you want better service, you ask for a service class other than best
effort.

Craig

---

From: Craig Partridge <[email-masked]>
Date: Thu, 26 Oct 95 12:40:58 -0700

thanks for the explanation, but it doesn't make ANY sense to me.  why
    would a user care if there exists a router from which the services are
    asked from?  the application should ask a particular service from the
    network, not from a router.

Juha:

    Sorry my explanation doesn't make sense -- let me try again.  (And I'll
cross post to ROLC on the grounds that others may also be confused by what
I said).

    Strictly speaking, I shouldn't have said "routers" but "service elements"
which one can think of as anything which accepts IP datagrams on one sides
and spits them out the other side.  So one can think of a MAC layer network
with two hosts attached as a service element, as one host puts IP datagrams
in and the other takes it out.  In short, the INT SERV stuff works just
fine over a single network without any routers.

    Pushing ahead, you point out the application asks for a service from
the network.  From my perspective that's not quite right -- the application
asks *something in the host* (a software library, the OS, whatever --
via what you'd call the API) for a service and that something asks the
*internet layer* which in turn works with the MAC layer.

    The reason I like this model is that there's a lot of complexity in this
process.  For instance, as you know, the same video stream could be described
by hundreds or thousands of different token buckets.  Which description you
choose is likely to depend on local policy and tarriffing issues.  And you
don't want to have to embed tarriff tables in every application.  So something
between (which may just be a library call or a call to the OS) makes
the problem a lot easier.  It also gives you a level of indirection to cope
with things like combining flows.

    And yes, this is all independent of RSVP, ATM, etc.

Craig

---

From: David Clark <[email-masked]>
Date: Thu, 26 Oct 95 16:02:37 -0400

Actually, I disagree. As I discussed in the paper I gave at TPRC recently,I
believe that the Internet can (and will) grow to have the concept that one
person's best effort is better than another.  I think we can build mechanism to
do this.

Dave

---

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

craig,

i'm greatly relieved that you don't assume a router + rsvp to deliver
the service.  i guess i need to read the draft in order to figure out if
it can deliver good mileage in case the wire is atm.

-- juha

---

From: [email-masked]
Date: Thu, 26 Oct 1995 14:24:00 -0700

Dave, is this paper available online?

Daniel Zappala
[email-masked]

>>>>> David Clark <[email-masked]> writes:

---

From: David Clark <[email-masked]>
Date: Wed, 01 Nov 95 11:14:22 -0500

The paper I wrote on service discrimination is online: look at 

http://ana-www.lcs.mit.edu/anaweb/ps-papers/TPRC2-0.ps

For a list of group papers, in both ps and PDF format, look at

http://ana-www.lcs.mit.edu/anaweb/papers.html

(for those of you who might like the paper as PDF...)

Dave