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

[Dan Grossman <[e-mail]>]

Kathie,
Comments inline

Kathleen Nichols wrote:

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

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

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

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

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

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.

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

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.

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

In part, sure.

> A crucial component
> that seems not to have gotten the required attention is classification
> or filtering, and that might slow deployment also.

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?

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

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

>
>
>         Kathie

Dan


_______________________________________________
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