Subject: RE: [Diffserv] A Simple One-line Definition of EF service.

From: Jon Bennett <[email-masked]>
Date: Wed, 26 Jul 2000 22:53:10 -0400

> Here's a simple one-line definition of the EF service.

Unfortunately this definition is even less implementable 
than the one found in RFC 2598.

But at least it is easier to show that this is the case...

> ------------------------------------------------------------------
> First, I establish some convenient terminology:
> 
> 'Packet Arrival': The last bit of a packet has entered the router.
> 'Packet Departure': The last bit of a packet has quit the router.
> 'EF_Period': 1/Configured_EF_Rate. Here, the rate is measured 
> in bits/sec.
> 
> -----------------------------------------------------------------
> Definition of EF service:
> 
> A packet of size B bits departs within B*(EF-Period) time units of
> entering the router.
> 
> -----------------------------------------------------------------

Consider the following scenario,

Link rate          = 100 bits per second
Configured_EF_Rate = 10 bits per second
EF_Period          = 1/10 seconds per bit
Assume all packets are 1 bit long.

At time 0, 20 EF packets arrive on 20 different input links, 
each of these packets must depart by time B*EF_period or
1 bit * 1/10 seconds per bit = .1 seconds.

Unfortunately the link can only transmit 10 bits in .1 seconds 
so 50% of the EF packets will fail to leave the router in time
as required by this definition.

jon

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

---

From: Mahadevan Iyer <[email-masked]>
Date: Wed, 26 Jul 2000 22:54:20 -0700 (PDT)

Jeez, sorry, my earlier definition was absurd, hehe. How can any
finite-capacity scheduling scheme provide any guarantee without
constraints on the arrival rate? So here's the completed definition :)

The following definition will handle the overloading scenarios that you
pointed out. Basically, this definition says that the EF packet latency is
bounded by the 1/Configured_Rate *if* aggregate arrival rate is less than 
Configured_Rate. Else, there is no such guarantee.

Definition is stated below after your reply..

> But at least it is easier to show that this is the case...

With the above terminology,
----------------------------------------------------------------
Definition of EF service:

If a packet of size B bits arrives at least B*(EF_Period) seconds after 
arrival of previous packet, then it departs within B*(EF_Period) seconds 
of its arrival.

----------------------------------------------------------------

Remarks:
1. With above definition, if arrival rate is less than or equal
to configured rate, then actual departure rate is equal to arrival rate
and moreover if this is so always from time 0 onwards, then no EF packet
ever has to get queued and wait behind another EF packet.

2. The above definition doesn't specify what the input queueing or
output queueing or dropping policy is if arrival rate is more than
configured rate. Say, one could additionally specify that a B-bit packet
arriving within B*(EF_Period) of the previous packet should be dropped.
But this kind of small time-scale policing seems too strict and not easy
to implement in practice. Maybe relax it a little and monitor only over
some larger time-scale? Hmm...needs more careful thinking..