RE: [Dcpel] some comments on draft-vandenberghe-dcpel-basics-00.txt

["Hancock, Robert" <[e-mail]>]

hi kathie,

> Robert,
> 
> First, I apololgize for the "minor comprehensibility nits" but
> 1) we wanted to get something out for comment and 2) we figured
> that things might change a lot after discussion, so a lengthy
> editing pass seemed okay to skip.

fair enough.

> 
> This is a fairly short reply. I can send more later or let others
> reply in detail.
> 
> > 1. What is a "traffic aggregate"?
> > 
> 
> I thought that we said we were using the 3086 definition of taffic
> aggregate. Anyway, that is:
> 
> 
>       Traffic Aggregate: a collection of packets with a codepoint that
>       maps to the same PHB, usually in a DS domain or some subset of a
DS
>       domain.  A traffic aggregate marked for the foo PHB is referred
to
>       as the "foo traffic aggregate" or "foo aggregate"
interchangeably.
>       This generalizes the concept of Behavior Aggregate from a link
to a
>       network.

True, and that definition is included in the 'basics' draft directly.
My question was not so much 'what does the definition mean?' but
'is the definition too broad to be a good basis for scoping the 
problem space?'. Defining a specific aggregate for a link is very
simple;
defining a specific aggregate for a network could be nearly arbitrarily 
complex. Is all of that complexity envisaged to be in scope, or is that
something still to be worked out?

> 
> > 2. Interior vs. edge vs. exterior
> 
> So, again, we are following the diffserv architecture. See, for
> example section 2.1.1 of RFC2475. "edge", "boundary" and "border"
> are somewhat interchangeable, but normally "border" is used for
> the edge of an AS where boundary or edge might be at the edge of
> a DS domain that is not administratively separate from the adjoining
> one. We should probably avoid "exterior". The same
> distinction between interior and edge/boundary/border shows up in
> RFC3086.

That seems reasonable; but again, why does the basics draft need to
assert that the DCP should do some things only at the edge/whatever
only and some things domain wide? Isn't that part of the solution
space?

> 
> > 3. Role of PDBs and service descriptions
> > 
> ...PDBs apparently define the treatment that a set of packets
> > will receive from a DS domain; that sounds like a service to
(certainly
> > in the way that IntServ talks about service elements). Elsewhere the
> > document indicates that multiple services might use (implement?
> > provide?) the same PDB, but with different policy constraints, which
> > implies that 'service' means something more like an SLS (e.g. in the
> > Tequila sense). It might be nice to have a definition of 'service'
and
> > some examples.
> 
> So, I think you have it correct. RFC3086 says in the abstract:
> 
>     The next step is to formulate examples of how forwarding path
>     components (PHBs, classifiers, and traffic conditioners) can be
used
>     to compose traffic aggregates whose packets experience specific
>     forwarding characteristics as they transit a differentiated
services
>     domain.  The WG has decided to use the term per-domain behavior,
or
>     PDB, to describe the behavior experienced by a particular set of
>     packets as they cross a DS domain.  A PDB is characterized by
>     specific metrics that quantify the treatment a set of packets with
a
>     particular DSCP (or set of DSCPs) will receive as it crosses a DS
>     domain.  A PDB specifies a forwarding path treatment for a traffic
>     aggregate and, due to the role that particular choices of edge and
>     PHB configuration play in its resulting attributes, it is where
the
>     forwarding path and the control plane interact.  The measurable
>     parameters of a PDB should be suitable for use in Service Level
>     Specifications at the network edge.
> 
> And says later that a PDB might be specified in an SLA (e.g. if it is
a
> "well-known PDB") or perhaps just the measurable parmeters of the PDB.
I
> believe part of the work of dcpel can be to work out what are the
right
> ways to exchange this information. But the point is well-taken that
all
> of this will need to be made clearer.

OK, my fog may be starting to lift slightly. My underlying question is
whether there is an expectation to use PDBs to describe resources in 
the interdomain communication. AFAIK neither Y.1541 (caveat: I have only
looked at the 2002 version) nor the NSIS Q-spec use PDBs themselves, but
they might very well use the measurable parameters of PDBs. There could
be a concern about extending the vocabulary for describing interdomain
QoS any further; some people think that it is already too sophisticated
;-)
But I guess this could come out of subsequent work.

cheers,

robert h.

_______________________________________________
Dcpel mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dcpel