Subject: [Dcpel] DCPEL Proposal

From: Roland Bless <[email-masked]>
Date: Fri, 07 Oct 2005 12:12:16 +0200

Hi Kathie,

I agree very much with your proposal. It would be a good starting
point and the logical consequence to continue the work that begun in the
DiffServ WG. Furthermore, I think that the increasing deployment of VoIP
and DoS protection
(http://www.internet2.edu/~ben/papers/20030827-qos-dos.pdf)
are be a good driver for QoS-based solutions. And some people already
started to deploy things, see e.g.
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-00.txt
http://www.ietf.org/internet-drafts/draft-briscoe-twvwg-cl-phb-00.txt
So there needs to be discussion whether such approaches are
the right basis towards a common solution or CP architecture.

I think PDBs are a really useful concept, but it is very
important to show exactly how PDBs should be controlled, which includes
IMHO a very detailed PDB specification. So far we don't have many
standardized PDBs for "elevated" services, but many operators have a
rough guessing/feeling what they could do with DiffServ. AFAIK most
operators (start to) use DiffServ as an overlay for splitting bandwidth
into different isolated traffic classes, i.e. they simply prioritize
their traffic, e.g., for VoIP. A static DiffServ setup this is elatively
easy to deploy, but currently providers probably don't care much about
the actual PDB attributes or PDB guarantees (though it would be good
hear counter examples...). So I feel that we have a lack of PDBs for
elevated services, e.g., guaranteed bandwidth.

Moreover, as soon as we start to deploy DiffServ dynamically, we may
need admission control, resource management and signaling. Therefore, I
see a possible strong relation to the work in the NSIS WG. If QoS a
agents, Proxies, BBs are used it would be good to hear what protocols
should be used for configuring routers (FP elements).
A suitable protocol could be COPS, but I'm unsure whether this
has enough support from the IETF community (esp. vendors, operators).
So it would be good to gather input about such issues.

I've been working on inter-domain (and inter-AS/inter-operator) DiffServ
management which is the last point on your list of goals. From my
perspective it is important to provide QoS-based services globally just
like today Internet access or IP connectivity. In order to get a
scalable solution we also need to apply inter-domain aggregation
concepts in the control plane, not only in the data plane (DiffServ).
I'm currently preparing a draft for NSIS that tries some kind of
analysis what would be required for this.

Best regards,
 Roland

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 07 Oct 2005 14:23:54 +0200

Hi,

I forgot to mention that an important operational point
is the security. The correct operation of DiffServ networks
depends heavily on a correct marking at the first-hop/boundary
node. Due to aggregation it is usually later not easily possible
to figure out a particular non-admitted flow...
Consequently, one should probably use an IPsec tunnel for packets
sent to the first-hop router in order to authenticate packets from
legitimate users and thus to prevent theft of resources
etc. This IMHO would increase the operational complexity
a lot...

Regards,
 Roland

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 07 Oct 2005 11:05:33 -0700

Roland Bless wrote:
..
> DiffServ WG. 

That's good to hear. Clearly a lot of work to clarify and constrain
the useful issues is still needed.

Furthermore, I think that the increasing deployment of VoIP
> are be a good driver for QoS-based solutions.

There was certainly discussion in the earlier days (perhaps not
on the diffserv WG list) of problems of DOS attacks. Decoupling
the control plane and forwarding path and properly structuring
the authentication mechanisms across domain boundaries seems
like it can be helpful here.

 And some people already
> the right basis towards a common solution or CP architecture.

I read those drafts as describing a stand-alone architecture, not
diffserv, that just wants to use the DSCP mechanism. From the abstract:

"This document describes an architecture to achieve a Controlled Load
(CL) service edge-to-edge, i.e. within a particular region of the
Internet, by using distributed measurement-based admission control."

and later in the document, the approach is contrasted to "diffserv".
Although a comparative discussion of QoS architectures might be a
useful exercise in some forum, if we take that approach we will
end up having a very difficult time constraining our work here. This
is why the proposed goals are explicitly for the diffserv architecture
that was described in RFCs 2474, 2475, and 3086. And, to the abstract
router model of RFC 3290.
> elevated services, e.g., guaranteed bandwidth.

Yes, agree. Though we may have some PDBs for "elevated services" and
just a dearth of discussion. Not clear at this point.

> see a possible strong relation to the work in the NSIS WG.

Yes, absolutely we need more control plane structure. I believe we
can discuss a framework for what each of these elements needs to
do and perhaps standardize how they can interact. Thus, analogously
to the forwarding path, we allow innovation in the implementation of
resource management, admission control, etc. Signaling is more problematic.
A problem is the the NSIS WG says in the abstract and introduction
of RFC4080:

   The Next Steps in Signaling (NSIS) working group is considering
   protocols for signaling information about a data flow along its path
   in the network.

And the rest of the text makes it clear this is a path-oriented
protocol. Following a diffserv approach, where QoS is delivered
by a network domain, the signaling (from outside) needs to be to the
network domain.

If QoS a
> So it would be good to gather input about such issues.

Yes, this configuration protocol is a different issue. COPS seems
suitable on the surface, but other approaches may be more efficacious.
It seems an issue worth exploring
> analysis what would be required for this.

Aggregation is clearly a topic that should be examined further.