Subject: Framework for differentiated services

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Wed, 05 Nov 1997 16:09:53 +0200

I have followed the recent discussion on this list and became somewhat   
anxious. I believed that the target was to create a new type of service   
for Internet based mainly on some bits in IP packets. And the result was   
aimed to be simpler than the current approach relying primarily on RSVP.

But now almost everyone considers some seemingly separate issues - some   
bits here and some problem there without too much common view. In this   
way the result will certainly be much too complicated (if anything).   
Particularly, if all problems are tried to solve in the same way as   
earlier, that is, with pre-defined traffic and quality parameters,   
resource reservations, signalling systems etc.

Let us try to do something else and, first of all, let us take seriously   
the simplicity target, there is already plenty of complicated systems to   
handle QoS in public networks. No need to do one more.

Below is my very preliminary framework document for this task.

=> Q0: The first question is whether this could be a basis for a common   
framework document or not.

Anyway, there are some questions (Q1-Q9) on which I am keen to know your   
opinions (if someone is interested enough to read the following pages).

regards, Kalevi

=================================================================

Quality differentiation in Internet by means of drop preference and delay   
indication bits - A very preliminary draft

Target

The main target of this effort is to offer a simple way for QoS   
differentiation in Internet. The prime tool for doing this is to use some   
bits in every packet instead of any complicated reservation mechanism for   
every or most of the flows.

If possible we should avoid constructing any resource reservation   
mechanism in this effort, as the result will inevitable be something like   
RSVP, and that will not be simple. In addition, we must avoid building   
any new ABR service, because that will also be absolutely too complicated   
for our purposes. (My humble but solid opinion is that those kind of   
efforts do not belong here)

=> Q1: can we agree on these targets?

Therefore, the scope of this draft is to assess the possibility to use   
some bits in every IP packet for traffic control purposes. Technically   
speaking, the two main purposes are to define:

1) which packets shall be discarded under congestion situation, and
2) in which order packets will be transmitted forward.

=> Q2: is there any other relevant purposes for the bits?

In this draft the bits are called:

 drop preference (DP) bits and
 delay indication (DI) bits.

Together these bits are called control bits.

=> Q3: what could be proper names for these bits?

The area of this draft is specified based on a simplified network shown   
in figure 1. User (U1) is sending packets (P1) to the first access node   
(AN1) owned by an ISP (Internet Service Provider). ISP may modify the   
packets and send the modified packets (P2) to backbone network owned by a   
backbone operator. Backbone operator may, again, change some bits in the   
packet and then send the modified packets (P3) forward.

   P1      P2      P3
U1 ==> AN1 ==> CN1 ==> CN2 ==> AN2 ==> U2

This draft tries to define the meaning of the control bits in different   
parts of the network, in particular between access and core network   
nodes. In addition, we discuss about the allowed and possible control   
functions performed in access nodes (AN) and core network nodes (CN), and   
the properties of different approaches.

The main control functions available are

 Setting of control bits
 Profile specification for flows (or users)
 Traffic measurement of flows
 Queuing of packets
 Discarding of packets
 Traffic shaping

=> Q4: is there any other important functions?

We may further suppose that the actual customer relationship is between   
user and ISP, whereas the customer has not any direct relationship with   
backbone operators - the actual relationship is between ISP and BO.   
Although this not necessarily always the real situation, any control   
mechanism (including charging, rights of use, etc.) must be workable   
under this assumption.

The main technical issues are:

1) Related to control bits
 a) separate bit or mixed field for the DP and DI bits
 b) how many DP bits?
 c) how many DI bits?
 
2) What is the role of application requirements, rights to use, traffic   
measurement, charging, fairness, etc. in the determination of
 a) DP bits
 b) DI bits

3) Who (user, ISP or backbone operator) is allowed to change
 a) DP bits
 b) DI bits

4) Use of bits inside the network
 a) DP bits
 b) DI bits

=> Q5: is there any other important issues?

 ----

In the following there are some preliminary consideration about these   
issues.

1a) Separate or mixed bits

If a mixed control bit field is used then some DP/DI combinations are not   
available. But there must be a good reason for this, because all the   
possible combinations could be useful. For example, a combination of low   
delay and high loss ratio is a reasonable scenario with internet phone.   
Therefore, in the rest of the draft we suppose that separate DP and DI   
bits are used.

=> Q6: can we agree?

1b) number of DP bits

Solutions without any DP bit are not addressed in this document.

One DP bit means basically the same as the use of CLP (cell loss   
priority) bit in ATM networks. So there is a solid theoretical background   
and some practical experience for this approach. The research and   
experience have shown that CLP bits may yield some advantages but not   
without problems. The main problem is that since there is only two   
classes, the higher class must offer very high quality as regards packet   
loss ratio and reliability, whereas the lower class is basically of the   
same quality as the current best effort service in Internet. Therefore, a   
reservation mechanism for the higher class seems to be inevitable. This   
alternative tend to lead to the same complex system with reservations   
(RSVP), QoS routing etc. which are already specified in IETF.

The other alternative is to build a network with much extra capacity so   
that a high quality level can be guaranteed without reservations. Then,   
however, there is not much real difference between the two quality   
classes, and not much incentive to use the more expensive service.

(Two DP bits: to be written later)

Three DP bits can be used to enhance essentially the properties of the   
network service. The key point is that 3 DP bits with much wider dynamics   
may enable a system without any resource reservations. The whole traffic   
control system can be build on the basis of DP and DI bits - this is not   
possible with one DP bit. This is such a big advantage (if real) that we   
shall not prevent from using this approach.

=> As I guess that there is no consensus in this question area, we shall   
evaluate the properties of different approaches.

1c) DI bits

At least one delay indication bit seems to be necessary for the future   
interactive services in Internet, in particular for voice and   
video(conference) applications.

=> Q7: can we agree?

One DI bit makes possible to distinguish flows with interactive   
application from data flows. A low delay indication in a packet may mean   
that every network node offers as small delay for the packet as possible.

Two DI bits. Real applications can certainly be classified into more than   
two different delay classes. However, it is not clear whether more than   
two delay classes can be effectively supported in  heterogeneous Internet   
environment. Anyway, there seems to be considerable support for the use   
of 2 DI bits, but no consensus.

2a) What is the role of application requirements, rights to use, traffic   
measurement, charging, fairness, etc. in the determination of DP bits

Application requirement is one issue and a building network service with   
differentiated quality is another issue. There seems to be various   
opinions where the emphasis shall be and in which way these issues should   
be combined.

My viewpoint is that the primary target shall be building of a network   
service with different quality levels. An additional feature can be that   
the access node tries to optimise the use of this network service based   
on the information concerning application requirements.

The target is that user gets some service from the ISP and pays for that,   
and everyone using the same service pays the same and gets the same   
quality independent of the application he or she uses.

=> Q8: is there any possibility for common agreement?

Now, if the starting point is network service then fairness is a real   
target for the development of the service model. Fairness means that   
charging and actual consumption of network resources shall be properly   
taken into account.

2b) What is the role of application requirements, rights to use, traffic   
measurement, charging, fairness, etc. in the determination of DI bits

My understanding is that delay indication shall be left for user (or user   
application) and ISP and BO shall not change the delay indication bit.

=> Q9: can we agree?

Everybody shall in principle have the right to use low delay service.   
However, there must clear incentive for the user to select low delay   
service only when needed. This objective can be met either by proper   
charging and/or by taking the delay class into account when determining   
DP bits.

3a) Who (user, ISP or backbone operator) and where is allowed to change   
DP bits

There are different options, but if we try to specify a network service,   
the key role belongs to ISP. If and when the customer relation is between   
user and ISP, user pays some charge of the network service. Now the   
capacity and quality shall depend presumably on the charge not on the   
application. This is one way to guarantee a fair treatment of different   
users and flows.

However, the user may inform the network about the relative importance of   
certain packets, and the ISP may try to improve its service by using this   
information.

My current opinion is that the most feasible solution is that ISP   
determines the DP bits in the first access node, and these bits are use   
through the whole (public) Internet.

3b) Who (user, ISP or backbone operator) and where is allowed to change   
DI bits

As stated above, delay indication shall be defined by the user or user   
application, and ISP and backbone operators will usually not modify DI   
bit(s).

4) Use of bits inside the network
 a) DI bits
 b) DP bits

The basic principles are:

DI bits are used to select the proper queue for the packet, and
DP bits are used for packet discarding under congestion situation.

There a several technical issues not yet addressed in this draft version.

---

From: "Andrew T.Campbell" <[email-masked]>
Date: Wed, 05 Nov 1997 10:18:07 -0800

Kilkki Kalevi NRC/Hki wrote:
> anxious. 

I'm anxious for opposite reasons - why are we so keen to
jettison the work on network QOS developed 
over the last ten years? 

I feel that while the idea of differential services is simple,
pragmatic and appealing to researchers, vendors and ISPs it is 
a retrogressive step in trying to build QOS into the NGI.

Of course it is easy for me to make such a comment. It is
more difficult to back up that position with a counter argument.

IP/TOS exists today and is not widely used. Looks to me that the
proposals
are really deltas along the of TOS in IP with drop. With
priority bits you can only give preferential treatment to
packets or create souped-up overlay networks with N classes -
you can say very little about what we traditionally term end2end
QOS. With drop bits you can do smart - possibly, semantic-based 
dropping. 

Jon Crowcroft's idea of 1 bit for QOS and pricing presented in
his Keynote at PfHSN'96 takes the idea of DS to the limit I believe! 
It is an appealing idea that makes a number of trade offs.
But in my mind it is em .. wishful thinking - apologies in
advance Jon!

In summary, looks a lot of network researchers are tooling-down with DS. 
And looks like we are moving forward with ISP TOS and more $$$ but
backwards 
with QOS in NGI? 

Best,
Andrew
--
Andrew T. Campbell  
http://comet.ctr.columbia.edu/~campbell
Wireless Media Systems Project 
http://comet.ctr.columbia.edu/wireless

---

From: John Wroclawski <[email-masked]>
Date: Wed, 5 Nov 1997 11:58:40 -0500

>a retrogressive step in trying to build QOS into the NGI.

Hi Andrew,

I realize that the present discussion sometimes sounds otherwise, but I
don't think it's an either-or question. The differential services ideas are
actually quite complementary to previous work, and both diff-serv and that
work (RSVP, etc) fit nicely into a larger picture of providing customers
with the service they need at reasonable cost.

cheers,
-john

---

From: "Andrew T.Campbell" <[email-masked]>
Date: Wed, 05 Nov 1997 12:44:37 -0800

>John Wroclawski wrote:         

That is a relief - thanks for the clarification John.

Andrew

---

From: Bala Rajagopalan <[email-masked]>
Date: Wed, 05 Nov 1997 17:04:23 -0500

> with the service they need at reasonable cost.

I'd like to believe this, but the mantra nowadays seems to be
"RSVP is dead!". Indeed, just last week saw Juha in Frankfurt
airport, head totally shaven, clad in saffron, banging
on a drum and chanting the above. A couple of others from Telecom
Finland
were handing out internet drafts on diff-serv and asking money
to attend the next IETF meeting in Washington.

Now, even as I try not to take this too seriously, the utopia
promised by diff serv makes me wonder about the place for other
QoS models in the IETF's scheme of things. 

Regards,

-- 

Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A

Ph: +1-609-951-2969
Fax: +1-609-951-2499
Email: [email-masked]

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 05 Nov 1997 17:46:23 -0500

>QoS models in the IETF's scheme of things. 

No one is promising Utopia, just a reasonable compromise
between the 'soft state' maintenance required for RSVP and
traditional best effort. I'm of the opinion that if you're
looking for Utopia, you're looking in the wrong place.

I'm also of the opinion that there's room enough for
several flavors of QoS. At the moment, we just need to
hammer out the diff-serv semantics for (I hope)
preferential drop.

- paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 6 Nov 1997 07:26:14 +0200

huh, i don't remember seeing you at frankfurt airport and telecom
finland (although i don't work for them anymore) usually has had money
to pay their trips.

-- juha