Subject: [Diffserv] Diffserv PIB approved as Informational RFC

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jun 2002 15:08:41 +0200

-------- Original Message --------
Subject: Document Action: Framework Policy Information Base toInformational
Date: Tue, 11 Jun 2002 13:00:48 -0400
From: The IESG <[email-masked]>
To: IETF-Announce:;@zurich.ibm.com
CC: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>,[email-masked]

The IESG has approved publication of the following two Internet-Drafts
as Informational RFCs:

 o Framework Policy Information Base
	<draft-ietf-rap-frameworkpib-09.txt>
 o Differentiated Services Quality of Service Policy Information Base
      <draft-ietf-diffserv-pib-08.txt> 
 
These documents are the product of the Resource Access Protocol (RAP)
and Differentiated Services (DIFFSERV) Working Groups respectively.

The IESG contact persons are Bert Wijnen and Randy Bush.

The Working Groups had requested for standards track, but there is not
IESG consensus enough to support publication of these documents on the
standards track at this time thus we will publish them as Informational
RFCs. The IAB just held a workshop on network management and the report
on that workshop is being developed. If the results of the workshop and
subsequent discussion changes the consensus in the IESG we will then
issue a last-call to republish the documents as standards track RFCs.

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Dan Grossman <[email-masked]>
Date: Thu, 13 Jun 2002 16:13:05 -0400

I believe that with this, the working group has completed all the items on its charter.
Congratulations to all, especially the chairs and authors.

Now, at risk of creating controversy,  some hard questions:
We have completed all the items we were supposed to.  But is that enough?

In particular, we agreed, at much cost in pain, to create these PDBs, which were intended to be the
technical part of service definitions (changing the name to confuse the innocent).  Yet no PDB was
ever a working group draft, never mind being published as informational.   VW, which  (arguably) is
of the greatest commercial interest,  ran into some hard questions in working group review, and
also got hung up when its authors diverged from working group consensus surrounding RFC3246 and
RFC3248.  The draft has expired and the authors have not chosen to revise it and nobody has chosen
to pick it up.  So we don't have an end-to-end, interoperable definition of how to make a BA
achieve hard delay jitter bounds.    The relative assurances ("Olympic") PDB draft had some
disagreements and I believe has also expired.   Ditto the bulk transport PDB.   Has the group
completely lost interest in PDBs, preferring (to coin a metaphor) a bin full of disassembled parts
to a usable widget?  Or are the problems they expose too hard or too controversial?

Yoram's Diffserv framework draft raised a large number of system issues.  Few of them were ever
adequately addressed.  The view was that these would be resolved by experimental deployment.  Yet
we've seen no report on how successfully experimental deployment addressed any of these issues,
much less specific proposals resulting from experimental deployments.   In particular, there has
been an assumption that there would be a bandwidth broker that would ensure adequate capacity along
all hops in a DS-domain, even in the face of route flaps.    We've all seen journal and conference
papers on various ideas for how such a thing might work.  Yet except (arguably) for the PIB, the
whole subject was declared out-of-scope for the WG, and there has been no progress (at least that
I'm aware of) on another IETF working group activity that would address bandwidth reservations
(although one could argue that RFC3270 might indirectly be a response to this problem).

Finally, it was intended that RFC 2474 and RFC 2475 be updated after a decent interval and taken to
draft.  They were published in December, 1998, or three-and-one-half years ago.   Is it the view of
the group that there has not been enough deployment experience, that deployment experience has been
inconclusive, or that we've all lost interest?

In short, have we tacitly agreed to (in the words of the late Sen. Aiken)  "declare victory and go
home", leaving a partially complete system specification, riddled with holes and built on a
foundation of dubious soundness?  Or are we taking a breather before finishing the job?

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 13 Jun 2002 14:23:27 -0700

Dan,

You do have to consider whether these "hard questions" are best
answered by an IETF working group. It seems that the next steps
require deployment experience not more standards. There is
a working group, NSIS, that is looking at developing some
signaling that may or may not be useful for diffserv-based
services that require signaling.

As for PDBs, Brian and I passed the bulk handling PDB on for its
next revision to be done by Roland Bless and Klaus Wehrle. They
are renaming it to Lower Effort PDB and did send us a revision
last week. As the WG is closing this can be submitted as
an individual draft, thought discussion should probably take
place on this list. For VW or a jitter delay bounded PDB, my
original co-authors and I have done quite a bit of work to
define such a PDB and have also worked with someone else
on provisioning approaches. We don't currently see a reason to
take this intellectual property to the IETF. If there's truly
commercial interest, we shall see.

Although it has been 3.5 years since RFCs 2474&5 were published,
it doesn't seem like there's been enough public interoperability
work or public commerical deployment to warrant a rewrite. Do
you think there has been and that we are ignoring it?

Diffserv queuing is available in a wide range of routers, but services
seem to have been slow to deploy. I would think this is at least
in part a result of changes in the economy. A crucial component
that seems not to have gotten the required attention is classification
or filtering, and that might slow deployment also.

You correctly note that there are difficult problems that remain in
diffserv, but it's not clear that they can be solved in an IETF WG.
So, I would say that we are taking a breather before finishing the
job and further that the breather is required so we can get some
experience.

	Kathie

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jun 2002 13:24:39 +0200

I concur with Kathie. I think we're at a stage where further
design by committee is not likely to be useful - we need operators
to take what exists and try to build services with it (and that
means, IMHO, very simple service models, with minimal additional traffic
engineering to support service differentiation).

I do expect 3G systems to develop some degree of signalling in support
of diffserv, but that will either get standardised in NSIS or will
be done as a separate exercise.

     Brian

---

From: Dan Grossman <[email-masked]>
Date: Fri, 14 Jun 2002 17:29:43 -0400

Kathie,
Comments inline

Kathleen Nichols wrote:

> require deployment experience not more standards.

Actually, I was quite careful about what I asked the group to consider and why.  I wonder
if the lack of deployment experience might not result, in part, from  our work  not being
complete enough to deploy.

> There is

Yes, I'm following NSIS.  However, signalling is necessary but not sufficient.

> place on this list.

Good, I suppose, although I recollect that the need for such a PDB was controversial at
best.  I was among those who did not appreciate the need for such a PDB.  'twould be a pity
if that were the only one.

> For VW or a jitter delay bounded PDB, my

My perception was that many people believed that Diffserv would allow delay-jitter
sensitive telephony, video and multimedia application flows to be aggregated and
transported over a stateless core.  This was believed by many to be _the_ principal
application of Diffserv. One metric by which we might measure whether the working group was
successful was whether the working group's output describes how to build interoperable
implementations that do that.   I think it fair to argue that since we don't have such an
RFC (or RFCs), then by this measure we have failed.    Interoperability, incidentally, does
implicate section 10 of RFC 2026.

> you think there has been and that we are ignoring it?

There are a lot of claimed implementations.  Whether these are substantive or not may be
another question.  I suppose we won't know until there's be a call for implementation
reports.

> in part a result of changes in the economy.

In part, sure.

> A crucial component

I'm certainly aware of routers with sophisticated classification and filtering engines.
I'm also aware of several standard silicon components that do high speed classification and
filtering.  Besides, one of the important claims of Diffserv was supposed to be that since
classification/filtering is not needed in the core, very high speed
classification/filtering would not be needed.

Perhaps you're thinking about something beyond the kind of 5-tuple classification that we
discussed in the Model and elsewhere?

> job and further that the breather is required so we can get some

I think that addresses my question.  The question back to you is "until when"?

>         Kathie

Dan

---

From: Kathleen Nichols <[email-masked]>
Date: Sun, 16 Jun 2002 17:29:43 -0700

> complete enough to deploy.

If by "our work" you mean the IETF Diffserv WG, then I'm still
not convinced that we need more IETF work at this time. If
by "our work" you mean the Internet community in the tradition
of running code, then I agree that more work is needed, but
we are in a chicken-and-egg situation, perhaps exacerbated
by the fall-out amoung service providers.

...(non-issue deleted)
> if that were the only one.

We heard from a number of enterprise operators and someone
who sells to them (Yoram Bernet when he was a Microsoft)
as well as a couple of service providers that this was
interesting. It isn't for everyone, but I expect no PDB
will be.

....(my stuff deleted)
> application of Diffserv. 

So, I'm slightly astounded at this. This is where I put a lot
of technical time myself, but I heard early on in this process
(well before there was a diffserv WG) that many SPs didn't
even have this on their radar but just wanted some rough
differentiation, the kind of thing you can do with multiple
RR queues. You might take a look at the minutes of Brian's
original BoF. 

If someone knocks on my door with real interest in deploying a
delay-jitter sensitive PDB, I answer.

...(my stuff deleted)
> another question.  I suppose we won't know until there's be a call for implementation reports.
> 

Well, we have asked for this several times. Look at the diffserv
mailing list and meeting minutes. 
...(previous stuff deleted for brevity and not really an issue)
> discussed in the Model and elsewhere?
Perhaps I am. I called out two kinds of classifiers in
the pre-WG strawman, a DSCP classifier and a multiple
field classifier. The common 5-tuple was given as
an *example* of the latter, not the end-all. Multiple
fields was just that. Yes, I know some routers have
implemented this, but perhaps not enough or perhaps
it has not been made easy to set these up.
> I think that addresses my question.  The question back to you is "until when"?

I think you need to address that question to our AD. I'm not
sure what event would be considered the appropriate one
to start a new WG, though I heard in NSIS that they wanted
to take another stab at defining "quality of service classes"
so maybe the charter is going to be changed.

	Kathie

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 24 Jun 2002 22:37:25 +0200

[...]
> so maybe the charter is going to be changed.

Being active in NSIS, we basically ruled service definitions and 
specifications out of scope. I think the service definition is partly too 
difficult and on the other hand a service providers differentiater to offer 
the service markets want.

I feel it is not the task of the IETF to define it, even so I think a small 
number of basic PDB would help first deployments.

Marcus

> Archive:
> http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist
> .html
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

---

From: Dan Grossman <[email-masked]>
Date: Mon, 24 Jun 2002 17:27:11 -0400

We _already_ have service definitions ( RFC 2211 and RFC 2212).  A small number of
additional ones  would be useful, but I agree that a signalling WG is not the place to be
defining them.

My point was that the Diffserv work is complete enough to confuse the innocent,  but not
complete enough to be useful.     We have not defined any end-to-end (or even edge-to-edge)
services... er.... behaviors, much less the complete set of mechanisms to offer them or
even a sound architectural framework.  I don't think that NSIS can or should be expected to
resolve all that.

There may be some cause for hope that the NSIS work will ultimately provide much of the
needed mechanism to allow capacity reservation.  It may even fill in some of the nagging
holes in the Diffserv architecture (for example, the ability to nail a path,  mechanisms to
manage DSCP mappings between DS domains, and ability to discover what services... er...
PDBs...  might be available between two or more hosts).

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jun 2002 09:49:10 +0200

> even a sound architectural framework.  I don't think that NSIS can or should be expected to

That is really work for a trade association, not for the IETF, imho.

> needed mechanism to allow capacity reservation.  

You're begging the question of whether that is an appropriate mechanism for the Internet.

> It may even fill in some of the nagging
> holes in the Diffserv architecture (for example, the ability to nail a path,

Again, begging the question.

> mechanisms to
> manage DSCP mappings between DS domains, 

Again, trade association work.

> and ability to discover what services... er...

Unclear that this is soluble even in principle.

Hence, it's my view that there is no work item that is both mature
enough and suitable for IETF action.

   Brian

---

From: Nguyen Thi Mai Trang <[email-masked]>
Date: Tue, 25 Jun 2002 20:21:15 +0200

Hi everybody,

I read this mail session and find that the problem you rasied can be solved by my actual work:

http://www.ietf.org/internet-drafts/draft-nguyen-rap-cops-sls-02.txt
and more illustrations in "COPS-SLS: A service level negotiation for the Internet",
Communication Magazine, May 2002

I agree with Brian that service definition and DSCP mapping between domains may be work for a
trade association, not for the IETF. Each provider can build their services and choose a DSCP
mapping as they want. However, a protocol to make this mapping automatic, check the
interoperablility and negotiate for a end-to-end (or in general from one point to another point
in the network) service level is necessary and interesting for IETF, imho. Each DS domain can
be built and managed independently with their own policies and service definitions. COPS-SLS
can be used to hind the detail implementation and give an interoperability between
domains/sub-domains not only for Diffserv but also potentially other QoS technologies.

Maybe this is not the place to discuss the detail of this protocol but I hope that this work
can give a contribution for the deployment of Diffserv in large scale later. If you are
interested in this work, please mail to my personal email or discuss in an appropriate mailing
list (I don't know which list because this is an individual draft).
Regards,

Mai Trang

--
----------------------------------------------------
Nguyen Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Dept. INFRES - Bur. C234-4
46 Rue Barrault - 75013 Paris
Tel: 01 45 81 74 61 - Fax : 01 45 81 31 19
email : [email-masked]

---

From: Dan Grossman <[email-masked]>
Date: Tue, 25 Jun 2002 16:42:11 -0400

> That is really work for a trade association, not for the IETF, imho.

Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement
there is a statement that the IETF will defer technical work to a trade association?  Especially
since the Diffserv WG had consensus to start work on PDBs (after  jumping through hoops to throw
off this canard that such work is non-technical),  published several necessary-but-not-sufficient
RFCs on mechanism to support PDBs, and did the easy part of an architecture framework.   Do you
have a trade association in mind?   And if you do, why do you feel that they are more qualified
than the IETF to address the hard questions that the Diffserv working group chose not to address?

> You're begging the question of whether that is an appropriate mechanism for the Internet.

I believe that that is in NSIS' charter.  And in any event, this is a tired debate.  There is a
significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth
reservations to support telephony and multimedia services.

> Again, begging the question.

As was pointed out many years ago in the framework draft, nailed up paths are a necessary
mechanism for supporting QoS guarantees.  I am mildly hopeful that NSIS will provide that bit of
machinery in their protocols.

> Again, trade association work.

So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have
been done by a trade association?   Again, I'm mildly hopeful that the NSIS protocol(s) will
prove helpful in this regard.

> Unclear that this is soluble even in principle.

I'm personally not sure whether this is a routing problem or a signalling problem or both, but am
sure that there is at least one (albeit perhaps sub-optimal) solution.

> enough and suitable for IETF action.

Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a
degree of maturity for them.  Equally unfortunately, they are at best necessary but not
sufficient to actually providing useful services, even within a Diffserv domain, much less
between domains.  Worse, there is a perception -- which neither the Diffserv working group nor
the IESG has acted to counter -- that they actually are sufficient to do anything useful.   This,
IMHO, has been a disservice to the community.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 25 Jun 2002 23:04:07 +0100 (BST)

On Tue, 25 Jun 2002, Dan Grossman wrote:

> there is a statement that the IETF will defer technical work to a trade association?

Wait a minute. Why is the IETF not a trade association?

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2002 09:52:21 +0200

> Wait a minute. Why is the IETF not a trade association?

Trade associations are carefully constituted so that they can discuss matters
touching on business issues without infringing anti-trust laws. The IETF
isn't one.

There may well be some technical work (see Mai Trang's message) but we
have to stay away from business issues.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2002 13:38:30 +0200

> than the IETF to address the hard questions that the Diffserv working group chose not to address?

We may be disagreeing about the exact boundary between technical and business issues - but
see my earlier comment on Mai Trang's note - I agree there is scope for some signalling work.
I don't know which trade association - all I know is that the IETF isn't suitable for the
discussion of business practices.

> reservations to support telephony and multimedia services.

Yes, there is. That's exactly what I mean. But I don't think this list is the place
to debate it. As you say, if it is an IETF issue it's over in NSIS.

> machinery in their protocols.

Yes, but you are still begging the question of whether QOS guarantees are a 
reasonable goal. This is also over in NSIS.
> prove helpful in this regard.

No, what I meant is that before we can invent a technical solution we need to
have some idea of the requirements, and those are currently hidden in secret bilateral
agreements. You're also assuming that some sort of dynamic mechanism is needed; my
assumption is that static mechanisms will suffice initially, for which no
signaling is needed.
> IMHO, has been a disservice to the community.

Diffserv is only now getting shipped and we only recently finalised the MIB and PIB.
I think it's way too soon to make judgements about usefulness, but if you want a
statement of my belief, it's this: We have done what we set out to do, i.e. define
mechanisms for simple, stateless, scaleable, manageable class-of-service support 
that require only static configuration and no signaling. This is entirely deployable
as-is by ISPs and enterprises that want to provide simple service differentiation.

For what lies beyond that, see RFC 2990. I agree that we've made little progress
on the issues raised in that document, but that doesn't prevent deployment of
diffserv in its intended (very simple) role.

OK, enough philosophy for this mailing list. People who believe that NSIS is not doing
everything necessary should write to NSIS or to the Transport Area Directors.

    Brian

---

From: Dan Grossman <[email-masked]>
Date: Wed, 26 Jun 2002 11:52:39 -0400

Brian E Carpenter wrote:
<snip>

> discussion of business practices.

I'm sorry to be blunt, but this is a red herring.  Nobody is proposing to talk about business
practices.   The IETF and other bodies have been producing service definitions for years without having
to get into business practices (c.f.,  the aforementioned RFC 2211 and 2212).  The Diffserv working
group nonetheless chose to perform some interesting semantic contortions to avoid any perception that
it might be working on business practices.   Nobody is proposing that we should.  The problem remains:
in order to have anything other than best effort services in the Internet,
end-to-end/end-to-edge/edge-to-edge behaviors must be defined and the mechanisms to support them --
including between adminstrative domains --  specified.  We added an item to the WG charter to do that,
and then failed to do so.

> to debate it. As you say, if it is an IETF issue it's over in NSIS.

I partially agree, but think that it is necessary that the collective experience of the WG be drawn in
to that discussion.  In particular, the framework draft, which exposed a number of what are now NSIS
issues,  has long since expired.  Memories of people on this list may be needed to inform the
discussion in NSIS.

> agreements.

Bilateral agreements don't scale.

> You're also assuming that some sort of dynamic mechanism is needed; my

Static mechanisms don't scale.

> <snip>.
> as-is by ISPs and enterprises that want to provide simple service differentiation

I think we can debate simple, scaleable and manageable.   I frankly think that with all the issues,
there are grave doubts that it is deployable, but we shall see.  I do note that routers have been
shipping for at least two years that claim to do Diffserv, yet we don't see broad scale deployment.
And finally, the folks in the wireless and cable industries who think they see a use for Diffserv
aren't thinking simple service differentiation... they're thinking telephony and multimedia.

> .

Where do we say that's what we intended?   Honestly, if the intent is only "simple service
differentiation", then a Diffserv applicability statement is needed to state this, because that's not
what some elements of the community expect.

> everything necessary should write to NSIS or to the Transport Area Directors.

I believe this is the Diffserv standardization list.   This discussion relates directly to the work of
the Diffserv WG and the history, current state and future needs of Diffserv standardization.  I also
assume that the Transport ADs are listening and hope they'll appreciate the concerns raised.

But I do need to send a few words to the NSIS list concerning their requirments draft, as well.

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 26 Jun 2002 09:53:13 -0700

>>>Dan Grossman wrote:
....
>>machinery in their protocols.

I'm not sure what you two mean by "nailed up paths", but I do
NOT believe this is "necessary" to support QoS guarantees. Are
you assuming you'll assign one path and it will have zero
probability of failure? What kind of guarantees are you looking
at and what paths across a domain *won't* supply them? I suggest
you approach the problem from that end, rather than thinking you
must prefer some path that has the least delay by 20 nanoseconds.

By the way, using diffserv for cable data networks and wireless
networks is rather different than using diffserv for a more
mesh-y network cloud. What those folks are actually doing is
creating PDBs that apply across their very specific network
topologies.

	Kathie

---

From: Dan Grossman <[email-masked]>
Date: Wed, 26 Jun 2002 14:05:51 -0400

> must prefer some path that has the least delay by 20 nanoseconds.

Kathie,
I think you and I started to have this conversation once.  The problem is what happens to BAs in a
route flap, especially for VW-type PDBs.   Particularly since we assume that capacity for these kinds
of flows is allocated on a longer timescale than the lifetime of the flow (no per-flow signalling),
how does the network ensure that there are adequate resources along the new path?  If there are hard
upper bounds on delay [jitter], what prevents that bound from being exceeded during the route flap?
If the new path crosses a different set of DS-domain boundaries, what's to ensure that the same PHBs
are supported,  the correct DSCP mappings can be performed, and any other DS-edge functions performed
correctly?

The framework draft had some other, related, issues that escape me right now... and my copy got buried
somewhere when they moved my office.

Sometimes it best to just lock down the path and accept the possibility of a hard failure to meet the
SLS, than to have the SLS fail to be met in a transient fashion.

> creating PDBs that apply across their very specific network

I've gotten out of touch with the wireless folks.  The cable folks actually talk about using Diffserv
across their backbones, which are meshy (see
http://www.packetcable.com/specs/pkt-sp-iqos-i01-001128.pdf), although I think most of them now
understand the limitations of Diffserv and are either doing MPLS backbones or running their VoIP
traffic over ATM.

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2002 09:50:54 +0200

I was tempted to continue the discussion with Dan, but then decided
to put my WG Chair hat on and slap myself over the wrist for discussing
non-charter items. We're on a fairly deep disagreement here... I will
respond to Dan over on the diffserv-interest list, to avoid further
filling the 3000+ inboxes connected to this list.

   Brian

---

From: Simon Leinen <[email-masked]>
Date: 27 Jun 2002 13:08:47 +0200

>>>>> On Tue, 25 Jun 2002 16:42:11 -0400, Dan Grossman <[email-masked]> said:
> So RFC2836 (which is necessary but not sufficient to the solution to
> the problem) should have been done by a trade association? [...]

Gee, sometimes it's hard to follow you people when one doesn't know
all RFC numbers by heart... fortunately I have an RFC index handy
(http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/mini-index.html)

By the way, RFC 2836 has been superseded by RFC 3140
("Per Hop Behaviour Identification Codes").
-- 
Simon.