[Dcpel] DCPEL Proposal

Roland Bless <bless@tm.uka.de> Fri, 07 October 2005 10:12 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpDS-00040j-2f; Fri, 07 Oct 2005 06:12:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENpDR-00040e-4v for dcpel@megatron.ietf.org; Fri, 07 Oct 2005 06:12:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08568 for <dcpel@ietf.org>; Fri, 7 Oct 2005 06:12:34 -0400 (EDT)
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80] ident=[U2FsdGVkX1+Fa1tkzWga3rcwnK38dXGnO5C+qRDbGKA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENpMh-0006qJ-LV for dcpel@ietf.org; Fri, 07 Oct 2005 06:22:12 -0400
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1ENpD7-0002bQ-QD; Fri, 07 Oct 2005 12:12:25 +0200
Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3B84FB246; Fri, 7 Oct 2005 12:12:17 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1ENpD7-0004Yn-05; Fri, 07 Oct 2005 12:12:17 +0200
Message-ID: <43464A00.2020909@tm.uka.de>
Date: Fri, 07 Oct 2005 12:12:16 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: Kathleen Nichols <nichols@pollere.com>
X-Enigmail-Version: 0.92.0.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.5 (----)
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: dcpel@ietf.org
Subject: [Dcpel] DCPEL Proposal
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Sender: dcpel-bounces@ietf.org
Errors-To: dcpel-bounces@ietf.org

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