Subject: [Diffserv-interest] Re: [Diffserv] Hard questions (was: Diffserv PIB approved as InformationalRFC)

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2002 11:22:04 +0200

[also switched to differv-interest]

Dan Grossman wrote:
...
> 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.

And sometimes it isn't. This sounds like a decision that will be taken by individual
operators, like many other traffic engineering decisions. I doubt if there's much to be
said in general about this. It seems to argue that traffic engineering tools need to have
DSCP value as a parameter, for operators that want to pin routes per DSCP.

  Brian

_______________________________________________
Diffserv-interest mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2002 11:13:21 +0200

[switched to diffserv-interest]

Dan Grossman wrote:
> 
> Brian E Carpenter wrote:
> <snip>
> 
> >
> >
> > 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.
> 
> 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.

Well, we defined what a PDB is, but then we discovered the lack of both mathematical
and experimental understanding of how to characterise PDBs, and we still haven't made
much progress on that. That's why we haven't seen any PDBs yet that are ripe for
publication. See below for some comments on end2end.
> 
> >
> >
> > >
> > > >
> > > >
> > > > >
> > > > > There may be some cause for hope that the NSIS work will ultimately provide much of the
> > > > > needed mechanism to allow capacity reservation.
> > > >
> > > > 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.
> >
> > 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.
> 
> 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.

That should certainly happen. But frankly the framework draft was highly speculative
and the lack of math or experiment still keeps us in speculation mode.
> 
> >
> > > >
> > > > > mechanisms to
> > > > > manage DSCP mappings between DS domains,
> > > >
> > > > 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.
> >
> > 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.
> 
> Bilateral agreements don't scale.

Actually, I think they do. They scale like o(N) where N is the number of ISPs that a
given ISP is connected to, and that is quite tractable. What they don't do is associate 
(in the mathematical sense)- concatenated bilats don't create a multilat. That's where
constructing e2e behaviours gets difficult. I believe that we also don't understand
yet whether PDBs are associative. That's why the whole question of end2end is still
open.

> 
> > 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.
> 
> Static mechanisms don't scale.

Again, I think they do. In fact, if a given ISP (or enterprise network)
operates a few (3 or 4) classes of service, they can have a pretty much standard
and invariant router config in a central management database; the incremental
config for diffserv will be pretty small. 

If you try to run a very large number of classes or do dynamic resource 
allocation, things don't scale (and you certainly need signalling). My concern
is that this topic isn't well enough understood yet for committee work.

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

True, but it's only now that we have a MIB and begin to see operating systems capable
of classifying traffic at source. I think enterprise networks will be the first to adopt
diffserv, and I think it will be a stealth technology in ISPs - there is no reason you will
know it's there, as with any other traffic engineering mechanisms.

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

Indeed. And I think this is where we are seeing people most keen on adding
signalling and per-flow handling. I don't fully understand this, because telephone
systems have always been provisioned on a 0.1 or 0.2 Erlang basis, and I don't
fully understand why VoIP or multimedia over IP can't be statistically provisioned
too. It's exactly at busy hour that you need diffserv, so if you provision the
traffic aggregate for VoIP for the busy hour, it's hard to see how signalling and 
dynamic allocation will create bandwidth out of thin air. There is a tricky issue
of how you deal with land line or base station outages, or with extreme hot spots
(emergency situations or traffic jams) but we should be able to solve that
at an aggregate level, not per-call. So my conclusion is that the telephony
community in particular is over-constraining the solution by sticking with
notions of per-call QOS.

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

I'm thinking back to the BOF in April 1997 and the early meetings where 
the diffserv direction was set. The diffserv charter starts:

  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. 

and I believe this text has been there from the beginning; it was certainly
there in February 1998 from my records. Also, RFC 2474 starts by saying:

   Differentiated services enhancements to the Internet protocol are
   intended to enable scalable service discrimination in the Internet
   without the need for per-flow state and signaling at every hop.  

(That carefully doesn't exclude state and signalling totally, but there
is nothing in 2474 or 2475 that implies either flow state or signalling.)

So what can we say in an applicability statement in addition to
"read the Abstract of RFC 2474"?
> 
> >
> >
> > 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.
> 
> 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.

Certainly, because if NSIS does produce a new protocol, it needs to be able to handle
whatever we discover about dynamic resource allocation for diffserv in the future.

    Brian

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 27 Jun 2002 21:54:25 +0200

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

We define also PDBs but with our very specific DiffServ implementation by 
fixing quite a number of parameters before even think about a PDB. We found 
that the openness of the DiffServ specs are a hindrence in defining crisp 
PDBs, therefore we can only do propriatary ones, and these are complicated 
and not very crisp as well.

Marcus

--------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jun 2002 13:47:29 +0200

> and not very crisp as well.

That's an interesting comment. Can you be more specific? 

By the way, this isn't unusual in the IETF. We often have to fix basic behaviour
and leave many paramters free, because that is all we can get consensus on
until several years of deployment has gone by. Another (related) example is
the IPv6 flow label, where we are only now defining even its basic rules.

   Brian

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 28 Jun 2002 14:55:34 +0200

--On Freitag, 28. Juni 2002 13:47 +0200 Brian E Carpenter 
<[email-masked]> wrote:

>> fixing quite a number of parameters before even think about a PDB. We
>> found that the openness of the DiffServ specs are a hindrence in
>> defining crisp PDBs, therefore we can only do propriatary ones, and
>> these are complicated and not very crisp as well.
>
> By the way, this isn't unusual in the IETF. We often have to fix basic
> behaviour and leave many paramters free, because that is all we can get
> consensus on until several years of deployment has gone by. Another
> (related) example is the IPv6 flow label, where we are only now defining
> even its basic rules.
>
>    Brian

Brian,

I completely understand that. I even think since the definition of crisp 
PDB is very complicated, it adds value to solution, which people don't just 
want to give away for standardization.

E.g., we the did the following PDB:
- p2p
- guaranteed throughput no loss for packets within CIR profile
- maximum delay bound

We defined configuration rules for our DiffServ implementation. And we are 
sure this PDB is not implementable with some of the other DiffServ 
implementations (even if they conform to the standard).

>From the process we actually first looked into our implementation and then 
tried to figure out how the PDB looks like.

On the other hand, for the community and for helping the deployment, a 
small set of PDBs (even if they are very loose without stringent 
guarantees) would help. whether we are able to agree on them is a different 
question, because some of the people are not able to implement them with 
they DiffServ nodes.

Marcus

---

From: Dan Grossman <[email-masked]>
Date: Fri, 28 Jun 2002 15:42:51 -0400

All this is very discouraging, perhaps indicative of a massive failure of the
Diffserv standardization exercise.  It also raises questions as to whether the
historical accomodation between the IETF standarization process and the business
needs of its participants' employers hasn't in fact broken down.

> E.g., we the did the following PDB:

Can you explain this one?

> implementations (even if they conform to the standard).

Is the problem that PHBs are underspecified?   Or is the issue in classifiers,
conditioners, queuing systems and/or schedulers?

> tried to figure out how the PDB looks like.

Can you explain a bit more, and, in particular, were you looking at quantifiable
parameters only, or were there also temporal or other behaviors that were
affected?

> question, because some of the people are not able to implement them with

If this is true, then we have created a bunch of standards that don't advance
interoperability, and thus have failed.  I knew that there were problems, but
didn't realize that it was this bad.   Is there anything that can be learned
from this?