Re: [Diffserv] PDB draft

[Dan Grossman <[e-mail]>]

> > 
> > However, in addition to its editorial problems, it only partly achieves its
> > goal of defining PDBs and traffic aggregates.  It leaves many unanswered
> > questions about what these things are, how they work, how they relate to the
> > work done so far, and exactly what they are good for.  
> 
> In so far as that's true, it's strictly in the IETF tradition of
> defining components rather than grand plans. Of course, we will try to
> fill in gaps in the PDB description, but see Geoff Huston's
> draft-iab-qos-01.txt for grand plan stuff. 
It's not the grand plan that's missing... it's about the PDB and traffic 
aggregate concepts... sketchy descriptions, missing linkages to RFC 2475 and 
the terminology draft, missing linkages to anything like services.
> > It also continues to
> > avoid these meta-questions as to what Diffserv is trying to accomplish, 
> 
> I think that is stated succinctly in the WG charter.
Well, ok, but our readers don't always read the charter, or care about the 
Diffserv working group.  The issue is what the Diffserv architecutre is trying 
to accomplish. I'm thinking of this draft almost as an extension of RFC 2475.  
The new concepts should similarly extend what we were trying to accomplish in 
RFC 2475.
> 
> > what
> > Diffserv is and is not useful for,  
> 
> True. The IETF generally doesn't tackle that sort of question.
> We let the network decide for itself.
>
Maybe what I'm looking for is an applicability statement.  Or a respin of RFC 
2475.   Obviously another draft. But if the intent was that Diffserv be a 
blunt instrument for solving a particular kind of scalability problem for 
providing SLAs in the Tier 1 ISPs' backbones, then we've sure failed to 
communicate that.

> >whether it's ready for prime time or a
> > research project, 
> 
> That is answered by forwarding a document to the IESG, or by vendors
> shipping code.
> 
As I've said before, we have groups like 3GPP making big assumptions that 
Diffserv is ready for prime time, just add water and get delicious 
ready-to-eat services :-)  If we're building a research vehicle, we'd better 
let them know.  And if not, we've got to get serious about nailing down a 
specification.

> > and how confident we really are that it will work.
> 
> What in the document suggests lack of confidence?

"In general, though, a PDB operates between N ingress points and 
M egress points at the DS domain boundary. Even in the degener-
ate case where N=M=1, PDB attributes are more complex than 
the definition of PHB attributes since the concatenation of the 
behavior of intermediate nodes affects the former. A complex 
case with N and M both greater than one involves splits and 
merges in the traffic path and is non-trivial to analyze. Analytic, 
simulation, and experimental work will all be necessary to under-
stand even the simplest PDBs."


> > There is a significant part of the industry -- including 3GPP -- who have come
> > to believe that Diffserv is QoS pixie dust.  
> 
> Well, given that this part of the industry produced the ETSI description of
> QOS for IP telephony, which is the purest pixie dust, I'm not going to
> worry unduly about that. Once the major router vendors ship diffserv boxes,
> we shall see what we shall see.
> 
Maybe it's because my employer thinks they have a stake in whatever 3GPP comes 
up with.  Or maybe it's because I keep on having to go through the same tired 
explanations over and over again.  But I am duly worried about this.

> > This needs to be tempered by a
> > concise, readable, understanding of what we are trying to accomplish and what
> > limitations we see.   I was looking for this draft crystallize the group's
> > intentions.  That the draft does not do this is a significant disappointment.
> 
> That wasn't the intent of the draft. The intent was to start building
> the next layer of components in the diffserv toolkit.

And it is exactly that next layer of components that should begin to meet what 
3GPP et al are looking for.  Or if not, we should say so.  Because we didn't 
provide any such guidance in our existing layer of components, and see where 
it got us: "repeat after me:    PHBs are NOT end-to-end services. PHBs are NOT 
end-to-end services. PHBs are NOT end-to-end services... AAARGH!"  I would 
like this draft to say that PDBs **are** edge-to-edge services.  If somebody 
wants to put a DS-domain in the middle of, say, a UMTS core network, then it 
will offer PDBs to whatever is on its edges.  When the Diffserv WG specifies 
PDBs, then they can be used as standardized building blocks, parameterized by 
their TCSs and attrributes.  Which means that UMTS services can be mapped onto 
them.  
> 

> 
Dan



_______________________________________________
diffserv mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/