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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 24 Feb 2006 16:05:04 -0000

hi,

i've been reading draft-vandenberghe-dcpel-basics-00.txt and
draft-mendes-dcpel-requirements-00. i have some comments/questions on
the first. leaving aside minor comprehensibility nits, my main questions
are about trying to understand the scope in a bit more concrete terms.

this email got rather long; sorry for that.

r.

1. What is a "traffic aggregate"?

This term is given in section 2, as the generalisation of a behaviour
aggregate (which applies to a link) to a network. What I don't
understand is the nature of the generalisation - does a traffic
aggregate apply to a sequence of links along a path, or to all traffic
within a network? (Both possibilities are listed in the previous
section.) 

These would seem to me to be rather different concepts, especially once
routing interactions are taken into account. The first is can be defined
quite precisely by giving a specific (ingress, egress); for the second,
is one expecting ({set of ingresses}, {set of egresses}), or {set of
edge nodes}, or just to say 'all traffic passing a given AS'? Does a
traffic aggregate have a direction? Would a service description
assume/define particular traffic patterns within the aggregate, or would
arbitrary distributions be expected? If there is a change in external
connectivity (e.g. a BGP route switches from one egress to another) is
the definition of the aggregate supposed to change, or are you supposed
to renegotiate for a new aggregate?

[The reason I ask is that there seems to be a big spectrum of complexity
here in the range of possible sophistication of aggregate definition.
And I'm not sure where the scope boundary is supposed to be.]

Section 4.1 includes the phrase "There must be a non-path-specific
option." but I can't tell what this means - does it refer to signalling
mechanisms or to the definition of traffic aggregates themselves?

2. Interior vs. edge vs. exterior

The document seems to distinguish three different aspects of a DiffServ
network, but I'm not sure how they relate and/or overlap.
- There is a fairly consistent message that the 'internals' of the
network should not be exposed externally
- There is a discussion of developing or being consistent with a
universal inter-domain interface (which would presumably be independant
of these 'internals')

On the other hand, there are several places where it's asserted that
certain sorts of operations should affect only edge and not interior
nodes. This seems to be something that does more than just scope the
problem but describes some fundamental aspect of the solution; does it
mean that the edge nodes and interior nodes are going to be
distinguished in some architectural sense? For example, does this
distinction between edge and interior count as an aspect of the
'internals' which should not be exposed?

3. Role of PDBs and service descriptions

[This may all be clear to people with a longer DS background than me.]
I got continually confused by the relationship between PDBs and
services. 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.

A particular way of posing the question: would PDBs be visible in the
inter-domain interface of a DS domain (e.g. as part of a service
description)? If so, how would the use of PDBs to describe packet
treatment relate to other syntax for describing packet treatment (e.g.
ITU based)? Or are PDBs purely 'internal' language for a DCP to use in
intra-domain communication between the various DCP elements? For
example, the requirements draft indicates that the same inter-domain
control interface should be applicable to non-DiffServ domains, which
presumably wouldn't use PDBs at all.

4. SIP interactions

I was confused by two aspects of the interaction with SIP.

- SIP is mentioned as a possible instantiation of the inter-domain
control mechanism, but I don't see how it would be relevant. If the idea
is to piggyback the DifS signalling for a given flow on the SIP
exchanges for a flow, this would imply that there is a constraint that
the SIP signalling path and traffic path are the same (at the domain
level), which does not need to be true. If the idea is to have totally
different SIP interactions, I'm not clear how much of the SIP protocol
machinery is relevant to the DCP problem space.

- So far as I can tell, assuming that application interactions are
handled by 3312 (SDP preconditions) is quite valid, but also means that
there is no further relevance to the DCP work. As far as I understand,
3312 allows application endpoints to agree with each other which
endpoint is taking responsibility for resource configuration, but the
logic of the detailed interactions between the resource configuration
and SIP/SDP signalling is internal to those endpoints. In other words,
the fact that 3312 is being used should be entirely transparent to the
resource configuration mechansisms between the endpoints. (But 4.2
implies there is some specific work to be done here.)

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.

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

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 24 Feb 2006 14:48:49 -0800

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
> Tequila sense). It might be nice to have a definition of 'service' and

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.

> 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