Subject: Re: guaranteed service vs CBR

From: Scott Shenker <[email-masked]>
Date: Fri, 14 Jul 1995 16:58:26 PDT

I should have been clearer.

Obviously letting in bursts cannot improve the utilization of the
network if ALL users are using guaranteed service.  However, if some
users are using predictive service, then allowing guaranteed traffic to
send in bursts and having these bursts use some of the otherwise idle
time on the links CAN improve network utilization by lowering the
delays for predictive traffic.

---

From: [email-masked] (John Krawczyk)
Date: Mon, 17 Jul 95 08:01:09 EDT

[email-masked]:

   Assumptions:

   1) Each user has leaky bucket parameters (b_i,r_i), and a hard 
   network delay requirement D_i.

   2) Each network element provides a share of bandwidth  
   r_i to user i (i.e. user i is entitled to this much whenever he 
   wants it.)

   3) We want to guarantee zero loss (due to violation of delay
   bound) to each user, even in the worst-case.

Not exactly.  Scott partially answered this:

   [email-masked]:

           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   
And don't forget the best-effort traffic!!!  This is supposed to be
"Integrated Services", right?  The reserved flows (of whatever
service) have to co-exist with the best-effort traffic too, and any
assumptions need to include scenarios where the amount of reserved
traffic ranges from a small to a large percentage of a particular link
(but never all).  The best-effort traffic consuming the remaining
bandwidth may be light to heavy and of varying burstiness, and you
have little to no clue what it will look like at any time.  Any
analysis needs to examine the effects of and on the best-effort
traffic!

In the particular case of whether or not passing a burst of reserved
traffic is good for link utilization, I can think of two cases.  In
either case, there is one reserved flow and one best-effort flow:

1) Both flows burst at separate times, and each burst requires a
majority of the bandwidth.  Suppose the reserved burst happens first,
and if we smoothed out the burst, we would still be transmitting the
data when the best-effort burst comes through.  If the combination of
this data and the best-effort data congests the link, we have to drop
packets from the best-effort flow.  If we instead pass the reserved
burst through the network (given that we have the bandwidth at the
time), we have a better chance of not dropping packets from the
best-effort flow when it bursts.

2) Both flows burst at the same time.  In this case, smoothing the
reserved flow means that we'll drop less packets from the best-effort
flow than if we serviced the reserved burst immediately (and if I
understand WFQ w/ the CSZ scheduler correctly, we would smooth the
reserved flow, no?).

-jj

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 17 Jul 95 15:00:26 +0100

>"Integrated Services", right?  

indeed....

on the question of under or overspecified source behaviour (flow
spec) - given we have IP ratehr than pinned virtual circuits a la ATM,
we cannot know a lot about the hop by hop (e.g. we don't know how a
delay budget is subdivided amongst hops....on a multi-provider path,
we do not know what mix of different services different providers
policies will permit...) so the problem is that
since we can see less of the internal implementation of the QoS
provision, we have to say more than we would if the net revealed more
of its topology and traffic patterns as a VC type net would...

jon

---

From: Steve Jackowski <[email-masked]>
Date: Fri, 14 Jul 1995 10:45:38 -0900 (PDT)

Jon,

> of its topology and traffic patterns as a VC type net would...

Maybe we should consider a vc-type service ;)

Sorry...

Steve