[Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC
"LEVIS Pierre RD-CORE-CAE" <pierre.levis@francetelecom.com> Mon, 14 November 2005 19:58 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbkTH-0001aq-SK; Mon, 14 Nov 2005 14:58:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtRC-0001Xf-PY; Wed, 09 Nov 2005 12:08:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22235; Wed, 9 Nov 2005 12:08:14 -0500 (EST)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZthF-0002CY-Ib; Wed, 09 Nov 2005 12:25:18 -0500
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 18:08:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Nov 2005 18:08:33 +0100
Message-ID: <D109C8C97C15294495117745780657AE038D8987@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC
Thread-Index: AcXhmq+YbX0wtZ2gTiaSwep3RBssZQDs+Byg
From: LEVIS Pierre RD-CORE-CAE <pierre.levis@francetelecom.com>
To: Kathleen Nichols <nichols@pollere.com>, tsvwg@ietf.org
X-OriginalArrivalTime: 09 Nov 2005 17:08:38.0098 (UTC) FILETIME=[39DEE320:01C5E550]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:28 -0500
Cc: dcpel@ietf.org, diffserv-interest-request@ietf.org
Subject: [Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC
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
About the decoupling of services and applications. There are many approaches that divide the Network layer in service classes accordingly to applications requirements. See UMTS/GPRS TS 23 107 and, may be to a lesser extend, ITU Y.1541. The tendency is very much "yet another application, yet another class". Simply because it doesn't seem reasonable to have as many classes as applications, applications are grouped by categories. But fundamentally the rationale remains the network is to closely adapt to the application. This is indeed contradictory to several architectural ideas that enable the current Internet, like the hour glass model and the end-to-end principle. However it's also very true that network services will be used by applications and that there must be a certain level of coherence between the two. The notion of Meta-QoS-Class (MQC) we have introduced in <draft-levis-meta-qos-class-00.txt> both maintains the independence between PDB (or service class or class of service or whatsoever you call it) and applications, and allows dynamic linkage. Simply speaking, a MQC is just a label associated to a type of applications that can be put on any implemented PDB (we use the term local class) to certify this class is suitable for this application. MQC concept makes it possible to handle network services and applications requirements as separate notions. MQC is particularly interesting when it comes to SLS negotiations between ISPs (pSLS). We consider it is harmful to have pSLS QoS guarantees that span several domains. A pSLS should only concern the QoS of the neighbouring domain you're negotiating with. Two neighbouring local classes can be bound together if they conform to the same MQC. Pierre -----Message d'origine----- De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De la part de Kathleen Nichols Envoyé : samedi 5 novembre 2005 00:50 À : tsvwg@ietf.org Cc : dcpel@ietf.org; diffserv-interest-request@ietf.org Objet : [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC My concerns with this document haven't changed much from the comments I had for the authors on the original version. My major concern is that this draft rewrites many concepts that were crafted by consensus over several years in the DiffServ WG and are currently in use. Certainly, concepts and standards have to be revisited from time to time, but this draft is not being explicit about it. At the very least, this should be made clear both in the document and by the ADs, particularly since some of it is at odds with RFC2474, a standards track document. Concern 1: This draft ties "service class" to applications and to specific PHBs in all networks. This draft defines a "service class" as: "a set of traffic that requires specific delay, loss and jitter characteristics from the network for which a consistent and defined per-hop behavior (PHB) [RFC2474] applies. Conceptually, a service class pertains to applications with similar characteristics and performance requirements, such as a 'High Throughput Data' service class for applications like the web and electronic mail, or a 'Telephony' service class for real-time traffic such as voice and other telephony services." This links *applications* to requirements for specific delay, loss and jitter characteristic which is counter to the internet history of building applications that adapt to network conditions. The point of DiffServ was to provide tools to make it possible to differentiate traffic on whatever basis an operator desired, to not require that inner workings of a network be exposed, and not to require a particular PHB. If an operator can deliver certain specified treatments (in SLSs) to traffic across its network, it was considered its business what PHB and edge treatments were used. See RFC2475: "Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service." and "A distinction is maintained between: o the service provided to a traffic aggregate, o the conditioning functions and per-hop behaviors used to realize services, o the DS field value (DS codepoint) used to mark packets to select a per-hop behavior, and o the particular node implementation mechanisms which realize a per-hop behavior. Service provisioning and traffic conditioning policies are sufficiently decoupled from the forwarding behaviors within the network interior to permit implementation of a wide variety of service behaviors, with room for future expansion." but this draft would erase that distinction, and (more RFC2475): "The following requirements were identified and are addressed in this architecture: o should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s), o should allow decoupling of the service from the particular application in use, ... o should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes," Again DiffServ was explicit about the decoupling of services and applications. Concern 2: The definition of Service Class and its relationship to traffic aggregates. From RFC 2474: "Services are realized by the use of particular packet classification and traffic conditioning mechanisms at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic. A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them." and the definition from standards track RFC2474: "Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. To summarize, classifiers and traffic conditioners are used to select which packets are to be added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field is used to designate the packet's behavior aggregate and is subsequently used to determine which forwarding treatment the packet receives." This is turned inside out by this draft which talks about traffic aggregates as though they were traffic streams, as defined by RFC 2475, and invariant under edge conditioning and aggregation that must of necessity occur inside any non-trivial network. The effects of aggregation and the need to design PDBs and services to be careful of these is discussed in RFC3086, reflecting DiffServ WG discussions. First, from RFC 2475: "Traffic stream an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier." From the draft: "A Service Class as defined here is essentially a statement of the required characteristics of a traffic aggregate; the actual specification of the expected treatment of a traffic aggregate within a domain may also be defined as a Per Domain Behavior [RFC3086]." This is the only place in the draft where RFC 3086, a product of the DiffServ WG is mentioned. (There was no mention in the original.) From RFC 3086's abstract, giving context for this RFC: "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." and from RFC 3086's Introduction: "Diffserv classification and traffic conditioning are applied to packets arriving at the boundary of a DS domain to impose restrictions on the composition of the resultant traffic aggregates, as distinguished by the DSCP marking, inside the domain. The classifiers and traffic conditioners are set to reflect the policy and traffic goals for that domain and may be specified in a TCA (Traffic Conditioning Agreement). Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to group packets solely according to the behavior they receive at each hop (as selected by the DSCP). This approach has well-known scaling advantages, both in the forwarding path and in the control plane. Less well recognized is that these scaling properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets. Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold regardless of how the temporal characteristics of the marked traffic aggregate change as it traverses the domain, then that PDB scales. " A per-hop behavior, which is just how a packet is forwarded at each node, cannot directly result in a particular end-to-end, or even edge-to-edge set of characteristics since it is dependent on how much traffic is admitted and how traffic is mixed and so on. Which brings me to: Concern 3: draft seems to equate requiring a uniform PHB with achieving an end-to-end QoS. Contrast this with the RFC 2475 and 3086 approaches of having each network domain specify the loss rate, maximum delay, and/or other metrics which it will provide to traffic streams that conform to certain agreed-upon (via SLS) behavior (e.g., interface, markings, rate). Though work remains on how to put the values from a chain of networks together, it is certain possible to figure out the maximum delay through a set of networks with services so specified. At the same time, nothing need be known about network internals. If I am told that a traffic stream will be priority queued at every router between two points, I am told nothing about the maximum delay the packets will experience. In section 1.5.3 of the draft, "Expedited Forwarding PHB [RFC3246] behavior was originally proposed as a way to implement a virtual wire, and can be used in such a manner." The EF PHB was originally proposed as a *building block* to create a service (then called virtual leased line) and both the original proposal in RFC 2598 and the update in RFC 3246 were quite clear about this. From RFC 2598: The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to- point connection or a "virtual leased line". ... Creating such a service has two parts: 1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.) 2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate. The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part. From RFC 3246: "The intent of the EF PHB is to provide a building block for low loss, low delay, and low jitter services. The details of exactly how to build such services are outside the scope of this specification." and "Note that the EF PHB only defines the behavior of a single node. The specification of behavior of a collection of nodes is outside the scope of this document. A Per-Domain Behavior (PDB) specification [7] may provide such information." These DiffServ documents were clear that a PHB does not a service make. Finally, the draft specifies a lot of operational rules for networks. This is inverted from the DiffServ WG approach of putting tools into the hands of operators. Kathie Nichols _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ Dcpel mailing list Dcpel@ietf.org https://www1.ietf.org/mailman/listinfo/dcpel
- [Dcpel] draft-ietf-tsvwg-diffserv-service-classes… Kathleen Nichols
- [Dcpel] Re: [Tsvwg] draft-ietf-tsvwg-diffserv-ser… Fred Baker
- [Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-ser… Black_David
- [Dcpel] RE: [Tsvwg] draft-ietf-tsvwg-diffserv-ser… LEVIS Pierre RD-CORE-CAE