Subject: better-effort services and billing

From: Jon Crowcroft <[email-masked]>
Date: Sun, 15 Jan 95 11:22:38 +0000

if we believe in the requirement for resource
reservation for better effort services than traditional internet best
effort, then we presumably believe in charging for those services.

i was thinking about this a bit - the providers want to maximise
profit, while the subscribers want to minimise cost for acceptable
service....

however, an interesting 2nd order question is : the net is growing -
while there are ever more subscribers to bring online, and there is
increasing bandwidth, is the operating point necessarily the same as
in the steady state that the phone net has reached? i.e. do you really
need to charge for usage...... a sort of scott shenker type of
question, if i'd phrased it better...

maybe this isn't quite the right list, so here is something that is
unashamedly appropriate for this list:

how many rotuers implement IP TOS right now? 

if its more than a few, i'd like to try a simple experiemnt - have vat
and vic mark their TOS bits exactly as telnet and ftp respectively -
i.e. vat audio gets to look like low delay, and vic video ghets to
look like hi-thruput, but hi-delay

see how much better the audio does......and write a paper for CCR
about it....

cheers
jon

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 15 Jan 1995 03:39:08 -0800

>> look like hi-thruput, but hi-delay

    And do basic WFQ in the network based on those settings. I bet things
    would sound rather clear.

Dino

---

From: Allison Mankin <[email-masked]>
Date: Sun, 15 Jan 95 14:01:39 PST

> And do basic WFQ in the network.  I bet those things
> would sound rather clear

Dino,

Can we do a basic WFQ with many of the routers in the 
Internet?  This has always sounded like a good idea,
but not an attainable one.

Allison

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 15 Jan 1995 21:24:23 -0800

>> but not an attainable one.

    Not now we can't. But it will be available relatively soon. Right now
    we support semi-fair queuing :-).

Dino

---

From: Christian Huitema <[email-masked]>
Date: Mon, 16 Jan 1995 14:53:27 +0100

Dino,

In fact, we already have some experience with FQ here at INRIA. Tested FQ on
small test network, looked at how IVS, FTP and others competed, etc.
Basically, the results are that audio is terrible when it compete FCFS with
FTP, but becomes very good the moment we turn on FQ - even if we don't do
reservation.

The reason is "isolation". By doing FQ, we isolate the various flows. They
will indeed compete with each other, but you do away with the very large delay
variations that batch of packets can induce in an FCFS switch (e.g. after ack
compression). Indeed, we do not reserve bandwidth - but IVS is adaptive. FQ
has the effect of smoothing per flow's bandwidth variation, thus making
adaptation work much better.

I already had several discussions with Van on the subject, so feel
compelled to say that what is good is not so much FQ per se as its smoothing
effect. If the same smoothing effect can be obtained with other techniques,
e.g. RED, so much the better. We have not yet implemented RED for a
comparison, but I trust Van enough to believe he is probably right.

The good point of all this is that we do not need to separate "traffic
classes" and manage TOS. All users get the same share of the net, and use it
for whatever they want. Who are you to tell me that your audio should have
priority over my ftp? Indeed, this only work if there is, in average, more
than enough bandwidth per user.

The other good point is that we get a very simple architecture. We could still
implement provisions for contract, classes, etc. But then, a CBQ like solution
is enough.

Christian Huitema

---

From: Ibrahim <[email-masked]>
Date: Mon, 16 Jan 1995 10:30:58 -0500

> Christian Huitema

I have done some simulations and analysis on providing classes
of best-effort service.
Indeed, "isolation" of the traffic classes can significantly
improve performance.

In particular, I have found that if a class-based round-robin
discipline (rather than FIFO) is used for link scheduling
and this structure is exploited to calculate link costs,
then end-to-end delays can be significantly lower as
the routes of the traffic classes get isolated, i.e.
delay-sensitive traffic taking low delay routes
and throughput-sensitive traffic taking under-utilized routes
(Details are in ftp.cs.umd.edu:pub/MaRS/RoutingScheduling-2-TR93.ps.gz).

Best regards,
Ibrahim Matta

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 16 Jan 1995 13:26:15 -0500

Dino,

I couldn't fully parse that.  Maybe my parser is broken.

WFQ implies queueing things separately and setting weights.  Do you
mean some trivial approach like setting different weights for
different TOS and having one queue per TOS (presumably with manually
set weights) or do you mean something else.

Using WFQ where RSVP gives you your own queue and a weight seems to
make sense to me, but I'm not sure if that is what you meant from the
very terse statement you have here (and it doesn't have anything to do
with TOS).

I take it you are suggesting that the absolutely trivial approach
would probably do the trick, but are not advocating it.

Curtis

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 17 Jan 95 08:41:18 +0000

>set weights) or do you mean something else.
 
or you could read our paper on other sorts of interesting queuing thats
being given at usenix this week....

(or ftp://cs.ucl.ac.uk/darpa/usenix-cbq.ps)

 jon

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Jan 1995 22:42:12 -0800

>> set weights) or do you mean something else.

    Of course weights could all be assigned to 1 not biasing any one queue.
    Yes, if we could assign a TOS value to vat, we could give precedent
    to it over telnet and FTP for example.

>> very terse statement you have here (and it doesn't have anything to do

    Yes, I proposed both internally and externally to cisco to configure
    the queuing initially and later they will be dynamically configured using
    RSVP.

>> would probably do the trick, but are not advocating it.

    A trivial approach so we can learn more. If we believe it is adequate
    we lower our ambitions. If not, we continue more research.

Dino