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

[Dan Grossman <[e-mail]>]

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.

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

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

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

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

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

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

>
>
>     Brian


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