Subject: Re: [Diffserv] EF RFC and loss

From: [email-masked]
Date: Thu, 28 Oct 1999 16:45:29 +0200

Grenville,

>>[email-masked] wrote:
     [..]
>> I  was under the impression that a statistical packet queueing
>> process always entailed a loss probability,
>> that can however  be engineered to a low but non-zero value.

>EF imposes requirements that the queue serving rate is
>not dependent on random traffic characteristics in other queues, and
>is always larger than (within a small delta) the queue arrival rate.
>Therefore it is expected that a buffer big enough to hold a couple
>of EF packets should not overflow under proper operating conditions.
>
Your reply indicates to me that, even under proper operating conditions, it
should not but it may and can genuinely happen that a packet is lost.
So why should this rare event trigger the "notion of attack or serious misconfiguration"
as stated in the RFC.

>cheers,
regards,

>gja
manu
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 28 Oct 1999 07:56:42 -0700

> So why should this rare event trigger the "notion of attack or serious

Because _congestive_ losses when using EF _are_ a consequence of
misconfiguration (e.g. ingress shaping to lax, or queue servicing
interval insufficient, or someone assigned EF to the 2nd queue of a
priority scheduler and it is getting starved) or attack (which
results in the nett arrival rate exceeding the queue service rate).

Of course IP systems are rarely perfect, so packet loss is always
theoretically possible along an EF path (e.g. cosmic bit errors),
but congestive loss should not be part of the loss scenario when
the system is running properly.

cheers,
gja

---

From: "Albert Manfredi" <[email-masked]>
Date: Thu, 28 Oct 1999 11:34:27 -0400

----- Original Message -----
From: <[email-masked]>

[ ... ]

> Your reply indicates to me that, even under proper
> operating conditions, it should not but it may and can
> genuinely happen that a packet is lost. So why should
> this rare event trigger the "notion of attack or serious
> misconfiguration" as stated in the RFC.

Doesn't this only apply to the discussion about security features,
if they are invoked? And is it not a generic problem with dropping
packets in such cases?

Bert
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 1999 11:45:55 -0500

> if they are invoked? And is it not a generic problem with dropping

Right, to put it in elementary terms, an attacker could flood
an inadequately protected network with more premium traffic than
the premium service was configured to carry. Debugging such
an attack would be a matter of packet dumps, I suspect. But if 
the ingress policing is adequate, such an attack will fail.

   Brian

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 28 Oct 1999 09:05:53 -0700

what Grenville said.

	Kathie

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

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 28 Oct 1999 19:11:14 +0200

Dear all,

I'd like to add a comment on the discussion on "EF" and loss:
the discussion should more correctly refer to "premium service"
and loss.

The EF PHB does not imply zero loss at a node, but simply that 
a given service rate is provided to the EF aggregate.

The EF PHB CAN be used to support a "premium service" which is
engineered to provide zero loss, by means of traffic conditioning. 
As long as a "premium service" is provided in a network, the loss
of a packet due to queue overflow is a symptom of misconfiguration.

Best regards,
Stefano

-- 
*******************************************************************
Stefano Salsano
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
                  
E-mail  : [email-masked]      URL     : http://www.coritel.it
Tel.    : +39 06 20410029         Address : Via di Tor Vergata, 135     
Fax.    : +39 06 20410037                   00133 Roma - ITALY          
*******************************************************************

---

From: "Scott W Brim" <[email-masked]>
Date: Thu, 28 Oct 1999 14:58:00 -0400

>So why should this rare event trigger the "notion of attack or serious 

EF will drop packets if it has to in order to maintain the delay budget 
for the packets that get forwarded.  In a properly managed network very 
little excess EF traffic will be admitted.  So if you're seeing a lot of 
excess traffic, either your hardware is broken, your capacity management 
is broken, or someone is sneaking packets in.

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 28 Oct 1999 14:34:32 -0700

Scott W Brim wrote:
...In a properly managed network very
> is broken, or someone is sneaking packets in.

I would say "In a properly managed network NO excess EF traffic
will be admitted." But perhaps you have a different definition
of "excess" that I do. 

I think dealing with the excess traffic in a reasonable way is
what the "better effort" or "class of service" services are
all about. Traffic marked for the EF aggregate shouldn't have
any of this excess.

	Kathie

---

From: "Scott W Brim" <[email-masked]>
Date: Thu, 28 Oct 1999 21:09:24 -0400

>all about. Traffic marked for the EF aggregate shouldn't have

:nods

---

From: Ion Stoica <[email-masked]>
Date: Fri, 29 Oct 1999 13:14:34 -0400

Hi,

I just want to make a clarification with respect to the burstiness and
buffer requirements at core routers for the premium service. In
particular, the burstiness at an input/output port of a core router can
be as high as the _number_ of EF flows that share that link.

Assume you have a router with N ports, and assume that EF traffic with
a burst size of M packets arrives at each input port (i.e., there are
M consecutive packets belonging to the EF traffic arriving at each
input).  Then, if the EF traffic from all inputs is going to the same
output, the burstiness of the EF traffic at that output will be M1 =
N*M.

Thus, even if you start with perfectly regulated flows at each ingress
(i.e., with burstiness 1), the burstiness at the output link of the
s-th hop can be as high as N^s. 

On the other hand, the burst cannot exceed the total number of flows
on the output link. Let m be the number of flows on the output
link. Then the traffic burstiness at the s-th hop is

      min(m, N^s) (1)

Since at least theoretically we can arbitrarily increase s, let us
consider that the burstiness is bounded by m.

Now, let us compute the buffer requirements. For this consider again
the one router case in which EF traffic with burst size of M packets
arrives at each input port, and the EF traffic from all inputs goes to
the same output. Assume that the link speeds of the outputs and inputs
are the same. This means that during the time it takes M consecutive
packets to arrive at an input, the output will transmit at most M
packets. Thus, at the end of the bursts the output will still have at
least

      (N-1)*M  = N*M - M = M1 - M1/N (2)

buffered packets waiting to be transmitted.

Since the burstiness on the output link M1 is bounded by m, i.e., the
number of EF flows at the output port, from (2) it results that the
buffer requirements at the output can be as high as

      m - m / N

EXAMPLE: Assume an OC-48 (2.4 Gbps) link and 32 Kbps EF flows. Further
assume that the EF traffic is limited to 20 percents of the link
bandwidth. Let C denote the link capacity and let r denote a flow
rate. Then, the number of flows at the output port can be as high as

    m = 0.2 * C / r = 0.2 * 2.4Gbps / 32 Kbps = 15000

If we assume that the router has N=32 ports, then the buffer size should
be at least 

    m - m / N = 14531 packets

Finally, I have two comments:

1. If you regulate the aggregate EF traffic at each output, this will
not help in the context of the above example. In particular, assume
that you restrict the EF traffic to 30% of the link capacity. But then
you can still have M packets arriving at each input at the rate
0.3*C. Since the output cannot send more than M packets during the
same time interval it takes an input to receive M packets (as the EF
traffic at the output is also rate limited to 0.3*C) the number of
packets that needs to be buffered at the output at the end of the burst
is still m*(1 - 1/N). Worse yet, regulating the EF traffic will increase
the end-to-end delay.

2. The above "bound" is only for feed-forward networks; for general
networks (in which the paths of several flows can result in cycles,
e.g., flow f1 shares a common sub-path with f2, which shares a common
sub-path with f3, which shares a common sub-path with f1) they can be
much worse. For more details see

  R. Cruz, A Calculus for Network Delay, Part {II} : Network Analysis,
  IEEE Transaction of Information Theory, 37, 1, 121-141, 1991.

Ion