Subject: RE: [Diffserv] Possible compromise between EFRESOLVE anddraft-ch arny

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Tue, 12 Dec 2000 15:08:54 -0000

> ----------
> From: 	Anna Charny[SMTP:[email-masked]]
> 
> >...
> > > I think Bill may have answered this question, but let me give my
> > > answer.  Consider an ideal output buffered device with 1000 ports, all
> > > links being the same speed. Suppose that 1/5000 of traffic from each
> input
> > > goes to each output (that is, all links in the router is exactly 50%
> booked
> > > with EF traffic).  Suppose every output implements a strict priority
> > > queue.  An ideal output buffered device with a PQ at each output seems
> to
> > > me as close to an ideal device as we can get for EF support.  Suppose
> now a
> > > single packet destined for the same output j arrives at the same time
> to
> > > each one of 1000 inputs.  Would you agree that S has to be at least
> > > 999?  Now, let's go one step further and assume that we actually allow
> B
> > > back-to-back packet burst at each input.  Do you agree that S must be
> at
> > > least 999 times B?
> >
> 
> S is the measure (in number of packet times)
> of the bound on delay variation. The packet time is computed
> using the expected rate at the input interface.
> 
> Now, let's suppose we have M input interfaces,
> and that we accept a burst B MTU sized packets from each.
> 
> Let's suppose the accepted EF input rate is R and that the
> output interface is a link served at a rate R(out) at least such that
> MTU/R = MTU*M*B/R(out). 
In this case S=1. You can scale the output rate to obtain any value
of S that satisfies the service goals. The EFresolve does not
enter the business of defining this output rate.
This is implicit, left to the engineers
to figure out, depending on the instance of router they
are dealing with. The same holds for any other router specific knob
that can be used to obtain the S goal.

alessio

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 12 Dec 2000 11:02:49 -0500

Anna Charny wrote:

> I think it is perfectly fine for a scheduler or a device to cope with 
> simultaneous arrivals, and you are most certainly right that 
> every device 
> must deal with it. And in fact every reasonable device does.

To a point. In your example, Anna, you are assuming that the EF device must
accept simultaneously EF traffic from any of the interfaces and spit this
out any one or more output interfaces. But there's no reason to assume such
unconstrained behavior, is there?

I think it's easier to think of R as the aggregate incoming EF traffic rate
at that EF device, and to specify S for cases in which the capacity of each
egress is at least as high as the EF traffic directed to it.

In the worst case, all incoming R goes out a single interface. If you design
the box for this worst case and for non-blocking behavior at all times,
_then_ you would have to specify that ingress EF traffic on any interface
must be <= R/n, where n is the number of interfaces.

But there is no reason to mandate such behavior, is there? EF traffic might
only exist at a small number of interfaces at any given time. And there will
be times when people try to send too much EF traffic through, and the box
must somehow indicate that it is overbooked. 

> I gave an example of an ideal (large) output buffered device 
> with PQ at the 
> output, which gave a large value of S. Since I doubt that it 
> is reasonable 
> to say that large ideal output-buffered routers with a PQ at 
> the output are 
> bad for EF, I belive my example indicates that is is NOT true 
> that devices 
> with large S "are simply not ideal for EF use".

On the other hand, large S might not lead to acceptable EF behavior. I'm
simply suggesting that the uncontrained, non-blocking scenario you
postulated, when it leads to large values of S, results in large
queue-related latency, which this sort of traffic might not be able to
accept.

CBR traffic is hard to handle. It's always been the case. I'm suggesting
that the D(j) - E(j) <= a certain number of packets in queue definition of
EFRESOLVE is valid for actual _traffic_ requirements in the real world. I
don't think this behavior can necessarily be provided by a never-busy sort
of device, unless you put onerous constraints on incoming EF traffic.

Bert

---

From: Anna Charny <[email-masked]>
Date: Tue, 12 Dec 2000 11:15:04 -0500

>of S that satisfies the service goals.

 From the piece of text you have taken out from the example (which I think 
may be Dimitri's?) I cannot tell whether what you are saying is correct or 
not. But your message above does not seem to make sense to me in general. I 
want to remind you the context of the example I  gave to show large S for 
which no reasonable scaling would help. You have am ideal output buffered 
router with no internal delay,  N identical speed C interfaces, and a PQ at 
each interface. You have  C/2 -worth of total EF traffic going from each 
input interfaces to all other outputs, which means that the configured 
input rate is R=C/2. From the total EF traffic at every input only 
C/2N  goes to each individual output.    Therefore, each output has R=C/2 
EF traffic as well.  Consider any single output.  It can experience a 
simultaneous arrival of N packets of MTU size, one from each input 
interface (even for the case wen there is no input burstiness at all). This 
means that there could be an instantaneous queue of N packets, which can be 
drained at most at the speed of the interface C=2R.  Therefore, a delay 
experienced by the last packet in this queue will be N*MTU/2R. That means 
in this case D=N*MTU/2R for this packet.  In the absence of competing 
traffic this packet would have left at time E=MTU/C=MTU/2R. This means that 
D-E = (N-1)/2 * MTU/R.

So for a N=1000 port device S must be at least 999/2=499.5 for ideally 
shaped inputs.  If you allow a burst B at each input, you would need to 
have S=499.5*B, and
NOT S=1.

Anna
>  The EFresolve does not

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 12 Dec 2000 13:02:47 -0500

Anna Charny wrote:

> Again, I have to repeat that this is a serious statement that 
> I think you 
> are making. If we say that all EF traffic MUST get a 
> deterministic worst 
> case jitter guarantee of a small number of packet intervals 
> at its rate, we 
> need to make sure that 1) it is actually possible to achieve 
> end-to-end 
> (which we do not know at the moment), and b) that the working 
> group accepts 
> that you can only support an onerously small amount of  EF 
> VoIP traffic in 
> large devices.

Indeed, Anna.

Onerously small _only_ if the EF device must be available at all times, for
simultaneous EF traffic from any and all of its interfaces. But such
availability would be astonishing from any CBR net, so it should be equally
astonishing from an EF net.

Yes, I think what you summarize above is quite correct for EF. That is what
makes EF different from AF, in my view anyway. Is this not a consensus view?

Bert

---

From: Anna Charny <[email-masked]>
Date: Tue, 12 Dec 2000 14:38:27 -0500

Bert,

> > that you can only support an onerously small amount of  EF

I just want to make sure that you agree with what I think you have just 
agreed on.  I think you have just agreed that in the context of efresolve 
definition which requires a theoretical *worst case* jitter  bound you are 
forced to limit the amount of Ef traffic to an onerously small number (in 
my example 0.1% of the available capacity for a 1000 port device) if you 
want the jitter bound to be small. I think we are in agreement then.

>astonishing from an EF net.

The above statement is clearly of statistical nature. If you are talking 
about statistical behavior, I would immediately agree with you - it is not 
very likely that Ef traffic is completely synchronized all the time.  This 
is, however, irrelevant in the context of the current EF approach that has 
chosen to concentrate on the worst case behavior, and wants to provide hard 
deterministic delay bounds. For that goal you have to consider the rare 
occasions of syncronisation, and so you comment above seems a moot point.

If the working group decides that it is not the worst case guarantees that 
it is after, but statistical, then a) we need to make sure there is 
concensus for such a change; b) I would claim that it is difficulat to 
estimate the statistical probability of bad things happening withing the 
framework of efreesolve in particular, and not easy in principle.  The 
current work on this subject has been in the context of a rate-based model, 
and in my view the work of Jim Roberts is one of the most interesting inb 
this respect.

>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 13 Dec 2000 15:59:13 -0000

> shaped inputs.  If you allow a burst B at each input, you would need to 
In fact my answer was not related to this example, but just stating once
again
the fact that S can be any values that make S*MTU/R OK according to the
service
goals. if no satisfactory S*MTU/R can be found for a GIven R according to
a router config, one should go back to the drawing board and
change the acceptable R, or the configuration. I'm not comfortable with
the assertion big S = Bad thing. Again, if instead of S*MTU/R
we would have written Tmax or E, probably we would have saved much
folder / archive space, and time.

regards

alessio