From diffserv-interest-bounces@ietf.org Fri Nov 04 19:12:37 2005 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 1EYBfh-0003F7-TC; Fri, 04 Nov 2005 19:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBfh-0003Ev-Ci for diffserv-interest@megatron.ietf.org; Fri, 04 Nov 2005 19:12:37 -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 TAA23587 for ; Fri, 4 Nov 2005 19:12:14 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYBun-0007dy-0W for diffserv-interest@ietf.org; Fri, 04 Nov 2005 19:28:13 -0500 Received: from c-24-6-155-12.hsd1.ca.comcast.net ([24.6.155.12] helo=[10.1.1.74]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1EYBff-0007Ma-8N for diffserv-interest@ietf.org; Fri, 04 Nov 2005 19:12:35 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.6.155.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: kmnichols Message-ID: <436BF8F6.4090302@pollere.com> Date: Fri, 04 Nov 2005 16:12:38 -0800 From: Kathleen Nichols User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 To: diffserv-interest@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Of possible interest to this list X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Differentiated services general discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org I posted this to TSV WG about WGLC on draft-ietf-tsvwg-diffserv-service-classes-01: 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 _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From diffserv-interest-bounces@ietf.org Tue Nov 08 13:25:13 2005 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 1EZY9h-00062h-2K; Tue, 08 Nov 2005 13:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZY9e-00061q-My; Tue, 08 Nov 2005 13:25:11 -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 NAA23988; Tue, 8 Nov 2005 13:24:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYPU-0003wB-4j; Tue, 08 Nov 2005 13:41:34 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2005 10:24:58 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="228139779:sNHT29213836" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA8IOtag017536; Tue, 8 Nov 2005 10:24:56 -0800 (PST) Received: from [209.52.107.183] (sjc-vpn7-146.cisco.com [10.21.144.146]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id jA8IY3Oh027878; Tue, 8 Nov 2005 10:34:03 -0800 In-Reply-To: <436BF3A4.4050707@pollere.com> References: <436BF3A4.4050707@pollere.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Tue, 8 Nov 2005 10:24:52 -0800 To: Kathleen Nichols X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=7608; t=1131474846; x=1131907046; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Tsvwg]=20draft-ietf-tsvwg-diffserv-service-classes-01=20WGLC| From:Fred=20Baker=20| Date:Tue,=208=20Nov=202005=2010=3A24=3A52=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=bxkoPOF5HJOWujXtAQwTERjPSW/pIOUGqnMqDRnBbadT27r1AumFARom8twte1keZE0iJNin tlZw4rs30Qxucz7osfVaGdFwmTK4V1odVrji6tsKdTwIwSv+O50yPwQ4zt03qH4fzUvDq9Hi7Lf BmWCg1asnvAGbC8GAEe/vd5s= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: dcpel@ietf.org, diffserv-interest@ietf.org, TSVWG Subject: [Diffserv-interest] Re: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Differentiated services general discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org Hi Kathy. This is a discussion we have had for quite a while now, and it is not news to you that while your reading of the consensus in the diffserv working group was as you report, there was also a significant set of people who even then were interested in end to end QoS and wanted some concept of end to end service classes. The consensus was, as we say, a rough consensus, not a uniform one. Let me try to to address your points. On Nov 4, 2005, at 3:49 PM, Kathleen Nichols wrote: > Concern 1: This draft ties "service class" to applications and to > specific PHBs in all networks. I'm not sure I agree with that. It ties the service to the behaviors of classes of applications and the requirements that they have. For example, it mentions the needs of applications that move large volumes of traffic and are relatively insensitive to their users, which is to say applications that transfer files (examples of which might include FTP, Network News, and peer-to-peer file sharing) versus transaction applications, examples of which might include web services, the web itself, SNMP, and a variety of others. It doesn't try to assign a DSCP to HTTP and another to FTP; it does assign DSCPs to classes of applications that have more-or-less-consistent PHB-type requirements and user expectations. Practically speaking, this is probably the single largest use of QoS capabilities I have worked with customers on prior to the deployment of real time applications. In the late 1960's IBM discovered that providing a sub-second response to CICS queries was important to its customers, and made a heavy marketing program regarding "sub-second response time". In developing SNA, they found it necessary, to be responsive to customer needs, to be able to differentiate between file transfer traffic and transaction traffic. In the 1980s, distinguishing between echoplex terminal traffic and (to name one example) NFS became similarly important, and both RFCs 896 (which dealt with managing telnet traffic in a congested network where telnet competed with file transfers) and RFC 970 (which generalized that to help address TCP SWS and other issues, and was seminal in the development of modern fair queuing concepts) dealt with these issues. They remain at issue in today's networks, where the fiber core is often very high capacity but the access network may involve relatively low speed links and so on. In addition, with the development of real time services such as video and voice on IP, these applications have similarly experienced problems in the access networks, but have very different PHB requirements - but requirements that can still be described in classes. Practically speaking, you will recall when you, Van, and I were all at Cisco and Cisco stopped deployment of voice networks until we got a priority queuing concept into the MQC configurations of our routers, due specifically to the requirements of these applications. We can discuss academic concepts of service classes and so on if you like, but pragmatically the traffic behaviors are not ethereal concepts: they are the behaviors of traffic generated by and depended on by applications, and by the users who use them. Pragmatically, if we don't meet those applications' and users' needs in the architecture, it is not the users who are wrong. We have developed an anachronistic architecture, and it needs to change. So yes, if (as you and France Telecom both said last night in the O&M Area Meeting) we need to develop end to end service architectures, there are a variety of things we need to have, and one of them is some form of lingua franca in which we can discuss the traffic that users and their applications generate and consume, and what our expectations are regarding that traffic. Regarding the application of DSCP values to service classes, the draft does not require users or networks to use specific DSCP values, but it does recommend values. There are two ways to look at this. One, if DSCPs are truly only of local significance, then the assignment of DSCP values to the EF and AF classes is incorrect, and in fact the division of DSCP values into for-standardization, experimental-with-possible-standardization, and experimental-use is for naught. People should simply assign DSCP values locally. On the other hand, forcing them to do so is rather a big deal - it means that the network operator now has a huge job on his hands, and at every network interchange point they must be translated. And lacking consistent classes on either side of that demarcation point, the translation is not at all obvious. So, yes, we recommend DSCP values, and do so to simplify deployment and minimize the work that must be done at network boundaries. Operators remain free to do something different. > Again DiffServ was explicit about the decoupling of services and > applications. Right. But the services must serve classes of applications, or they are very difficult to describe. I'll refer you to RFC 3246/3247, if you like; these are very distinctly about traffic that behaves in a CBR manner and requires very predictable service. In terms of applications people use today of that type, that would be ATM-over- MPLS, to a less extent frame relay over MPLS, and VoIP. It might also include some classes of video service, but does not include services using variable rate codecs like MPEG-4, which have a very different set of requirements. > Concern 2: The definition of Service Class and its relationship to > traffic aggregates. > [snip] > 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. I will ask two questions. First, if a traffic aggregate is not the sum of some number of traffic streams, what is it? Second, if PDBs are so very important, would you please remind me what the RFC Number of the PDB associated with RFC 3246/3247 is? We are in fact using the PDB in RFC 3662 for the scavenger service. If this is a place where we have fallen down and deserve public censure, I think you have to agree that you are not lily-white either. > Concern 3: draft seems to equate requiring a uniform PHB with > achieving an end-to-end QoS. I'm not at all sure we said that; if you could point us to the text, I'd appreciate it. What we are saying, or what I think we're saying, is that Parehk&Gallager's proofs in Infocomm '91-'93 indicate that to deliver a predictable service from host to host across a network, one must be able to quantify the behavior of both the hosts and the relevant routed or switched interfaces across the network. There are certainly also other engineering and management issues, something we don't gain-say. But trying to provide end to end QoS *without* describing the PHBs in question is, mathematically, not possible per the available mathematical work on the topic. > These DiffServ documents were clear that a PHB does not a service > make. Agreed. Now tell me how to build a service without the PHB? > 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. I disagree. The tools are still in the hands of operators. That said, the operators come to me asking which tools to use and how. At Cisco, we funded the development of a simulator and a major clean-up of NS-2 with a view to helping them accomplish that, and have given a lot of free consulting to our customers helping them do this. My colleagues at Nortel find themselves similarly engaged. The discussion has gone to the ITU due to IETF's disinterest in helping out with the topic, resulting in certain aspects of the NGN architecture, and it has come back to us in IEPREP, in which various agencies have asked for additional services of various kinds, such as a DSCP for all emergency traffic. Numerous folks are looking to the IETF for guidance, and given a vacuum will go elsewhere that may be less clueful. This draft seeks to summarize that guidance, leaving the specific engineering in the operator's very capable hands. It is not our place to list our customers, who discuss their issues with us in private. There have, however, been some who commented publicly, such as Optus' request that call control traffic for voice and video not occupy the same service queue as the traffic is is about. In fact, we are in private discussions with quite a number of enterprize, access, and backbone network customers, with the GIG folks who held their BOF last night, and so on. There is significant interest in developing some set of service classes for classes of applications with more-or-less-consistent requirements. We would be happy to have your suggestions on text to change, which is why this has been in review in diffserv and in tsvwg in various forms since 2002. Kwok, Josef, and I agreed on this note before I sent it... _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From diffserv-interest-bounces@ietf.org Wed Nov 09 12:15:55 2005 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 1EZtYB-00030V-51; Wed, 09 Nov 2005 12:15:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtY6-0002zW-CQ for diffserv-interest@megatron.ietf.org; Wed, 09 Nov 2005 12:15:54 -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 MAA22901 for ; Wed, 9 Nov 2005 12:15:21 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZto4-0002Ur-2w for diffserv-interest@ietf.org; Wed, 09 Nov 2005 12:32:25 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id jA9HDSTe016487 for ; Wed, 9 Nov 2005 12:15:28 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Nov 2005 12:12:55 -0500 Message-ID: To: diffserv-interest@ietf.org Date: Wed, 9 Nov 2005 12:12:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.11.9.16 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Subject: [Diffserv-interest] FW: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Differentiated services general discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org -----Original Message----- From: Black, David Sent: Tuesday, November 08, 2005 3:43 PM To: nichols@pollere.com; tsvwg@ietf.org Cc: dcpel@ietf.org; diffserv-interest-request@ietf.org Subject: RE: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC Kathie, Pulling out selected portions of your email to comment on your issues ... > 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. That certainly was not the draft's intent. To the extent that the draft is at odds with RFC 2474 and 2475, I suspect the problems can be cleaned up with suitably careful selection of terminology and a suitably detailed editing pass. (NB: I'm a co-author of RFC 2474 and 2475). > Concern 1: This draft ties "service class" to applications and to > specific PHBs in all networks. > 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. > Again DiffServ was explicit about the decoupling of services and > applications. This draft's coupling of network services to applications is deliberate and is much of the value of the draft. Diffserv has always been viewed as a toolkit - it has the equivalent of band saws, planers, drill presses, etc. In the hands of an expert, there's no limit to what can be built, but it's intimidating to the point of inaccessible to a novice who just wants to build a table and chairs. Think of this draft as a set of "project plans" for building all the furniture that a house might need. The user may choose what to build (e.g., maybe our example novice doesn't need a china cabinet right now). This is one of the reasons that it's deliberately *not* going standards track - Best Current Practice was one possible alternative to Informational. > Concern 2: The definition of Service Class and its relationship to > traffic aggregates. I think this is mostly sloppy terminology. The focus of the draft is (and should be) the traffic aggregates around which the core of the network/diffserv domain needs to be designed. The draft definitely needs to allow the situation in which aggregates are exploded into flows at the network edges and flows may "switch" aggregates when passing between networks (e.g., I'm a customer of network A, so my video download gets gold treatment from that operator, but network B carries it as best effort). To the extent that it forbids this sort of thing, the draft needs to be corrected to point out that if the behavior changes across domains, it's harder to be sure that the result is consistent QoS ... > Concern 3: draft seems to equate requiring a uniform PHB with achieving > an end-to-end QoS. The draft shouldn't "equate" - to the extent it does, it needs editing. What the draft is trying to do is describe one approach to building end-to-end QoS, namely use the same PHB (and hence PDB) uniformly across the networks (diffserv domains) involved. See the above "project plans" analogy - such a set of plans are not the only way to build furniture (e.g., plans for a novice probably won't use mortise/tenon construction). > 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. The "project plans" comment applies to this also. I think this draft is an important complement to the existing body of diffserv work and needs to be published as an RFC. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > On Behalf Of Kathleen Nichols > Sent: Friday, November 04, 2005 6:50 PM > To: tsvwg@ietf.org > Cc: dcpel@ietf.org; diffserv-interest-request@ietf.org > Subject: [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 > _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest