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

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

Bert,

At 11:02 AM 12/12/00 -0500, Manfredi, Albert E wrote:
>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 you mean that a 1000 port device should be specified as being only 
able to support EF traffic on a small number of its interfaces?
I would agree that if you want the jitter bound of one packet time at the 
rate that VW draft wants, you may need to impose such drastic constraints.
But in that case, you are also limiting any EF traffic that does not need 
such stringent requirements. For example VoIP does not seem to need that - 
there are jitter buffers that you can use to absorb a much larger 
device.  So either you would have to say that your S is large, or you have 
to say "if up to i interfaces support EF with max input rate of R_j, then 
S=S(i, j),  And that seems to become rather a difficult task to specify all 
possible reasonable combinations when interface speeds are different, and 
the number of ports are large.

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

It seems to me that this would require going from the input-rate based 
definition to an output rate based definition. I agree that that would be 
the correct thing to do.

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

I do not agree that the above is the worst case, if R is the max rate of 
the total input EF traffic a some interface, as the current definition says.
It would indeed be so if R were the configured rate of the output.  We have 
suggested it several times to the efresolve team, but they always insisted 
that the input rate R is the correct approach, and the one they actually meant.

>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 think I addressed this at the beginning.  What you are saying seems to 
imply that either you give huge S numbers and do not specify
restrictions, or you need to figure out how to specify the restrictions in 
a meaningful way. If you tell me that you have a 1000 port device with S=1 
in Ef traffic is coming from
a single input only (or some small number of ports), that would be a true 
statement, but I am not sure it would be useful for me to understand 
whether I can use that device to support a less restrictive environment.

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

I think that there is a very large range of Ef traffic, such as VoIP, that 
would be perfectly supportable
in a large device. I am not sure we can say that EF is ONLY traffic that 
needs a strict worst case guarantee that jitter dos not exceed
a small number of packet intervals.  If that is what is indeed what you are 
saying, I think that should be very carefully considered by the WG.

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

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.

Anna

>Bert

---------------------------------------
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: John Schnizlein <[email-masked]>
Date: Tue, 12 Dec 2000 15:54:14 -0500

At 11:52 AM 12/12/2000 -0500, Anna Charny wrote:
>... If we say that all EF traffic MUST get a deterministic worst 

The basic idea of EF is that delay at a hop is bounded.
Other PHBs might be defined that have attractive properties for
voice.

The observation that a larger number of inputs for EF leads to
a larger S is accurate. Since S is not intended as a comparison
measure between devices with different numbers of inputs or
different burst capabilities, this is not a problem.

It should also be noted that devices with on the order of 1000
inputs ususally have smaller rates on those inputs than on the
(trunk) output.

The WG need not say how onerously small the EF rates are for 
a device, the conformance claim just states what S for what
rate and burst capacity the device supports. 

John

---

From: Anna Charny <[email-masked]>
Date: Tue, 12 Dec 2000 16:44:44 -0500

>different burst capabilities, this is not a problem.

I heard Joel say on the list that S is a comparative measure at some point.
Has this changed? Is there any consensus on this within EFRESOLVE now?

>inputs ususally have smaller rates on those inputs than on the

But there is hardly a requirement that no EF traffic can go between lo 
speed interfaces, is there?  There is also no requirement that such a box 
cannot be used as a high speed interconnect of identical links.

>rate and burst capacity the device supports.

The WG may not need to say in the PHB definition how much EF traffic can be 
supported, but it most certainly should be aware of the consequences of 
what a particular definition has.  The fact that you can support only a 
tiny fraction of your capacity dedicated to EF to get a small S in a large 
device seems to be one of those consequences that need to be spelled out.

Also,  if having a small or large S does not tell you anything useful, then 
I am not sure what you can usefully say about such a device.  Sure, I can 
do conformance testing on it, but why would I care if S tells me 
nothing?  I would assume one would only want to test conformance of 
something that actually is important?

Anna

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 12 Dec 2000 14:35:29 -0800

> At 03:54 PM 12/12/00 -0500, John Schnizlein wrote:
	[..]
> Has this changed? Is there any consensus on this within EFRESOLVE now?

Nothing has changed, and John's complete sentence is consistent
with Joel's observation. 'S' can be a comparative measure within a
specified context - a context that includes the number of inputs
under discussion.

cheers,
gja

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Dec 2000 17:31:31 -0500

What I said is that for a given topology, S can be used to compare 
devices.  Even then, depending upon the usage one is making, it may be 
sufficient that S is less than some limit, or it may be that lower S is better.
The fact that this depends upon usage is why I have trouble with the 
argument about whether S is or is not a figure of merit.

Yours,
Joel M. Halpern