Subject: Differentiated Services working group

From: Scott Bradner <[email-masked]>
Date: Sun, 1 Mar 1998 14:45:15 -0500 (EST)

A note from an AD

Since the presentations in the Integrated Services (intserv) working group
session in the Munich IETF meeting there has been a lively discussion about
many possibilities and challenges of being able to provide some level of
differentiated services on TCP/IP networks including the Internet.  Most of
these discussions have taken place on the interv mailing list (archive at
ftp://ftp.isi.edu/int-serv/int-serv.mail).

A number of the proposals that arose from these discussions were presented
at the Integrated Services session at the DC IETF meeting.  At the end of
that meeting I asked for advice from the attendees on what, if any, future
efforts should be undertaken within the IETF in the area of differentiated
services for TCP/IP networks.  Dozens of people sought me out to give me
advice or sent me email with their opinions.

In response to the opinions received the transport area directors (Allyn
Romanow and I) decided to charter a new working group within the Transport
Area to explore these topics. The Differentiated Services (difserv) working
group was approved by the IESG last Thursday.  Kathleen Nichols and Brian
Carpenter are co-chairs of the working group.

One thing that was clear from the flurry of postings on the intserv mailing
list was that a working group would need to have some focus of discussion
if any progress was going to be made.   This working group will use
draft-nichols-dsopdef-00.txt as the basis for their initial discussions.
This Internet draft is the result of a design team effort and is to be seen
as the starting point of working group discussion rather than as a working
group product.  The final documents produced by the working group may or
may not resemble this Internet-draft.

The schedule for the working group is quite aggressive but I feel that this
effort to expand the repertoire of available QoS tools is quite important
to the potential of the Internet and trust that the working group will
proceed expeditiously to define the required technology.

Scott Bradner - Transport Area co-AD

---------------------------------------------------------------------------
Differentiated Services (diffserv)

Last Modified: 16-Feb-98

Chair(s):

Brian Carpenter <[email-masked]>
Kathleen Nichols <[email-masked]>

Transport Area Director(s):

Scott Bradner <[email-masked]>
Allyn Romanow <[email-masked]>

Transport Area Advisor:

Scott Bradner <[email-masked]>

Mailing Lists:

General Discussion:  [email-masked]
To Subscribe:        mail to [email-masked]
                           in body: subscribe diff-serv
Browse archive:
                     http://www-nrg.ee.lbl.gov/diff-serv-arch/
Retrieve archive:
                     ftp://ftp.ee.lbl.gov/diff-serv-arch/

Description of Working Group:

There is a clear need for relatively simple and coarse
methods of providing differentiated classes of service for
Internet traffic, to support various types of applications,
and specific business requirements. The differentiated services approach to
providing quality of service in networks employs a small, well-
defined set of building blocks from which a variety of services may
be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the
IPv6 Traffic Class octet, is used to mark a packet to receive a particular
forwarding treatment, or per-hop behavior, at each network node. A common
understanding about the use and interpretation of this bit-pattern is
required for inter-domain use, multi-vendor interoperability, and
consistent reasoning about expected service behaviors in a network. Thus,
the Working Group will standardize a common layout to be used for both
octets, called the 'DS byte'. A standards-track document will be produced
that will define the general use of fields within the DS byte (superseding
the IPv4 TOS octet definitions of RFC 1349). The Working Group will also
assign specific per-hop behaviors to a small number of particular patterns
or 'code-points' of the DS byte. The standardized code-points will only
apply to per-hop behaviors already in widespread common usage within the
global internet, e.g, the forwarding treatment received by best-effort
traffic.

In addition to the standards-track specification document, an informational
framework document will be produced. The framework document will define
the differentiated services architecture and a common language for
differentiated services. Example uses and services will be described.

Another goal of the WG is to experiment with other per-hop behaviors that
can be used to produce additional services. These will be documented in
internet drafts. It will be decided whether these additional code-points and
per-hop behaviors should be specified in experimental RFCs or should become
standardized. The WG will also investigate the additional components
necessary to support differentiated services, including such traffic
conditioners as traffic shapers and packet markers that could be used at
the boundaries of networks. The WG may also define mechanisms such as
LDAP schemata to map user service profiles into differentiated
services at the network boundary. Later documents will cover these
issues.

The group will analyze related security threats, especially theft
of service or denial of service attacks, and suggest counter-measures.

The group will not work on mechanisms for the identification
of individual traffic flows within the network, or on
signalling mechanisms to support the marking of packets.

Goals and Milestones:

Feb 98: Strawman version of TOS/traffic class spec (standards track)

Mar-Apr 98: Meet at LA IETF to review strawman spec
        Initial discussions and outline for framework doc (FYI)

Apr 98: Revised drafts of spec and framework

Jun 98: Interim meeting to review spec and framework docs
        Further revision and WG last call

Jul 98: Submit drafts to IESG

Aug 98: Meet at Chicago IETF to discuss boundary mechanisms
        and traffic conditioners

Oct 98: Publish drafts on boundary mechanisms and traffic
        conditioners

Dec 98: Meet at IETF to finalise boundary mechanisms and traffic
        conditioners documents

---

From: Jim Fleming <[email-masked]>
Date: Sun, 1 Mar 1998 14:34:42 -0600

You are welcome to discuss that in the context of IPv8
which was not mentioned in the previous message. QoS is
an important focal point for IPv8 which is not intended
to be an end-to-end protocol. In an IPv4/8 world, you
have the following arrangement.

User--IPv4'--ISP--IPv8--IPv4/6 CORE--IPv8--ISP--IPv4'--User

The IPv4' subnets use 10.x.x.x addressing.
The IPv4/6 CORE can be anything, and eventually is phased
out as the IPv8 mesh develops.

The ISPs sell the services that the users perceive to
have value. Some of those services are oriented toward QoS.
I am not sure if these are "Differentiated Services" but
the basic approach is to allow ISPs to prosper by supporting
various services that they offer users.

In my opinion, it is important that ISPs are able
to select these services and deploy them with the knowledge
that the "IPv8 Service Network" was designed with this
in mind. This avoids the problem where services are
designed to the least common denominator, which means
that often, 98% of the users suffer.

Jim Fleming
Unir Corporation

---

From: Scott Bradner <[email-masked]>
Date: Sun, 1 Mar 1998 18:25:19 -0500 (EST)

> is the chater still open for further discussion?  

not at this time

Scott

---

From: Kenneth_Peirce/MW/US/[email-masked]
Date: Sun, 1 Mar 1998 19:15:57 -0600

Does this mean that the adaptive applications bof will not result
in a WG after all?

---

From: Scott Bradner <[email-masked]>
Date: Sun, 1 Mar 1998 20:27:14 -0500 (EST)

--
--

huh?

the adaptive aps bof is unrelated to the diff-serv effort

Scott

---

From: Scott Bradner <[email-masked]>
Date: Sun, 1 Mar 1998 23:03:05 -0500 (EST)

Let me try again, what I wanted to say was that the decision to form the
diff-serv WG should not be seen to imply anything about the
future of adaptive apps.

sorry for the confusion

Scott

---

From: Borje Ohlman <[email-masked]>
Date: Mon, 02 Mar 1998 11:36:37 +0100

I would like to make the following points:

1.
I completely agree that we should construct diff-serv in such a way that it
works without any need for signalling to or from end-systems.

2.
I also agree with those claiming that declaring end-system interactions out of
scope of the diff-serv work seems short sighted. I also think that excluding
end-system interactions from the discussion might produce a result that will
not seem well considered in the long run.

3.
One example of where the discussion of end-system interactions seems very
appropriate is on the issue of receiver control.
Here I want to make clear that there are (at least) two types of receiver
control. One is when the receiver is allowed to control which priority should
be set by the sender (this I agree should be left out of the discussion for
now). Another type is when the receiver feel he needs to control which priority
data has when it comes from the network onto his access link. Two reasons why
this is important. One is that it provides protection from certain types of
denial of service attacks. The other is that this is important on low bandwidth
access links, in particular for cellular IP hosts.
According to the current proposal there is no way that the receiving host can
influence the setting the TOS-bits of incoming packets

Best regards,
                Börje Ohlman

Yoram Bernet wrote:
> 
> Of course diff-serv should be usefuyl without requiring that end-systems be
> modified. However, we should make sure that, in the long run, end systems
> will be able to make use of the services offered by diff-serv. Surely we
can
> consider the requirements of end systems, without delaying the diff-serv
> efforts. After all - in the end - who will use the diff serv services? Who
> generates and consumes the traffic carried by the diff-serv networks? To
> completely exclude any end-system considerations seems short sighted.
> 
> Yoram
> 
> > -----Original Message-----
> > From: Keith McCloghrie [SMTP:[email-masked]]
> > Sent: Sunday, March 01, 1998 3:14 PM
> > To:   [email-masked]
> > Cc:   [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; Yoram Bernet
> > Subject:      Re: Differentiated Services working group
> >
> > I agree that the end2end result is important, but I think diff-serv
> > needs to be useful without requiring that all end-systems be modified.
> >
> > Keith.
> >
> > > I agree. I am concerned that the chater seems to exclude the issue of
> > > end-to-end semnatics and edge interactions. I believe, it will be
useful
> > to
> > > include a discussion of the role of end systems, how and what signaling
> > > would be used by applications to take advantage of what dif-serv
offers,
> > > and the expected end2end result.
> > >
> > > Thanks
> > > Raj
> > > At 04:52 PM 3/1/98 -0500, Scott W Brim wrote:
> > > >Scott Bradner wrote:
> > > >> Two possibilities:
> > > >>
> > > >>         There has been some discussion that RSVP could be used by
> > > >> hosts to signal QoS requests to the routers that in turn would mark
> > > >> packets to support the Differentiated Services functions.  I would
> > > >> expect that additional discussions of this could be done in the
> > > >> context of the RSVP working group.
> > > >>
> > > >>         After the Differentiated Services working group discussions
> > > >> have produced specific proposals the topic of host interaction could
> > > >> be taken up by the Differentiated Services WG or by a new WG.
> > > >>
> > > >> opinions?
> > > >>
> > > >> Scott
> > > >
> > > >Yes, but we may already agree.  The issue of what is expected in terms
> > of
> > > >edge signaling -- not the mechanisms but the expected functions --
does
> > > >have an effect on what we choose to do in diff-serv.  Some proposals
> > don't
> > > >make sense without some kind of signaling from the end system to the
> > edge
> > > >forwarders.  If edge interactions come up, in that context, we
> > shouldn't
> > > >insist that they are out of scope.
> > > >
> > > >...Scott too
> > > >--
> > > >Scott Brim    <[email-masked]>    +1.607.273.5472
> > > >
> > > >
> > >
> > > -----------------------------------------
> > >    Raj Yavatkar
> > >    Communication Architecture Lab           [email-masked]
> > >    Intel Corporation, JF3-206                     voice -- 503-264-9077
> > >    2111 NE 25th Avenue,  Hillsboro, OR 97124
> >
> > >

-- 
<pre>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Börje Ohlman                     
KK/ERA/T/NI  (Network Reference Group (NRG) @ Switchlab)
Ericsson Radio                            Tel.   +46- 8-719 3187
Dialoggatan 1  (Kungens Kurva)            Mobil. +46-70-519 3187
S-126 25 Stockholm                        Fax.   +46- 8-719 6677
Sweden

E-mail:  [email-masked]       
WWW:     http://switchlab.ericsson.se:8080/~eraboje/  <--- HAS CHANGED!!!!
              (only from within Ericsson)
Private: http://www.abc.se/~m10181

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 2 Mar 98 05:48:16 -0500

ARGH! This is an interesting discussion, but can we please restrict it to *one*
mailing list, not three? Thanks!

	Noel

---

From: [email-masked]
Date: Mon, 2 Mar 1998 10:20:52 -0800

Keith, I Agree, but we need to take into account when an end-station has
the ability and desire to participate in the end-to-end setup.  From a
scaleability point of view, the futher setup (not enforcement) can be
removed from the core the better.

/jsb

Keith McCloghrie <[email-masked]> on 03/01/98 03:13:54 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked] (James
      Binder/HQ/3Com)
Subject:  Re: Differentiated Services working group

> end-to-end semnatics and edge interactions. I believe, it will be useful
to
> would be used by applications to take advantage of what dif-serv offers,
of
> >edge signaling -- not the mechanisms but the expected functions -- does
don't
edge
> >forwarders.  If edge interactions come up, in that context, we shouldn't

---

From: [email-masked]
Date: Mon, 2 Mar 1998 10:25:24 -0800

Scott,

It should be (at least on this subject).  There were lots of presentations
and comments on this issue at the last meeting and to close on it without
full consensus does not bode well for wide adoption of this standard.
Also, It seems to me this charter was crafted without input from a number
of interested people (Raj, Yoram, myself) and may have even taken place of
the this list.
/jsb

Scott Bradner <[email-masked]> on 03/01/98 03:25:19 PM

To:   [email-masked], [email-masked], [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked] (James Binder/HQ/3Com)
Subject:  Re: Differentiated Services working group

not at this time
Scott

---

From: [email-masked]
Date: Mon, 2 Mar 1998 10:18:27 -0800

I agree with Raj and Yoram.  Also, as we move into a IPSec world, this
become all that much more important!

/jsb

Raj Yavatkar <[email-masked]> on 03/01/98 03:09:25 PM

To:   Scott W Brim <swb @Newbridge.COM>, Scott Bradner <sob @harvard.edu>
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked] (James Binder/HQ/3Com)
Subject:  Re: Differentiated Services working group

I agree. I am concerned that the chater seems to exclude the issue of
end-to-end semnatics and edge interactions. I believe, it will be useful to
include a discussion of the role of end systems, how and what signaling
would be used by applications to take advantage of what dif-serv offers,
and the expected end2end result.
is the chater still open for further discussion?
Thanks
Raj
At 04:52 PM 3/1/98 -0500, Scott W Brim wrote:
>Yes, but we may already agree.  The issue of what is expected in terms of
>have an effect on what we choose to do in diff-serv.  Some proposals don't
>make sense without some kind of signaling from the end system to the edge

---

From: [email-masked]
Date: Mon, 2 Mar 1998 10:29:37 -0800

The big question is which is the right mailing list?  This may be some of
the problems here in that the charter was crafted on one while alot of
other people were watching another.

/jsb

[email-masked] (Noel Chiappa) on 03/02/98 02:48:16 AM

To:   [email-masked], [email-masked], [email-masked]
cc:   [email-masked] (James Binder/HQ/3Com)
Subject:  RE: Differentiated Services working group

ARGH! This is an interesting discussion, but can we please restrict it to
*one*
mailing list, not three? Thanks!
     Noel

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 03 Mar 1998 07:41:11 -0500

[I have trimmed the CC: list mercifully to only diffserv
 and intserv for relevance]

My immediate, knee-jerk reaction to this (incorporating end-system
behavior and signaling into the wg charter) is that this is out of
scope for the working group, but I'll bite my tongue since I can
clearly see the benefit of the end-systems signaling the first-hop
gateway (perhaps even using RSVP) for a diffserv translation, in effect.

Therefore, I would suggest that we modify the charter to consider
incorporating this scope only *after* the base diffserv mechanics
have become more clear, in other words, further out in the diffserv
time line.

This would seem to be more productive, and satisfy the desires of
many people who are adamant to incorporate end-system signaling
to the first-hop gateway for differentiated services.

- paul (on vacation, no less)

At 08:10 PM 3/1/98 -0800, Yoram Bernet wrote:

>will be able to make use of the services offered by diff-serv. Surely we can

---

From: Greg Minshall <[email-masked]>
Date: Tue, 03 Mar 1998 12:41:41 -0800

(let's try leaving the poor IETF list out of this!)

Typically, we define a protocol as A) some bits on a wire between two systems 
(syntax), and B) how those bits influence the behavior of the receiving system 
(semantics).

Here, the *receiving* system is a router, definitely.  I.e., this is what we 
are trying to standardize on, how routers deal with packets with certain bits 
in them.

The model is that there exists a "service level agreement" between the sender 
and the receiving router (in the case where the two systems are in different 
administrative domains).  We are not definining *how* this agreement has been 
set up.  (We do *suspect*, however, that the setting up of this agreement is 
on the time scale of days rather than packets, RTTs, etc.)

Diff-serv, then, is a way of the sender indicating a service level for each of 
its sent packets, and for the receiving router to A) possibly modify the 
service level in a packet (in the case where the two systems are in different 
administrative domains), and B) provide a level of service to each packet that 
should provide end2end behavior consistent with the previously negotiated 
service level agreement.

Some other items:

1.  How do hosts indicate which of the already contracted service levels they would like for a particular packet?  Well, once they understand how the "network" is supposed to treat bits in the packet, then they can set bits appropriately.  (Just like "once routers understand how they are supposed to treat bits in the packet, they can treat the packets appropriately".)  Yes, some border device in the path of the packet may completely re-write the bits, but at least they have done their best.

2.  Border routers (on the sending side, say) may want to have some clue as to which packets should get "premium service".  There will probably be a lot of static configuration here ("at the end of the quarter, order entry gets all the premium"; "www outbound gets best effort", etc.).  But, pre-set bits in the header might help.

(3.  Yes, the IPSEC obfuscation of the port numbers is a pain.)

4.  I think the three resources "we" have to control in the network are:  short term access to the wire (latency); long term access to the wire (bandwidth); buffer utilization.  Hopefully there will be more than one bit (though whether there is actually orthogonality in the three resources is an open question, imho).

5.  Shivkumar Kalyanaraman said:
> What will be good is a control scheme which can keep the *steady state
> queueing delay* low and the steady state utilization high, while being
> able to quickly drain out transient queues. We hope to do it through
> ECN and related methods. A differentiated service class which can
> provide this (better-than-best-effort) option will be clearly
> superior. 

RED is what is trying to keep steady state queueing delay low, while leaving room for transient bursts.  (ECN is trying to help the efficiency of the network by not wasting effort in partially carrying a packet only to drop it in order to signal congestion to the end system.)  I don't think that a diff-serv class "will be clearly superior" to RED.  You need RED in any case.  However, the diff-serv class could give you a larger share of the buffer space (so, your packets don't get discarded as soon as other packets), or it could say "even if the queue is large, you go to the front".

6.  Christian (with a quote from Mike O'Dell) said:
>> i note it's asymmetric and it's very unclear how to fix that.
> Looks to me as precisely one of the points that the diff-serv WG ought
> to study.

I think this should be outside the (initial) scope of diff-serv (i think it is too hard of a problem at present).  (Though i shudder at the prospect of seeing *8* links on an HTML page:  "click here to retrieve this using gold service"; "click here to retrieve this using silver service"; ...)

Greg