[Dcpel] Re: [Tsvwg] draft-ietf-tsvwg-diffserv-service-classes-01 WGLC
Fred Baker <fred@cisco.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-0001ZL-0i; 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 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: <D0A3946F-3273-4BD9-81D0-A3E214759322@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Tue, 08 Nov 2005 10:24:52 -0800
To: Kathleen Nichols <nichols@pollere.com>
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<fred@cisco.com>| 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
X-Mailman-Approved-At: Mon, 14 Nov 2005 14:58:28 -0500
Cc: dcpel@ietf.org, diffserv-interest@ietf.org, TSVWG <tsvwg@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
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... _______________________________________________ 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