Subject: Re: various questions about Generic QoS Socket Interface

From: [email-masked] (Mark Garrett)
Date: Wed, 17 Aug 1994 15:02:03 -0400

Zheng,

Yes, I agree that with a token-bucket constrained traffic source
you can guarantee transport, dimension both bandwidth and buffer
allocation, and know delay bounds when using WFQ. That is all
very good.

Now, the problem is to look at the set of applications that are
improved by having statistical multiplexing, and try to do
something appropriate for them.  I will contend that the token-bucket
approach is essentially a definition of peak-allocation, and no
significant statistical multiplexing gain is obtained.

You state: ``...the WFQ algorithm which requires close-to-average
bandwidth....''  Now, I believe this is incorrect, but it is
consistent with what a lot of people in the community say and
belive.  So we need to clarify this point (unless we can simply
show that I'm misinterpreting something.)  Can you tell me what
you mean by average?  If I have a stream of traffic that conforms
to a token bucket (R,B), then I know I can allocate bandwidth R
to serve that stream.  However, I don't think that R is anything
but an upper bound on the average.  Do you disagree?

Yes, if you have different types of sources mixed, then the problem
is to find R(N) and B(N) for the mix.  If you had a dominant coder
like some version of MPEG, then we could clearly do it for that.
Much of the traffic is more general, and it would be nice to have
effective stat mux allocation rules for it too.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 2Q-265			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
-------------------------------------------------------------------------------

---

From: Zheng Wang <[email-masked]>
Date: Thu, 18 Aug 94 12:37:35 +0100

> you mean by average?  If I have a stream of traffic that conforms

By average I mean AV(t)=A(0, t)/t, where A(0, t) is the total number of bits 
that entered into the network during (0, t). 

> but an upper bound on the average.  Do you disagree?

Yes, I disagree. R is not the upper bound of the average (as defined above).
Just imagine that a traffic goes "greedy" (i.e. a bursts of back-to-back
packets) at t=0. In this case, the upper bound is the speed of the burst
which is only constrained by the outgoing interface/link. But as long as
the burst size is smaller than B, it has no effects on R.
AV(t) can move above or below R. This is why I said "close-to-average".
Informally, we can say that R is the rate after smoothing B size bursts.

> effective stat mux allocation rules for it too.
 
This is exactly what I am worried about. Even if you have a very small 
types of typical sources, mixing them can produce a lot more types.
Note that we are only taling about the traffic sources. When the traffic
passes a router, the characteristics (R(N) and B(N)) may change so you
need to this at each hop.

I have no problems with the concept of "traffic-classes" approach and
more stat multiplexing.  I just think it is hard to support it in the network.

Zheng