[Dcpel] Re: DCPEL Proposal

[Kathleen Nichols <[e-mail]>]

Roland Bless wrote:
..
> 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. 

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
> and DoS protection
> (http://www.internet2.edu/~ben/papers/20030827-qos-dos.pdf)
> 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
> 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 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.
> 
> 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.

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

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

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

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

Aggregation is clearly a topic that should be examined further.


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