Subject: Re: [Diffserv] EF RFC and loss

From: Omar Elloumi <[email-masked]>
Date: Mon, 15 Nov 1999 15:41:48 +0100

Hello,

I went through the emails on EF and losses but I'm still
confused. The original question was do we need absolute zero
loss in EF or not?
Some of you responded no (few losses are tolerated),
in that case how can we distinguish packet losses due
to possible attacks from tolerated losses??? do we
need to have a threshold above it we trigger an alarm
to check a possible attack?

My intention is NOT to trigger a new discussion but just
to have in few lines a definitive (formal if possible) answer to this.

kind regards.

--
____________________________________________________________
Omar Elloumi

Alcatel Research - Network Architecture - Traffic Technology

Francis Wellesplein 1, 2018 Antwerp, Belgium

Phone: + 32 3 240 78 33
Fax:   + 32 3 240 99 32
http://www.alcatel.com/crc/
____________________________________________________________

Opinions expressed are those of the sender and do not reflect Alcatel
policy or agreement

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

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 15 Nov 1999 08:22:50 -0800

Hi,

If the question is solely "do we need absolute zero
loss in EF or not?" then an answer could go something like
this:

	- EF is intended for virtual leased line ('a wire
	  between two points') services
	- Wires dont drop packets, congested interfaces at
	  the ends of the wires drop packets (barring cosmic
	  radiation corrupting bits in transit along a wire)
	- Ergo EF's target packet drop rate ought to be
	  that of the equivalent 'wire' without cosmic
	  radiation -> i.e. zero.

(I didn't say it was a good line of argument, but it works for
me :)

cheers,
gja

---

From: Anurag <[email-masked]>
Date: Mon, 15 Nov 1999 23:14:02 +0800

Hi

As I understand, according to the present RFC on EF PHB, there is no way
to distinguish between packet losses due to buffer over flow or attack.
Both shall trigger alarm. 

regards
Anurag

---

From: Panos GEVROS <[email-masked]>
Date: Mon, 15 Nov 1999 17:57:43 +0000

Grenville Armitage writes:

 |
 |	- EF is intended for virtual leased line ('a wire
 |	  between two points') services
 |	- Wires dont drop packets, congested interfaces at
 |	  the ends of the wires drop packets (barring cosmic
 |	  radiation corrupting bits in transit along a wire)

may i add that
Wires also don't buffer packets

from previous discussion in this thread my understanding was that :
	-EF is about *no* loss and *no* queueing delay.
	-packets that arrive on different input interfaces and need to be forwarded 
on the same output interface EF queue may create instantaneous backlog and 
non-negligible queueing delays.

is this correct ? 
(if yes doesn't it break the service)
i hope there is a yes/no answer, if not pointers to relevant work would be 
appreciated.

Thanks in advance,
Panos

 |	- Ergo EF's target packet drop rate ought to be
 |	  that of the equivalent 'wire' without cosmic
 |	  radiation -> i.e. zero.
 |

 |Omar Elloumi wrote:
 |> 
 |> Hello,
 |> 
 |> I went through the emails on EF and losses but I'm still
 |> confused. The original question was do we need absolute zero
 |> loss in EF or not?
 |> Some of you responded no (few losses are tolerated),
 |> in that case how can we distinguish packet losses due
 |> to possible attacks from tolerated losses??? do we
 |> need to have a threshold above it we trigger an alarm
 |> to check a possible attack?
 |> 
 |> My intention is NOT to trigger a new discussion but just
 |> to have in few lines a definitive (formal if possible) answer to this.
 |> 
 |> kind regards.
 |
 |_______________________________________________
 |diffserv mailing list
 [email-masked]
 |http://www.ietf.org/mailman/listinfo/diffserv
 |Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
 |

---

From: Kathleen Nichols <[email-masked]>
Date: Mon, 15 Nov 1999 10:22:00 -0800

> to have in few lines a definitive (formal if possible) answer to this.

Perhaps the correct way to think of it is that the PRESUMPTION
has to be no loss. The construction of a VLL behavior
aggregate using the EF PHB is to eliminate congestive loss
for those packets. The work of preparing the traffic properly
is pushed to the edges where it can be shaped or policed or
whatever is appropriate for the type of traffic using it. That's
information that might be available at the edge.

	Kathie

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 15 Nov 1999 13:34:10 -0500

> Wires also don't buffer packets

Well, even telephone systems are digital now, so even they suffer
from _some_ amount of packet delay. EF is supposed to emulate this
kind of service, as well as perhaps less stringent requirements.

> non-negligible queueing delays.

Uh, well, why not let's pick a packet size of, say, 53 bytes?
That'll keep delay low enough. :)

Everything I've read so far about interactive applications used by
human beings is that 150 msec is considered acceptable. This does
not necessarily apply to control systems, which may have much more
stringent requirements.

So EF if used for interactive multimedia applications does not need
to be _no_ delay. If used in a control system setting, delays in the
1 to 10 msec range or so are certainly within the realm of
possibility. But this would typically be over short distances/few
hops.

Bert
[email-masked]

---

From: Stefano Salsano <[email-masked]>
Date: Mon, 15 Nov 1999 21:13:11 +0100

Dear Omar,

here is the "formal" answer from my side:

1) EF PHB in itself, as described in RFC 2598 does not prescribe 
   anything related to loss, but simply that a router MUST guarantee 
   a configurable aggregate rate of outgoing EF packets.

2) The VLL or premium service which is described in RFC 2598 prescribes
   that you configure your network (with traffic conditioners at the
edge)
   in order to have NO LOSS. In a network that provides such a VLL
service
   a loss event can be caused only by: misconfigurations, phisical 
   transmission errors, security attacks...

After these formal statements, let me add my comments:

- the buffer requirements to provide a VLL service with DETERMINISTIC
  NO LOSS in a medium/large scale network are very high, or conversely
the
  utilization of EF traffic must be kept very low
- nothing prevents an ISP to provide different services based
  on the EF PHB where the NO LOSS constraint is relaxed... but none
  of this service is described in any RFC... I would call this service
  "statistical VLL"... I think this kind of services can be needed for
  example for Voice over IP if you want to have a reasonable
utilization...

Regards,
Stefano

---

From: Frank Kastenholz <[email-masked]>
Date: Tue, 16 Nov 1999 11:02:02 -0500

The _ideal_ behavior for EF might be 0 packet loss and 0 delay (other
than cosmic-ray type losses and speed-of-light delays). However, this
will not be the case in the real world. Building applications that assume
that these characteristics will absolutely met would be living rather
dangerously.

EF will have some packet loss above and beyond Grenville's cosmic rays.
Routers fail and the packets in the failed router are lost, as are all
the packets that are sent to that router (until the routing protocols
reroute). Ditto for links failing (no amount of DiffServ specification
can prevent a backhoe from eating a fiber when it gets hungry).

Also, routing just isn't all that stable and packet-loss, connecticity-
loss, etc-loss, can happen for no apparent reason. Just look at the
periodic outages we had at the WDC IETF meeting last week. 

Long-term, these losses are probably in the noise. However, short-term
the loss-rates could be substantial

About all you can say about EF and packet-loss is
    If the network is properly traffic engineered (including the proper
    configuration for BE traffic) then there ought to be no loss due to 
    buffer overflow  -- i.e. no congestive loss

As to delay, again I hate to disappoint but there will be delay,
above and beyond the speed-of-light propagation delay.

There will be the intra-router delay.  Even if there is no load,
a router will take a certain, non-0, amount of time to do its thing.
High-speed routing technology optimizes for packet-rate by
increasing parallelism and therefore latency. The routing silicon
could have many 10's of packets 'in flight' at any one time waiting
for memory accesses to complete, etc, etc.

There will also be queueing delay. Consider a router with three
interfaces, A, B, and C. Two EF packets come in, one via interface
A and the other via interface B. They both are to go out interface C.
Only one will go out at a time. The other will have to wait.

Another possibility, consider an OC48 Packet-over-SONET line.
There could be an IPv6-jumbo-gram (which can be _real_ _huge_,
possibly taking several seconds on the link) going out when an
EF packet comes in. The EF packet will just have to wait...

In addition, real implementations of packet processing all have
some fifoing between the queuing logic and the physical link.
The queuing logic is where the EF/AF/.. decisions are made and
the next packet to be sent is selected. Then that packet sits in 
the fifo until it reaches the head of the fifo and then off it 
goes. Fifos may be several KB deep.

About all you can say about EF and delay is
    If the network is properly traffic engineered (including the proper
    configuration for BE traffic, such as for MTU) then delay should 
    be highly characterizable, and jitter will be minimized, but not 0.

Frank Kastenholz

---

From: Siamack Ayandeh <[email-masked]>
Date: Thu, 18 Nov 1999 13:16:32 -0500

> to have in few lines a definitive (formal if possible) answer to this.

Omar,

There can be no formal answer to a rather informal notion.
Let's put loss in perspective.  What do you mean by zero loss?

1. Bit error rate on an OC-48 fiber interface gives you 1-bit error
every 6 minutes or so.

2. With a probability between 10E-17 & 10E-18 the same
fiber may be cut with a back hoe.

If you do some back of envelope calculations the probability
of buffer overflow, for reasonable size buffers, and independent
sources is smaller than 1 & 2.

Since reasonable size buffers, as of rfc 2598, seem to work, the
question of delay is also a non issue.

Regards, Siamack