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: Hemant Kanakia <[email-masked]>
Date: Sun, 01 Mar 1998 18:44:58 -0500

At 03:09 PM 3/1/98 -0800, Raj Yavatkar wrote:
>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
I echo raj's concern. IMHO, not considering 
the impact of services being offered
vis-a-vis the role of end systems 
was what ultimately made ATM's effort
to provide additional service classes 
unacceptable to a large number
of end-users. One is likely to get 
details wrong unless at least the
disussion includes issues related to
end-to-end semantics and signalling
efforts needed to implement differentiated services.

Hemant Kanakia

---

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: Yoram Bernet <[email-masked]>
Date: Sun, 1 Mar 1998 20:10:38 -0800

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.
>  
> > 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
> 
> >

---

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

of
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

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