Subject: Re: [Diffserv-interest] Re: [Diffserv] Hard questions (was:Diffserv PIB approved asInformational RFC)

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Jul 2002 15:52:34 +0200

I don't understand the doom and gloom. We set out to define domain-based service
differentiation, because that's what users and service providers both told us
they wanted. That's what we did. I count this as a success.

It's no news that end-to-end QOS is a hard problem. But that wasn't the problem
we tried to solve.

It's a fact that some parts of the industry, that only started coming to
the IETF since the diffserv effort began, appear to believe that e2e QOS is
a simple matter that should have been fixed long ago. I haven't believed
this since I read Kleinrock's two volumes on queueing theory many years
ago. I find the phrase "e2e QOS guarantees" to be self-contradicting when
applied to the Internet. Expecting complete consistency between alternative
implementations of the "same" PDB isn't reasonable, but it doesn't matter
in terms of interoperability. Everything is statistical anyway.

   Brian

Dan Grossman wrote:
> 
> >
> 
> 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.
> 
> > 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
> 
> Can you explain this one?
> 
> >
> > - 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).
> 
> Is the problem that PHBs are underspecified?   Or is the issue in classifiers,
> conditioners, queuing systems and/or schedulers?
> 
> >
> >
> > >From the process we actually first looked into our implementation and then
> > 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?
> 
> >
> >
> > 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.
> 
> 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?

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