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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 13:02:05 -0500

If all the traffic is EF, then the full output is dedicated to EF, and 
things work easily.

Given the latest request for an example, here is one.  I am sure that 
people will argue that it is a bad example.  So be it.

The assumption in this example is a pipe model of EF usage.  A number of 
interfaces supporting EF traffic are directing that EF traffic to a common 
output.  The implementor must specify, for the burst limit that he is 
willing to support, what the R and S are for each input.  For simplicity, 
all of the inputs will use the same R in this example.

The configuration is 500 input interfaces, each allowing 4 megabits / 
second of EF, and a total burst limit on the output of 32,000 packets.  The 
common output is a 40 gigabit link.  The EF scheduler in use alternates EF 
packets and everything else.

Assume for simplicity that the bursts are arriving at all inputs at once 
(one can easily perform the math for more complex cases, but it does not 
elucidate any more).  Also assume that the input links are 44 megabits, and 
the bursts arrive at wire rate.
The last packet that will be leaving arrives on its interface at time
     64 * MTU / (input-wire)
It leaves the output interface at time
     fixed-delay + 32,000 * MTU / (output-wire)
The earliest time it could have left is obviously its arrival time plus the 
fixed delay.  Therefore, in units of time the maximum time difference is
     32,000 * MTU / (output-wire) - 64 * MTU / (input-wire)
To show that S comes out fairly small even in bad cases, I will overstate 
that S the implementor will calculate by ignoring ths second term. Then,
     S = 32,0000 * (input-rate) / (output-EF)
Plugging back in the 4 megabits / second EF input rate and the 40 gigabits 
/ second output wire rate, and the alternate packet scheduling, we see that
     S = 6.4

So, can we stop saying that we can not calculate S or that all reasonable 
schedulers give large S.

Yours,
Joel M. Halpern

_______________________________________________
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: demir <[email-masked]>
Date: Mon, 11 Dec 2000 11:13:54 -0800 (PST)

I am not sure if anyone has already pointed out. If so, I appologize for
bringing it up again. 

An EF (EFRESOLVE) scheduler can make D(i) - E(i) conformance test only
before it sends a EF packet. If a non-EF packet arrives after a EF packet
where EF packet's conformance has already calculated, but non-EF packet
leaves before the EF packet though it has arrived after (for whatever
reason), then pre-calulated D(i) - E(i) will be wrong. Is that acceptable?

Alper K. Demir

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Mon, 11 Dec 2000 14:38:19 -0500 (EST)

Joel,

A couple of comments:

. You assumed a 64 packet input burst. And that means that 
    packets might get dropped, up-stream burstiness has 
    created some more jitter.... but that is a general 
    problem, so I ignore.

> the bursts arrive at wire rate.

Thus this is an edge router and not a core router. Numbers
are quite different if all links are 40Gbps, and you just

>      S = 32,0000 * (input-rate) / (output-EF)
     I hope you mean ^input-wire^ ..

> / second output wire rate, and the alternate packet scheduling, we see that

No problem ... though, you have an error. The input-wire rate
in your example is 44Mbps and not 4Mbps. None guarantees
that the input burst will arrive with 4Mbps. ... it can
arrive at the full wire rate. Thus, based on my
calculator S = 35.2 (following your equations).

In addition, if input wire= output wire = 40Gbps,
S= 32000 ... can you see the problem now ? 
 (i.e. S becomes equal to your output burst size .. and it doesn't 
   realy matter what scheduler you use .. the quality
   of the scheduler is hidden in the large numbers, that 
   are dominated by the burst sizes)

Dimitri

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 16:00:03 -0500

A) The "input-rate" in the last part of the calculation is the input EF 
rate, not the input wire rate.
B) The Output EF rate must exceed the total input EF rates.  There is 
indeed a case that produces large S if you are trying to run a trunk and 
add traffic from a large number of small interfaces.  If the input EF rate 
were 1 gig, the output were 1.5, and one was adding 400 1 megabit EF 
streams, each of which could burst several packets, one would have a large 
S.  On the other hand, one would also really have a large variation in the 
potential delay.  So a large S is indeed appropriate.
C) The packet size did not actually appear in the formula.  I actually 
assumed that all packets were of size = MTU, which then fell out of the 
equation.  If the packets are smaller, the impact is reduced.
D) It was pointed out to be that the EF output service rate in the example 
was unrealistically high.  If you change the example to a 10 gig output 
link with the same scheduler (5 gig output EF service) the S is 26.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 16:02:49 -0500

The specific decision in crafting this form of definition was that 
conformance testing can only be done in a test environment,  It is 
certainly true that one can not characterize in the operational network the 
E(i) that an actually serviced stream would have received.  However, if the 
device does EF you know what the bounds are anyway. Conformance testing in 
an operational environment while nice is simply not a feature of our 
definition.

Yours,
Joel M. Halpern

At 11:13 AM 12/11/00 -0800, demir wrote:
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Mon, 11 Dec 2000 16:13:31 -0500 (EST)

> rate, not the input wire rate.

I am sorry, but I don't agree with that. The maximum burst 
can arrive with the wire-rate and not the EF rate. Thus,
the larger the input wire rate the faster you receive
the burst, and the higher the burst that will be observed
at the output. (assume that the previous scheduler is a priority one) 

Even if assume the above statemtn is correct, that it is not, you can
always assume that you have de-aggregation. (i.e. you
have 40Mbits of input EF traffic, out of which only 4Mpbs
go to the particular interface ... and thus the input rate
becomes very close to the wire-rate ...).

You can also make the argument that 80% EF is not 
normal .. but then, I will tell you assume 1Gbps
links, and you will get again the same result.

Dimitri

---

From: demir <[email-masked]>
Date: Mon, 11 Dec 2000 13:38:23 -0800 (PST)

Joel,
> an operational environment while nice is simply not a feature of our 

I agree with above "statements". In addition, both E(i) and D(i) has the
same problem. I accept that "conformance testing in an operational
environment" is simply not a feature of your definition. Are we talking
about a "utopian"/"misterious" PHB? It seems to me that EFRESOLVE is
trying some "acrobatic" to tackle all problems related to it (Please no
offence or harm to anyone. This is only what I see). If we assume
"everything" (provided all conditions), we can construct a scale to hold
the "earth" (I recall similiar phrase from physics class, sorry for not
being able to write it down in English as it is said).

Alper K. Demir

---

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

Joel,

Would you agree that S in your example is very much dependent on the 
traffic matrix you chose? For example, suppose that there happens to be no 
traffic going to the high-speed interface, but rather all traffic happens 
for the moment to be going between all low-speed interfaces, of which there 
are 500.  (I am assuming that all interfaces are full-duplex, so for any 
input interface of speed X there is also an output interface of the same 
speed X.
Suppose there is only 0.004 megabits of traffic on each of these inputs, 
but all this traffic happens to go to the same 4 megabit output 
interface.  Do you agree that for that traffic matrix in the same device, 
you would have to have S at least equal to 499, because one packet destined 
to the same output interface can arrive at the same time for a given 
output, (and this does not even include the allowed input burstiness that 
would need to be used as an additional multiplier). So if you are 
specifying your device by a single triple (R, S, max input burstiness), 
which is what efresolve draft says is the default specification, then you 
will be forced in this case to declare a much greater S that your example 
suggests.  Do you disagree with that?

You may say that you can specify a S for each combination of possible 
traffic matrices.  Although cumbersome,  it may indeed be possible to do 
for the pipe model. But what about the hose model?  How do you specify 
these multiple sets of constraints when all you have at your disposal is 
the total input traffic on each input interface, but no knowledge how much 
of this traffic actually goes to a given output?

Thanks in advance for a clarification,
Anna

At 01:02 PM 12/11/00 -0500, Joel M. Halpern wrote:
>second of EF, and a total burst limit on the output of 32,000 
>packets.  The common output is a 40 gigabit link.  The EF scheduler in use 
>alternates EF packets and everything else.
>
>elucidate any more).  Also assume that the input links are 44 megabits, 
>and the bursts arrive at wire rate.
>The earliest time it could have left is obviously its arrival time plus 
>the fixed delay.  Therefore, in units of time the maximum time difference is

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Dec 2000 18:24:08 -0500

Yes, it (S) is dependent upon the matrix I chose.  In fact, the zero-loss 
domain of the definitions in your document is also dependent upon such a 
matrix.
Yours,
Joel M. Halpern

At 06:25 PM 12/11/00 -0500, Anna Charny wrote:

>for the moment to be going between all low-speed interfaces, of which 
>there are 500.  (I am assuming that all interfaces are full-duplex, so for 
>any input interface of speed X there is also an output interface of the 
>same speed X.
>you would have to have S at least equal to 499, because one packet 
>destined to the same output interface can arrive at the same time for a 
>given output, (and this does not even include the allowed input burstiness 
>that would need to be used as an additional multiplier). So if you are 
>>interfaces supporting EF traffic are directing that EF traffic to a 
>>common output.  The implementor must specify, for the burst limit that he 
>>is willing to support, what the R and S are for each input.  For 
>>simplicity, all of the inputs will use the same R in this example.
>>
>>packets.  The common output is a 40 gigabit link.  The EF scheduler in 
>>use alternates EF packets and everything else.
>>
>>Plugging back in the 4 megabits / second EF input rate and the 40 
>>gigabits / second output wire rate, and the alternate packet scheduling, 
>>we see that
>>     S = 6.4
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Dec 2000 18:02:35 -0600

Your point isn't clear. There isn't any real difficulty in doing a lab
test to measure the sequence E(i) with a standard traffic source,
followed by a test to measure D(i) with the same source but in the
presence of other traffic from one or more other standard traffic
sources. There is a significant difficulty in doing the same thing 
outside the lab, but that is nothing new and nothing specific to EF.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: demir <[email-masked]>
Date: Tue, 12 Dec 2000 04:18:39 -0800 (PST)

Brian,
My point was about in the presence of other traffic (non-EF traffic).

Alper K. Demir