Subject: Re: [Diffserv] EF RFC and loss

From: Constantinos <[email-masked]>
Date: Fri, 5 Nov 1999 20:02:15 -0600 (CST)

Hmm.. so what I had in mind is regulation at any multiplexing
and demultiplexing point (both output and input interfaces),
so that the burstiness of the EF aggregate never increases to more
than one packet per 1/R seconds, where R is the capacity of the
EF aggregate at that point. 

In this model, the regulator in the multiplexer of an output interface
would only require a buffer of N packets, where N is the number of
inputs to the multiplexer.

In the case of demultiplexing at an input interface, though,
Ion's last note convinced me that the number of required buffers
is indeed proportional to the number of (macro)flows present
in the EF aggregate of that interface. I refer to the following
part of his email:

> To see this, assume a router that receives at input i aggregate EF
> traffic at a rate R, and assume that this consists of n flows of rate
> r, i.e., R = n*r. Then assume that n/K of these flows go to the
> output j. As a result the traffic from input i to output j will be
> regulated to R/K. Now assume that all packets of these n/K flows are
> received back-to-back, i.e., it will take
> 
>                     t = (n / K)/ R = n / (K*R)
> 
> to receive these packets. In contrast, since the rate between input i
> and output j is limited to R/K, during the same time input i can
> transfer to output j only
> 
>                      m = (R/K)*t = n/K^2
> 
> packets. Thus, at the end of this interval the input i has to store
> 
>                      n/K - m = n/K (1 - 1/K)
> 
> packets for output j. It is easy to see that this value is maximized
> for K=2. Thus even if you regulate the traffic at the inputs you still
> need a buffer of size proportional to the number of flows. And recall
> that this is only for one output; the input has to eventually maintain
> a buffer for each output port.
> 

So, in the worst demultiplexing case (K=2), the input regulator needs n/4 
packet buffers, where n is the number of macroflows in the EF aggregate.
Which can be also thought of as a bound on how much aggregation of EF 
traffic is feasible at each link.

Interesting stuff (even at Friday's evening..)

Constantinos

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Siamack Ayandeh <[email-masked]>
Date: Wed, 10 Nov 1999 17:20:27 -0500

I think this thread is not complete without the following  point:

What is the likelihood of the worst case scenario actually occurring. Using
your notation let z = (N-1)^s.  Then if the link share of the EF aggregate in
an
interior hop s, is given by "a" (which say is 0.1 or so) then the probability

of the worst case traffic scenario, assuming independent sources, is (a/z)^z.

So the probability drops off much faster than the buffer requirement!

If sources are not independent then you probably have a security issue
on your hands.

Regards, Siamack