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

[Kathleen Nichols <[e-mail]>]

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.

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.

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

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

> 4. SIP interactions

The quick response is that we didn't plan to change SIP or 3312 but
to use that as a guideline for our framework, that is, our framework
should have a way to interoperate in the 3312 sense. It was suggested
as a starting point (and maybe sufficient) for application
interaction.

> 5. Is development of signalling protocols in scope or not?
> 
> 4.1.2 says that "...definition of an interdomain QoS signaling protocol
> is considered as future work for the proposed DCPEL WG", but 4.2 only
> lists interworking with existing protocols. This seems contradictory.

So I think this is a language failure. I think we meant something more
like "selection" instead of "definition" subject to the state of the
art at the time interdomain is being considered. But perhaps others
have a different opinion.

	Kathie


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