Re: Hard questions (was: Diffserv PIB approved as Informational RFC)

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

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.

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

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

Yes, but you are still begging the question of whether QOS guarantees are a 
reasonable goal. This is also over in NSIS.
> 
> >
> >
> > > 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. 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.
> 
> >
> >
> > > and ability to discover what services... er...
> > > PDBs...  might be available between two or more hosts).
> >
> > 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.
> 
> >
> >
> > Hence, it's my view that there is no work item that is both mature
> > 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.

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

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