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

From: Anna Charny <[email-masked]>
Date: Mon, 11 Dec 2000 18:01:40 -0500

Bert,

At 05:53 PM 12/10/00 -0500, Manfredi, Albert E wrote:
>Anna Charny wrote:
>
> > Alessio Casati wrote:
>
> > > > - non-FIFO treatment of EF will typically lead to a large
> > value of S
> > > >
> > >It appears this concern was addressed on the list and
> > >multiple voices supported that this point was not valid.
> > >As such we don't need to discuss about this further.
> >
> > Do you mean to say that it is not true that devices with
> > non-FIFO treatment
> > will have large S, or that it is not important that they have large S?
> >
> > I would also like to point out that  there were also multiple
> > voices on the
> > list that supported the opinion that this point was valid, so
> > I suggest
> > that we need to address this question
> > with a more technical discussion.
>
>I'm afraid I don't understand the controversy regarding S.
>
>EFRESOLVE states that EF is defined as an aggregate flow for which the
>difference between minimum possible delay and the maximum possible delay is
>bounded by some number S X MTU transfer time when the arrival rate of this
>incoming EF aggregate flow is specified as R.
>
>The underlying idea of EF, whether we can state this or no, has always been
>(has it not?) to support a service similar to CBR, or approaching CBR, for
>an aggregate flow. So S will determine how CBR-like this EF flow will be.
>
>If some non-FIFO schedulers will result in large values of S, seems to me
>that those schedulers are simply not ideal for EF use. Why is this an issue?

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?

Does this example answer your question?

> > We are concerned, however, that the
> > decision of the
> > team to use the  input rate only makes it difficult to generalize the
> > definition to a device with a range of interface speeds in a
> > way meaningful
> > in the diffserv environment. While it is possible that we
> > misunderstand how
> > you plan to address this issue, we have not been able to get any
> > clarification of this (and in fact at least two members of
> > your team have
> > acknowledged that such generalization is not obvious).
> >
> > It may help if you can give the answer to the following questions.
> > Can you please let us know what is the maximum input rate R
> > that a device
> > can support in the case of multiple speeds of  interfaces,
> > when the device
> > is just characterized by a single value of R  (your draft
> > says that this is
> > the speed of the slowest interface - do you believe it is
> > correct?).
>
>Wouldn't the total EF arrival rate at the box be R? And if so, if the speed
>of the slowest egress >= R, then haven't we guaranteed that the delay
>variation will remain bounded?

I think you are quite right.  Note however, that your statement above does 
not say anything about the max rate *at each input*, rather it says that 
the sum of R at all inputs must be at most the *output* capacity.

The efresolve draft says that a device must advertise a value of R such 
that as long as the *input rate* on any interface does not exceed R, the 
device must guarantee a particular jitter bound. That seems to me to imply 
that in a device with n inputs, the input rate R cannot exceed 1/n of the 
output interface speed. This is because all you know is a constraint on the 
total amount of EF traffic at a given input, but you do not actually know 
where it goes. In particular, all of it may happen to go to the same 
output, and the efresolve says you must provide bounded jitter in that case.

Suppose you have a router with 1000 identical speed interfaces.  If you are 
specifying this router by a single value of *input rate* R, then you seem 
to be limited by R <= smallest output interface speed/1000 for *all EF 
traffic on a given input*. This seems like an unacceptably small number - 
it would be bad if all we could do was to support 0.1% of total EF traffic 
at each interface.

Now, maybe it might be possible to solve this problem by specifying 
different combinations of R's and S's for different traffic matrices.  But 
I frankly do not understand how that can be done in the standard hose model 
diffserv environment (true, for the pipe model, where you have information 
about how much traffic goes from each input to each output, it is possible 
top give such a matrix; but for the hose model you only know how much EF 
traffic there is going from a given input to all outputs together).  This 
is what I meant when I asked Alessio to explain how you can specify the 
constraints in the multi-input multi-output case with different interface 
speeds.

Regards,
Anna

>Bert
>
>_______________________________________________
>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

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

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Dec 2000 18:29:28 -0600

Anna Charny wrote:
...
> back-to-back packet burst at each input.  Do you agree that S must be at

Isn't it the case that this (the fact that the queue will instantaneously
contain at least 999 or 999B packets) is a truism whatever scheduler and 
EF definition is in use? 

  Brian

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 11 Dec 2000 20:50:34 -0800

Anna Charny wrote:
	[..]
> different combinations of R's and S's for different traffic matrices.

Yes (including burst tolerances), that is the intention. 

cheers,
gja

---

From: Anna Charny <[email-masked]>
Date: Tue, 12 Dec 2000 01:28:26 -0500

Brian,

>contain at least 999 or 999B packets) is a truism whatever scheduler and

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.  But the 

>that those schedulers are simply not ideal for EF use. Why is this an issue?

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".

Anna

Anna