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

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
Dcpel@ietf.org
https://www1.ietf.org/mailman/listinfo/dcpel