Re: [Diffserv] PDB draft

Dan,

I took the opprtunity of an 11 hour plane ride to look at your comments
on the PDB draft, for which many thanks. It would be tedious for the WG to
respond in detail, since many of them are editorial and will simply
lead to text fixes. Or they are points of stylistic taste or document
organisation where the authors may prefer their version to yours. So for 
those items please wait for the next version. Let me try to pull out some
specific issues:

> A goal of the diffserv WG is to provide the firm technical 
> foundation that allows these business models to develop. 
> >> This is true only when Diffserv is used by ISPs, and when the issue is
> >> related to peering.  There are other uses of Diffserv where two domains
> >> might want to interconnect to provide service from the edge of one to the
> >> edge of the other. 

That is peering; but it's diffserv peering (or transit) which is new
and different and calls for radically different SLAs.

> Similarly, specific PDBs are intended as tools for ISPs to con-
> struct differentiated services offerings; each may choose different 
> sets of tools, or even develop their own, in order to achieve
> particular externally observable metrics. 
> >> So how are customers supposed to manage (and particularly validate) SLSs if 
> >> Diffserv is not going to define them and create MIB objects for monitoring  
> >> them?  Are vendors supposed to have different monitoring tools for every 
> >> ISP?

My personal view is that until we have some vendor specific deployment
experience, we are incapable of answering this. And there isn't going to be
a PDB MIB any time soon, since it would be a MIB for a distributed entity.

> Measurable, quantifiable, attributes are associated with each PDB
> >> I'm not convinced that this is where we've been going.  Certainly,
> >> if somebody were to try to turn the Olympic Service into a PDB, it
> >> wouldn't have measureable or quantifiable attributes.  At least not the
> >> way that AF is designed. 

I don't understand what you're saying. If AF doesn't produce statistically
quantifiable edge behavior we shouldn't have standardised it.

> A PDB's definition does not have to hold 
> for arbitrary topologies of networks, but the limits on the range of 
> applicability for a specific PDB must be clearly specified. 
> >> How invariant is invariant?  For example, if we take Anna and Jean-Yves' 
> >> work
> >> at face value, can we claim that kind of invariance for VW?

Again I don't see what you're saying. The invariance applies within
certain boundary conditions on the topology. Why do you mention VW-Charny
(which is different from VW-Jacobson, but that's another conversation)?
The same thing applies to AF too - in fact BE is probably the only
one that doesn't have topological constraints.

> When a set of related PDBs are defined using a PHB group, they 
> should be defined in the same document. This would be particu-
> >> Why did you choose to do it this way?  It would make more sense to have
> >> PDBs use a PHB or PHB group, and characterize the behavior of the PDB
> >> according to whatever attribute differentiates the members of the PHB
> >> group.

We disagree; we think it's more logical this way.

> 5.2  Rules
> 
> This section describes the rules to be followed in the creation of 
> this PDB. Rules should be distinguished with "may", "must" and 
> "should." The rules specify the edge behavior and configuration 
> >> ref RFC 2119

No. This is not a standards track document.

> If additional 
> restrictions, e.g., route pinning, are required, these must be stated.
> >> Which doesn't exist except in MPLS.

Route pinning exists wherever an ISP cares to make it exist. 

> However, in submitting a PDB specification to the 
> Diffserv WG, a PDB must also meet the test of being useful and 
> relevant. 
> >> Which leads to another meta-question about where we're going.  There seems
> >> to be an industry expectation that diffserv is the solution to the world's
> >> QoS problems.  If our intent is to meet that expectation to some extent,
> >> then this draft needs to be quite prescriptive about the content of PDB    >
> > specifications.  If we're really doing research, then we need to reset
> >> industry expectations (good luck!)  Or we need an explicit way of dividing
> >> the Diffserv world into a research track and a standard track.
> 
I hope we're not doing research although as noted above we  severely lack
deployment experience. But I thought we *were* being prescriptive about
the content of  specs....

> 7.0  Reference Per-Domain Behaviors
> >> Shouldn't we put these into  different drafts?

....which is exactly why we want the reference PDBs here, to get some
precision into this document. (RFC 2474 does the same by defining
the BE and CS PHBs.)

> A Bulk Handling (BH) PDB is for sending extremely non-critical 
> traffic across a diffserv network. There should be an expectation 
> that these packets may be delayed or dropped when other traffic is 
> present.
> >> Is this related to the less-than-best effort PHB that we discussed for sev-
> >> eral meetings? I thought there was no consensus to proceed on that.

This is the authors' view of how LBE functionality can be delivered
without wasting a code point on an LBE PHB. You could also think of
it as the Napster PDB. 

> 5. If/when passes Last Call, goes to ADs for publication as a WG 
> Informational RFC in our "PDB series".
> >> The industry expectations I keep seeing seem to militate toward standards
> >> track.  Although frankly, the distinction between informational and standards
> >> track is missed by the outside world. 

The IETF generally speaking only standardises wire protocols. 
We decided to put PHBs on the standards (or experimental) track because
they are very close to being a wire protocol - they describe how a node
acts when certain bits are set in a packet. PDBs are really not quite
in this category; but it's a judgement call. I can imagine a trade
association writing SLS standards that would cite a PDB; but they can
cite an Informational RFC as long as they don't mistake it for a standard.
And as you say, marketroids don't care.

In another message you wrote:
...
> 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.

Oh? Since those guys are going for MPLS and MPLS is integrating diffserv
support, I'm not sure you're correct.

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

I thought that's what we were doing.
> 
> > > 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."

Hey! This text is the direct result of the lunch conversation you
and I had in Adelaide, with a napkin drawing. Maybe the text
should clarify that it's talking about the difficulty of
a complete *mathematical* understanding - exactly what we're
arguing about in the case of EF/VW. But it would be dishonest
to claim that it's easy.

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

And I won't say that. They are major building blocks, but at least the
ETSI view of edge2edge service is a specific set of parameters
such as {throughput>x, delay<y, jitter<z}. That's still one layer
up from a PDB.

Regards,

   Brian

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