Subject: RE: differential services tos octet

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Wed, 15 Oct 1997 13:27:04 +0200

As I seem to be responsible for the 3 drop preference (DP) bits, I should   
try to give reasons for the use of the bits.

 -------- Why 3 bits for Drop Preference --------

If we suppose that a network already has all the different service   
classes (guaranteed, controlled load, best effort), and RSVP implemented,   
and then some priorities are introduced in the network for the sake of   
improved congestion control, then 1 DP bit could really be enough.

But, that is NOT the idea of using 3 DP bits. Instead, my statement is   
that the use of 3 DP bits makes possible to introduce a new service type   
that has several promising characteristics. The service, called SIMA, has   
been described in draft "draft-kalevi-simple-media-access-01.txt". SIMA,   
or any service with similar characteristics, cannot be implemented by one   
DP bit.

So what are the characteristics, and why do we need 3 bits? I try to give   
a short answer.

3 DP bits means dynamics while 1 bit is only on/off. The dynamics make   
possible to integrate connections with essentially different QoS   
requirements into one network service: from pure best effort to high   
quality connections. In addition, with one (or perhaps two) delay bit(s)   
real-time and non-real-time flows can use the same service, and   
therefore, share very efficiently the same link capacity.

Based on an extensive research effort, I would claim that this type of   
service can be managed without any resource reservations. The key point   
is that the 3 DP bits can be used to make a direct relationship between   
charging, actual bit rate of the flow and quality. The price difference   
between services with lowest and highest quality is so large that it is   
very improbable that the load of highest priority level will exceed the   
network capacity. So, resource reservation will be replaced by a charging   
scheme. This is a big issue, as it may solve many scalability problems.

In general, charging is a very important issue, and with SIMA service it   
has some attractive properties: the same charging principle is   
appropriate to all quality levels, both to real-time and non-real-time   
flows, and moreover, it takes automatically into account the difference   
between idle and busy hours. But, for this we need 3 DP bits.

One more reason for 3 bits: if TCP/IP is used with SIMA, each flow gets   
network capacity proportional to the charge of the flow.

Once again, 3 DP bits are not intended only for controlling congestion   
situations, but they are used to create a new complete network service   
with some very promising characteristics. Of course, in a short mail like   
this I cannot address all the important issues, but you may visit the   
web-pages at http://www-nrc.nokia.com/sima/, and I am ready to answer any   
questions about the SIMA service.

Regards,

Kalevi Kilkki
[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Wed, 15 Oct 1997 18:15:22 -0700

Oops.  I wrote:

> Non-adaptive users can always decide not to stop using an adaptive
> application...

Change "decide not to stop" to "decide to stop".

Steve

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Fri, 17 Oct 1997 10:47:23 +0200

The difference between 1 DP (drop preference) bit and 3 DP bits is quite   
similar to that between RED and FRED (or the fair buffer allocation   
scheme proposed by Juha). A system with 3 bits, that is 8 levels, makes   
possible much better fairness between different connections.

And why to use 3 DP bits in every packet instead of FRED? Because of two   
main reasons:

1) if the information is in every packet then there is no need to keep   
record on connections in the core network,

2) at the access of the network there is essentially better possibility   
to determine the priorities (DP and delay)

.. Kalevi

 ----------
From:  Juha Heinanen
Sent:  16. Octoberta 1997 9:16 PM
To:  ferguson
Cc:  wuchang; int-serv
Subject:  Re: differential services tos octet

Content-Transfer-Encoding: 7bit

   Whiile connections in RED experience the same packet
   loss rate, FRED makes different dropping decisions over connections
   with different bandwidth usages by use of per-active-connection
   accounting.

i wonder how the connections are identified when people are encrypting
their ip packet payloads before sending the packets to the isp, i.e., is
per connection anything practical in the current world of secure
intranets?

otherwise the idea described in the paper seems to be quite simular to
what we have proposed a couple of years ago for implementing per
connecting fairness for atm
(ftp://lohi.dat.tele.fi/atm/articles/heinanen-fair-buffer.ps).

 -- juha

---

From: "Alessio Casati" <[email-masked]>
Date: Fri, 17 Oct 1997 09:43:21 +0100

On 16 Oct 97 at 14:46, Philippe OECHSLIN wrote:

> 
> Alessio,
> 
> [email-masked] said:
> >  So, good application designer will design the application so that in 
> > such a situation it sends a bit to the sender saying "Please, don't 
> > send Video, It's useless 
> 
> If you rely on good applications not to send data which would be dropped in 
> the network you don't need different drop priorities in the first place.

The problem  was what to do with the out of profile stuff. If the network is
designed so that people sending out of profile packets get *penalized*, then I think
people are going to buy good applications designed by good application designers.
DP bit is a hook for identification of out of profile packets. You need that
to build the penalization mechanism. Whithout the DP bit in Steve's scenario also
audio packets would experience loss.

Is that fair?

> > Now and then S2 will attempt to increase the DP to probe for 
> > bandwidth (and lower ISP rates)
> 
> Here you use the DP bit to signal that you would like to benefit from a lower 
> tarif while the network is not congestioned. You can do that with any other 
> bits that express your quality of service, it doesn't have to be DP.

I agree. Rates will not necessarily be related only to DP. But, I suppose, if you are looking for 
lower rates within the same service class, most likely you will have to give up something. First 
class drop rate is one of them. The most appropriate way to do that might be based on something 
different from DP bit, and the WG is going to find out that. But if you want to use some 
leftover(cheap) bandwidth, the only way, I suppose, is to go out of profile (that is lowering the
requirements your profile convey),or allow the network to drop (or delay) your packets with
higher priority wrt others. 

Please correct me.

bye 

Alessio Casati

---

From: Francois Toutain <[email-masked]>
Date: Fri, 17 Oct 1997 14:28:12 +0200

> Interesting.  I am unclear about whether you are talking about priority or
> drop preference.  Some differences between those two mechanisms are:

Ooops. Sorry for that. Actually I was talking about drop preference, although
SIMA includes both DP and "delay priority" (call it...DP ? ;-) So let me
explain again.
With a given nominal bit rate, your packets get a DP value which is:
- higher than a "mean value" if the actual rate is lower than the NBR,
- the mean value if the actual rate equals the NBR,
- lower than the mean if the actual rate is higher than the NBR.

The point is, a CBR traffic gets the same DP value for all packets. Hence packet
losses won't give preference to some packets over others. Thus the end
application gets an incentive to reduce its rate in the same way as TCP
currently does (or rather: doesn't get an incentive to stay with its current
rate...)
When the traffic is not CBR, packet bursts get a lower DP than packets being
sent during low-rate periods. If/when losses occur, again there is no
preference as to which packets are discarded. So again the application gets
no incentive to go on sending the burst, because it cannot use DP to
"protect" high importance data from being lost.
Basically the difference I see between SIMA and other DP schemes is that
SIMA wasn't designed to protect some piece of data inside a session (the
"in-profile" one), but rather to differentiate between competing sessions.
See it as a mechanism that enforces some kind of "fairness".
 
So in summary, I believe SIMA has the same "neutrality" with respect to
good/bad behaviour as the current Internet, and also that it may need further
means to encourage good behaviour, such as are currently discussed (i.e.
(F)RED, FQ...). Such mechanisms however should not interfere with the
"fairness" provided by the scheme.

> Hmm, I guess I ought to go and
> read the SIMA proposal before indulging in any more wild speculation based
> on trying to read between the lines of your brief message.  :-)

The easiest way is  http://www-nrc.nokia.com/sima/

> But
> within each priority level, I think it would be a mistake to support drop
> preference,

Actually in SIMA the view is reversed: it offers two priority levels (more
could be useful indeed) within each DP level. And I don't think it would
be a mistake to support such a scheme.

> I never said that priority schemes prevent good behavior; I said that
> drop-preference schemes encourage bad bahavior.

I have tried to say that not all DP schemes (counter-example = SIMA) encourage
bad behaviour. Did I make sense ?

Cheers
-ft.

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Mon, 20 Oct 1997 14:59:58 +0200

There have been two questions concerning the use of delay bits:

   In case we allow applications to set delay priority bit(s),
   how do we charge for the low-delay packets? (Hyogon Kim)

and

   It is an interesting question as to which (delay priority or dropping
   priority) is more important  (Zheng Wang).

The apparent meaning of delay indication bit is that the network provides   
smaller delay for certain packets than for some other packets. But that   
does not mean that those two groups experience different loss ratio, if   
the drop decision is made before and independent of the queue selection.   
So in order to keep delay and loss properties independent of each other,   
dropping should be made first and then the queue selection. (I have tried   
to illustrate the situation at http://www-nrc.nokia.com/sima, especially   
under the item "material for the mailing list discussion").

But then, why does not everyone request short delay? The reasoning goes   
roughly in the following way:

1. Short delay means small buffers
2. Small buffers means that the network cannot allow high burstiness for   
real-time flows
3. In order to punish flows with high burstiness the traffic profile   
shall be different for real-time and non-real-time flows
4. If the burstiness of the flow is high, the flow gets lower priority   
with real-time service than with non-real-time service.
5. If delay is not important for the application, non-real-time service   
is better for the user.

If the traffic profiles for real-time and non-real-time services are   
determined correctly, there is no need to have different charging for   
real-time and non-real-time services.

.. Kalevi

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Mon, 20 Oct 1997 16:13:17 +0200

Roch,

I agree with you except that, in my mind, there is not much use of   
quantitative guarantees with a majority of applications. For instance, if   
someone is using tcp/ip, I am wondering what kind of quantitative   
guarantees networks may give and how users can know that the network is   
obeying the guarantees.

With certain applications, like video, guarantees might be useful. But   
what is the ultimate target for the user? I believe that most users are   
satisfied if the quality of application is good enough, independent of   
any network performance parameters. The most important issue is that the   
connection is available when needed (where availability means that packet   
loss ratio does not exceed a threshold that can be difficult to determine   
in advance). As for these services, a network with several drop   
preference levels means different availability or reliability levels   
(rather than different packet loss probabilities).

So, if we have 3 DP bits, it does not mean that there is 8 different   
service classes with pre-defined quality parameters. Rather, these 3 bits   
form the basis of the service, and the quality of each DP level depends   
on the general readyness to pay for quality, reliability and   
availability. 3 DP bits offers much more dynamics than 1 DP bit in that   
sense, and dynamics is needed because of very intense traffic variations   
in the network.

.. Kalevi

 ----------
From:  Roch Guerin
Sent:  18. Octoberta 1997 1:21 PM
To:  Fred Baker
Cc:  Juha Heinanen; esc; int-serv
Subject:  Re: differential services tos octet

Content-Type: Text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Fred,

>OK, I would suggest that this is that what you are asking for in the   
case
>is not a certain drop preference and a certain delay preference. They   
all
>have the same delay preference - whatever delay they encounter, they   
want
>it to be consistent. What's different is the drop preference - you take   
the
>janitor's phone call and make it the thing to drop if anything is going   
to
>get dropped, and by the way, if there's many drops, you'd like to drop   
the
>whole call.

I think this is a rather narrow view of things.  You'll have the
janitor phone call and the janitor web traffic.  The two don't have
the SAME delay preference.  There are certain applications that need
to go first, but that does not mean you've got to drop others to
achieve that.  If you do that, you'll end-up with a network with
pretty low utilization, and I don't think you want that.
So, I'll contend that you need BOTH delay priorities and drop
precedence.

I don't buy the argument that "links are going to be so fast that we
don't need to worry about delay".  As I think you even mentioned
yourself in a previous note, we'll have a heterogeneous environment
with high and low speed links, so that we MUST have mechanisms to
support delay priorities.  And as buffer sizes have been regularly
increasing, I believe we'll need similar capabilities even on high
speed links.  This does not mean that we'll need the same granularity
on all links, i.e., per flow on low speed links and class-based on
high speed links, but support needs to be there.

Concerning drop precedence, I personally think one bit will suffice,
and certainly if we are squeezed for bits I'd use them to specify
delay priorities, but I don't have problems having more than one drop
precedence if there are bits left.  I just don't think you can provide
a  QUANTITATIVELY accurate service definition for multiple drop
precedences.

Roch

---

From: Indra Widjaja <[email-masked]>
Date: Mon, 20 Oct 1997 13:35:55 -0400

At 02:59 PM 10/20/97 +0200, Kilkki Kalevi NRC/Hki wrote:

..deleted
>2. Small buffers means that the network cannot allow high burstiness for   

Kalevi:

Maybe you should first *define* what "burstiness" exactly means.
For example, some real-time traffic such as packet voice and video
are often said to be "bursty", and yet they do not require a lot of buffering.

..rest deleted

indra

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Wed, 22 Oct 1997 12:02:51 +0200

Yes,

burstiness is indeed a difficult term, it seems to be impossible to give   
any generally applicable definition.

In this is case, the point is that small buffers (let say 10 kbytes or   
200 ATM cells) cannot manage large packets (like 1 kbyte), or otherwise   
the load level must be extremely low. So the buffer size to burst size   
ratio is the key factor (where burst is either a packet or several   
packets transmitted back to back). General traffic theory tells that if   
this ratio is large enough (say 100), utilisation can be high, but if the   
ratio is small (say 10), either packet loss ratio is high or utilisation   
level is very low.

This is strongly simplified, I know, but a detailed story needs perhaps   
100 pages (e.g., there is some tens of pages about this issue in my   
doctoral thesis).

.. Kalevi

 ----------
From:  Indra Widjaja
Sent:  20. Octoberta 1997 1:35 PM
To:  Kilkki Kalevi NRC/Hki; int-serv
Cc:  Hyogon Kim; [email-masked]'
Subject:  RE: differential services tos octet

        [email-masked] ([email-masked]')

..deleted

Kalevi:

Maybe you should first *define* what "burstiness" exactly means.
For example, some real-time traffic such as packet voice and video
are often said to be "bursty", and yet they do not require a lot of   
buffering.

..rest deleted

indra

---

From: Pawan Goyal <[email-masked]>
Date: Fri, 24 Oct 1997 10:45:05 -0400 (EDT)

>In congestion instances you are mainly interested in distributing the
>bandwidth/resources in a fair manner among the congested connections.
>There is absolutely no requirement to remember what flows have done
>earlier or what they will do later. This is a saficient action for 
>preventing some users (either they are called short fast-reacting
>connections or mis-behaving connections, or reverse ack streams) for
>monopolizing the bandwidth. 
>
>And if we follow the fair queueing model, the service offered to
>a connection is a function of its weight and the other connections
>that are BACKLOGGED in the system. This definition shows immediately
>that connections that are not present, do NOT affect the bandwidth
>distribution. As a result, there is no need to reserve resources for 
>these connections.
>

Most of the fair queuing algorithms need to maintain state 
even for flows that are *not backlogged* (Self-clocked Fair Queuing is
one exception that I know of). Hence, state in fair queuing algorithms
is usually proportional to the number of flows and not buffer space.

Pawan