From exim@www1.ietf.org Wed Oct 8 17:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10195 for ; Wed, 8 Oct 2003 17:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ltg-0003YJ-27 for diffserv-interest-archive@odin.ietf.org; Wed, 08 Oct 2003 17:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98LV4at013640 for diffserv-interest-archive@odin.ietf.org; Wed, 8 Oct 2003 17:31:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Lte-0003Xh-BK; Wed, 08 Oct 2003 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Lsz-0003Wu-Cj for diffserv-interest@optimus.ietf.org; Wed, 08 Oct 2003 17:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10165 for ; Wed, 8 Oct 2003 17:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lsw-0004iu-00 for diffserv-interest@ietf.org; Wed, 08 Oct 2003 17:30:18 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1A7Lsw-0004ic-00 for diffserv-interest@ietf.org; Wed, 08 Oct 2003 17:30:18 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h98LTfNb104826 for ; Wed, 8 Oct 2003 23:29:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98LTfuX247390 for ; Wed, 8 Oct 2003 23:29:41 +0200 Received: from zurich.ibm.com ([9.145.140.210]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA57664 for ; Wed, 8 Oct 2003 23:29:40 +0200 Message-ID: <3F8481A3.70367020@zurich.ibm.com> Date: Wed, 08 Oct 2003 23:29:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: diffserv interest Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] [Fwd: Last Call: 'The Differentiated Services Configuration MIB' to Proposed Standard] Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Last Call: 'The Differentiated Services Configuration MIB' to Proposed Standard Date: Wed, 08 Oct 2003 15:18:01 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce :; CC: snmpconf@snmp.com The IESG has received a request from the Configuration Management with SNMP WG to consider the following document: - 'The Differentiated Services Configuration MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-10-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-08.txt _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Tue Oct 28 03:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07340 for ; Tue, 28 Oct 2003 03:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEP5E-0004Zb-9c for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 03:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S8K8aW017540 for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 03:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEP57-0004Xv-B5; Tue, 28 Oct 2003 03:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEP4b-0004Tm-T2 for diffserv-interest@optimus.ietf.org; Tue, 28 Oct 2003 03:19:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07115 for ; Tue, 28 Oct 2003 03:19:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEP4Y-0004Wd-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 03:19:26 -0500 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEP4X-0004Vp-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 03:19:26 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9S8IqXZ052770 for ; Tue, 28 Oct 2003 09:18:52 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9S8Iq7G268378 for ; Tue, 28 Oct 2003 09:18:52 +0100 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id JAA38860 for ; Tue, 28 Oct 2003 09:18:51 +0100 Message-ID: <3F9E264A.E0EFAB98@zurich.ibm.com> Date: Tue, 28 Oct 2003 09:18:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: diffserv interest Content-Type: multipart/mixed; boundary="------------C31F24EB08CE13B5E627129D" Subject: [Diffserv-interest] [Fwd: I-D ACTION:draft-baker-diffserv-basic-classes-01.txt] Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------C31F24EB08CE13B5E627129D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-baker-diffserv-basic-classes-01.txt Date: Mon, 27 Oct 2003 15:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Configuration Guidelines for Basic Classes of Managed Traffic Author(s) : F. Baker Filename : draft-baker-diffserv-basic-classes-01.txt Pages : 34 Date : 2003-10-27 This paper summarizes a recommended correlation of applications to Differentiated Service Code Points (DSCP) and packet treatments in the network. There is no intrinsic requirement that individual DSCPs correspond to given applications, but as a policy it is useful if they can be applied consistently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-diffserv-basic-classes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-baker-diffserv-basic-classes-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------C31F24EB08CE13B5E627129D Content-Type: Message/External-body; name="draft-baker-diffserv-basic-classes-01.txt" Content-Disposition: inline; filename="draft-baker-diffserv-basic-classes-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-27160930.I-D@ietf.org> --------------C31F24EB08CE13B5E627129D-- _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Tue Oct 28 07:07:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17541 for ; Tue, 28 Oct 2003 07:07:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEScp-00014m-1q for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 07:07:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SC72T1004113 for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 07:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEScn-00013f-AH; Tue, 28 Oct 2003 07:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9UT-0007iA-CX for diffserv-interest@optimus.ietf.org; Mon, 27 Oct 2003 10:41:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20388 for ; Mon, 27 Oct 2003 10:40:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE9UQ-0006nB-00 for diffserv-interest@ietf.org; Mon, 27 Oct 2003 10:41:06 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AE9UP-0006mk-00 for diffserv-interest@ietf.org; Mon, 27 Oct 2003 10:41:05 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9RFeHc00031; Mon, 27 Oct 2003 10:40:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Oct 2003 10:40:18 -0500 Message-ID: From: "Jozef Babiarz" To: Morgan Littlewood , Fred Baker , bdavie@cisco.com, oran@cisco.com, "Ralph Santitoro" , "Paul Coverdale" , kmainwar@cisco.com, Philip Jacobs , acmorton@att.com, diffserv-interest@ietf.org Date: Mon, 27 Oct 2003 10:40:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C39CA0.9ED70D20" Subject: [Diffserv-interest] FW: draft-baker-diffserv-basic-classes-01.txt submission Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C39CA0.9ED70D20 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39CA0.9ED70D20" ------_=_NextPart_001_01C39CA0.9ED70D20 Content-Type: text/plain Please find attached an update to the existing individual draft on Configuration Guidelines for DiffServ Serivce Classes that was submitted to IETF. I tried to address all the issues and concerns rased in the update. Please review and provide comments. Regards, Joe. Jozef Babiarz QoS and Network Architecture Nortel Networks email: babiarz@nortelnetworks.com Tel: (613) 763-6098 ESN:393-6098 -----Original Message----- From: Chan, Kwok-Ho [BL60:470:EXCH] Sent: Sunday, October 26, 2003 2:08 PM To: Internet-Drafts@ietf.org Cc: Fred Baker; Babiarz, Jozef [CAR:0S03:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH] Subject: draft-baker-diffserv-basic-classes-01.txt submission This is a submission of an update to an existing individual draft. Title: Configuration Guidelines for DiffServ Service Classes Filename: draft-baker-diffserv-basic-classes-01.txt Abstract: This paper summarizes the recommended correlation between service classes and their usage, with references to their corresponding recommended Differentiated Service Code Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB) and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioner PHBs and AQM be used for a certain service class, but as a policy it is useful that they be applied consistently across the network. If there is any question or problem related to this submission, please contact: Kwok Ho Chan E-Mail: khchan@nortelnetworks.com Phone: 978-288-8175 Thank You! -- Kwok -- ------_=_NextPart_001_01C39CA0.9ED70D20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: draft-baker-diffserv-basic-classes-01.txt submission

Please find attached an update to the existing = individual draft on Configuration Guidelines for DiffServ Serivce = Classes that was submitted to IETF.

I tried to address all the issues and concerns rased = in the update. Please review and provide comments.

Regards, Joe.
Jozef Babiarz
QoS and Network Architecture
Nortel Networks
email: babiarz@nortelnetworks.com
Tel: (613) 763-6098 ESN:393-6098

-----Original Message-----
From: Chan, Kwok-Ho [BL60:470:EXCH]
Sent: Sunday, October 26, 2003 2:08 PM
To: Internet-Drafts@ietf.org
Cc: Fred Baker; Babiarz, Jozef [CAR:0S03:EXCH]; = Chan, Kwok-Ho [BL60:470:EXCH]
Subject: draft-baker-diffserv-basic-classes-01.txt = submission

This is a submission of an update to an existing = individual draft.

Title:
    Configuration Guidelines for = DiffServ Service Classes

Filename:
    = draft-baker-diffserv-basic-classes-01.txt

Abstract:
    This paper summarizes the = recommended correlation between service
    classes and their usage, with = references to their corresponding
    recommended Differentiated = Service Code Points (DSCP), traffic
    conditioners, Per-Hop Behaviors = (PHB) and Active Queue Management
    (AQM) mechanisms. There is no = intrinsic requirement that particular
    DSCPs, traffic conditioner PHBs = and AQM be used for a certain
    service class, but as a policy it = is useful that they be applied
    consistently across the = network.

If there is any question or problem related to this = submission,
please contact:
Kwok Ho Chan
E-Mail:  khchan@nortelnetworks.com
Phone:  978-288-8175

Thank You!
-- Kwok --

  ------_=_NextPart_001_01C39CA0.9ED70D20-- ------_=_NextPart_000_01C39CA0.9ED70D20 Content-Type: text/plain; x-mac-type="42494E41"; x-mac-creator="74747874"; name="draft-baker-diffserv-basic-classes-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-baker-diffserv-basic-classes-01.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Internet Draft Fred Baker draft-baker-diffserv-basic-classes-01.txt Cisco Expires: April 2004 Jozef Babiarz Kwok Ho Chan Nortel Networks October 2003 =20 Configuration Guidelines for DiffServ=20 Service Classes=20 =20 =20 Status of this Memo =20 This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts = as reference material or to cite them other than as "work in=20 progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html. =20 =20 Copyright Notice=20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 =20 Abstract=20 =20 This paper summarizes the recommended correlation between service=20 classes and their usage, with references to their corresponding=20 recommended Differentiated Service Code Points (DSCP), traffic=20 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management=20 (AQM) mechanisms. There is no intrinsic requirement that particular=20 DSCPs, traffic conditioner PHBs and AQM be used for a certain=20 service class, but as a policy it is useful that they be applied=20 consistently across the network.=20 =20 Conventions used in this document =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = in this document are to be interpreted as described in [RFC-2119]. = =20 =20 Babiarz et al. Expires April 2004 [Page 1]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 =20 =20 =20 =20 Table of Contents=20 =20 1. Introduction....................................................3 = 1.1 Expected use in the Network....................................3 = 1.2 Key Differentiated Services Concepts...........................4 = 1.2.1 Queuing......................................................4 = 1.2.1.1 Priority Queuing...........................................4 = 1.2.1.2 Rate Queuing...............................................4 = 1.2.2 Active Queue Management......................................5 = 1.2.3 Traffic Conditioning.........................................5 = 1.2.4 Differentiated Services Code Point (DSCP)....................6 = 1.2.5 Per-Hop Behavior (PHB).......................................6 = 1.3 Key Service Concepts...........................................6 = 1.3.1 Default Forwarding (DF)......................................7 = 1.3.2 Assured Forwarding (AF)......................................8 = 1.3.3 Expedited Forwarding (EF)....................................8 = 1.3.4 Class Selector (CS)..........................................9 = 1.3.5 Admission Control............................................9 = 1.3.6 Service Differentiation.....................................10 = 2. Traffic Categories and Service Classes.........................10 = 3. Network Control Traffic Category...............................14 = 3.1 Administration Service Class..................................14 = 3.2 Network Control Service Class.................................15 = 4. User Traffic Categories........................................16 = 4.1 Interactive Traffic Category..................................17 = 4.1.1 Telephony Service Class.....................................17 = 4.1.2 Multimedia Conferencing Service Class.......................20 = 4.2 Responsive Traffic Category...................................22 = 4.2.1 Multimedia Streaming Service Class..........................22 = 4.2.2 Low Latency Data Service Class..............................24 = 4.3 Timely Traffic Category.......................................26 = 4.3.1 High Throughput Data Service Class..........................26 = 4.3.2 Standard Service Class......................................28 = 4.4 Non-Critical Traffic Category.................................29 = 4.4.1 Low Priority Data Service Class.............................29 = 5. Mapping Applications to Service Classes........................29 = 6. Security Considerations........................................30 = 7. Acknowledgements...............................................31 = 8. Normative References...........................................31 = 9. Informative References.........................................32 = 10. Author's Address..............................................33 = 11. Full Copyright Statement......................................34 = =20 =20 =20 =20 Babiarz et al. Expires April 2004 [Page 2]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 1. Introduction =20 =20 This paper summarizes the recommended correlation between service=20 classes and their usage, with references to their corresponding=20 recommended Differentiated Service Code Points (DSCP), traffic=20 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management=20 (AQM) mechanisms. There is no intrinsic requirement that particular=20 DSCPs, traffic conditioner PHBs and AQM be used for a certain=20 service class, but as a policy it is useful that they be applied=20 consistently across the network.=20 =20 Service classes are defined, based on the different traffic=20 characteristics and required performance of the=20 applications/services. This approach allows us to map current and=20 future applications/services of similar traffic characteristic and=20 performance requirements into the same service class. With this=20 approach, a limited set of service classes is required. For=20 completeness, we have defined nine different service classes, two=20 for network operation/administration and seven for user/subscriber=20 applications/services. However, we expect that network=20 administrators will selectively choose the service classes that are=20 required in their network based on their needs.=20 =20 1.1 Expected use in the Network=20 =20 In the Internet today, corporate LANs and ISP WANs are generally not = heavily utilized - they are commonly 10% utilized at most. For this=20 reason, congestion, loss, and variation in delay within corporate=20 LANs and ISP backbones is virtually unknown. This clashes with user=20 perceptions, for three very good reasons.=20 =20 - The industry moves through cycles of bandwidth boom and=20 bandwidth bust, depending on prevailing market conditions and=20 the periodic deployment of new bandwidth-hungry applications.=20 =20 - In access networks, the state is often different. This may be=20 because throughput rates are artificially limited, or because of = access network design trade-offs.=20 =20 - Other characteristics, such as database design on web servers=20 (which may create contention points, e.g. in filestore), and=20 configuration of firewalls and routers, often look externally=20 like a bandwidth limitation.=20 =20 The intent of this document is to provide a consistent marking,=20 conditioning and packet treatment strategy so that it can be=20 configured and put into service on any link which finds itself=20 congested.=20 =20 =20 Babiarz et al. Expires April 2004 [Page 3]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 1.2 Key Differentiated Services Concepts=20 =20 The reader must be familiar with the principles of the=20 Differentiated Services Architecture [8]. However, we recapitulate=20 key concepts here so save searching.=20 =20 1.2.1 Queuing =20 =20 A queue is a data structure that holds traffic that is awaiting=20 transmission. The traffic may be delayed while in the queue,=20 possibly due to lack of bandwidth, or because it is low in priority. = There are a number of ways to implement a queue; in some of these,=20 it is more natural to discuss "service classes in a queuing system"=20 rather than "a set of queues and a scheduler". In the literature, as = a result, the concepts are used somewhat interchangeably. =20 =20 A simple model of a queuing system, however, is a set of data=20 structures for packet data, which we will call queues or service=20 classes and a mechanism for selecting the next packet from among=20 them, which we call a scheduler.=20 =20 1.2.1.1 Priority Queuing=20 =20 A priority queuing system is a combination of a set of queues and a=20 scheduler that empties them in priority sequence. When asked for a=20 packet, the scheduler inspects the highest priority queue, and if=20 there is data present returns a packet from that queue. Failing=20 that, it inspects the next highest priority queue, and so on. A=20 freeway onramp with a stoplight for one lane, but which allows=20 vehicles in the high occupancy vehicle lane to pass, is an example=20 of a priority queuing system; the high occupancy vehicle lane=20 represents the "queue" having priority. =20 =20 In a priority queuing system, a packet in the highest priority queue = will experience a readily calculated delay - it is proportional to=20 the amount of data remaining to be serialized when the packet=20 arrived plus the volume of the data already queued ahead of it in=20 the same queue. The technical reason for using a priority queue=20 relates exactly to this fact: it limits delay and variations in=20 delay, and should be used for traffic which has that requirement. =20 =20 A priority queue or queuing system needs to support rate and burst=20 size control mechanism(s) to provide starvation avoidance of lower=20 priority queues.=20 =20 1.2.1.2 Rate Queuing=20 =20 Similarly, a rate-based queuing system is a combination of a set of=20 queues and a scheduler that empties each at a specified rate. An=20 =20 Babiarz et al. Expires April 2004 [Page 4]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 example of a rate based queuing system is a road intersection with a = stoplight - the stoplight acts as a scheduler, giving each lane a=20 certain opportunity to pass traffic through the intersection. =20 =20 In a rate-based queuing system, such as WFQ[27][26] or WRR[28], the=20 delay that a packet in any given queue will experience is dependant=20 on the parameters and occupancy of its queue and the parameters and=20 occupancy of the queues it is competing with. A queue whose traffic=20 arrival rate is much less than the rate at which it lets traffic=20 depart will tend to be empty and packets in it will experience=20 nominal delays. A queue whose traffic arrival rate approximates or=20 exceeds its departure rate will tend to be not empty, and packets in = it will experience greater delay. Such a scheduler can impose a=20 minimum rate, a maximum rate, or both, on any queue it touches. =20 =20 1.2.2 Active Queue Management=20 =20 "Active queue management" or AQM is a generic name for any of a=20 variety of procedures that use packet dropping or marking to manage=20 the depth of a queue. The canonical example of such a procedure is=20 Random Early Detection [25], in which a queue is assigned a minimum=20 and maximum threshold, and the queuing algorithm maintains a moving=20 average of the queue depth. While the mean queue depth exceeds the=20 maximum threshold, all arriving traffic is dropped. While the mean=20 queue depth exceeds the minimum threshold but not the maximum=20 threshold, a randomly selected subset of arriving traffic is marked=20 or dropped. This marking or dropping of traffic is intended to=20 communicate with the sending system, causing its congestion=20 avoidance algorithms to kick in. As a result of this behavior, it is = reasonable to expect that TCP's cyclic behavior is desynchronized,=20 and the mean queue depth (and therefore delay) should normally=20 approximate the minimum threshold. =20 =20 A variation of the algorithm is applied in Assured Forwarding [11],=20 in which the behavior aggregate consists of traffic with multiple=20 DSCP marks, which are intermingled in a common queue. Different=20 minima and maxima are configured for the several DSCPs separately,=20 such that traffic which exceeds a stated rate at ingress is more=20 likely to be dropped or marked than traffic which was within its=20 contracted rate. =20 =20 1.2.3 Traffic Conditioning =20 =20 Additionally, at the first router in a network that a packet=20 crosses, arriving traffic may be measured, and dropped or marked=20 according to a policy, or perhaps shaped on network ingress as in A=20 Rate Adaptive Shaper for Differentiated Services [23]. This may be=20 used to bias feedback loops, such as is done in Assured Forwarding=20 [11], or to limit the amount of traffic in a system, as is done in=20 Expedited Forwarding [19]. Such measurement procedures are=20 =20 Babiarz et al. Expires April 2004 [Page 5]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 collectively referred to as "traffic conditioners". Two traffic=20 conditioners that are use in deployment of differentiated services=20 that use Assured Forwarding are the Two Rate Three Color Marker=20 (trTCM) [18] and the Single Rate Three Color Marker (srTCM) [17]. =20 =20 Two Rate Three Color Marker:=20 The Two Rate Three Color Marker (trTCM) meters an IP packet stream = and marks its packets based on two rates, Peak Information Rate=20 (PIR) and Committed Information Rate (CIR), and their associated=20 burst sizes to be green, yellow, or red. A packet is marked red = if=20 it exceeds the PIR. Otherwise it is marked either yellow or green = depending on whether it exceeds or doesn't exceed the CIR. The=20 trTCM is use to enforce committed rate separately from Peak=20 Information Rate.=20 =20 Single Rate Three Color Marker:=20 The Single Rate Three Color Marker (srTCM) meters an IP packet=20 stream and marks its packets green, yellow, or red. Marking is=20 based on a Committed Information Rate (CIR) and two associated=20 burst sizes, a Committed Burst Size (CBS) and an Excess Burst Size = (EBS). A packet is marked green if it doesn't exceed the CBS,=20 yellow if it does exceed the CBS, but not the EBS and red=20 otherwise. The srTCM is used to enforce the committed rate and=20 burst length.=20 =20 1.2.4 Differentiated Services Code Point (DSCP)=20 =20 The DSCP is a number in the range 0..63, which is placed into an IP=20 packet to mark it according to the class of traffic it belongs in.=20 Half of these values are earmarked for standardized services, and=20 half of them are available for local definition. =20 =20 1.2.5 Per-Hop Behavior (PHB)=20 =20 In the end, the mechanisms described above are combined to form a=20 specified set of characteristics for handling different kinds of=20 traffic, depending on the needs of the application. This document=20 seeks to identify useful traffic aggregates and specify what PHB=20 should be applied to them.=20 =20 1.3 Key Service Concepts=20 =20 While Differentiated Services is a general architecture that may be=20 used to implement a variety of services, three fundamental services=20 have been defined and characterized for general use. These are basic = service for elastic traffic, the Assured Forwarding service, and the = Expedited Forwarding service for real-time (inelastic) traffic. =20 =20 =20 Babiarz et al. Expires April 2004 [Page 6]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 The terms "elastic" and "real-time" are defined in RFC 1633[2]=20 section 3.1, as a way of understanding broad brush application=20 requirements. This document should be reviewed to obtain a broad=20 understanding of the issues in quality of service, just as RFC=20 2475[8] should be reviewed to understand the data plane architecture = used in today's Internet. =20 =20 The definition of "service class" is, a description of the overall=20 treatment of (or a subset of) a customer's traffic across a=20 particular domain, across a set of interconnected DiffServ Domain=20 (DS) domains, or end-to-end. Service descriptions are covered by=20 administrative policy and services are constructed by applying=20 traffic conditioning to create behavior aggregates which experience=20 a known PHB at each node within the DS domain. A service class=20 provides the specified end-to-end behaviors in the network which=20 will support one or more applications or a set of applications that=20 have similar traffic characteristics and performance requirements.=20 This concept allows grouping of applications of similar traffic=20 characteristics and performance requirements into a common=20 forwarding discipline called a "service class" that provides=20 consistent behavior in the administered network. (Service class=20 definition originates from RFC 2474 [7] section 2 definition of a=20 service)=20 =20 1.3.1 Default Forwarding (DF)=20 =20 The basic services applied to any class of traffic are those=20 described in RFC 2474[7] and RFC 2309[6]. Best Effort Service may be = summarized as "I will accept your packets", with no further=20 guarantees. Packets in transit may be lost, reordered, duplicated,=20 or delayed at random. Generally, networks are engineered to limit=20 this behavior, but changing traffic loads can push any network into=20 such a state.=20 =20 Application traffic in the internet is expected to be "elastic" in=20 nature. By this, we mean that the receiver will detect loss or=20 variation in delay in the network and provide feedback such that the = sender adjusts its transmission rate to approximate available=20 capacity.=20 =20 For basic best effort service, a single DSCP value is provided to=20 identify the traffic, a queue to store it, and active queue=20 management to protect the network from it and to limit delays. The=20 interesting thing is that by giving that queue a higher minimum rate = than its measured arrival rate, we can effectively limit the=20 deleterious effects of congestion on a given class of traffic,=20 transferring them to another class that is perhaps better able to=20 absorb the impact or is considered to be of lower value to the=20 network administration. So, for example, if it is important to=20 service database exchange or transaction traffic in a timely=20 =20 Babiarz et al. Expires April 2004 [Page 7]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 fashion, isolating the traffic into a queue and giving it a=20 relatively high minimum rate will accomplish that. =20 =20 Scavenger, or less than best effort, service can also be provided,=20 for applications with congestion avoidance capabilities and is=20 considered to be of lower value to the network administration then=20 best effort traffic.=20 =20 1.3.2 Assured Forwarding (AF)=20 =20 The Assured Forwarding RFC 2597[11] service is explicitly modeled on = Frame Relay's DE flag or ATM's CLP capability, and is intended for=20 networks which offer average-rate SLAs (as FR and ATM networks do).=20 This is an enhanced Best Effort service; traffic is expected to be=20 "elastic" in nature. The receiver will detect loss or variation in=20 delay in the network and provide feedback such that the sender=20 adjusts its transmission rate to approximate available capacity. =20 =20 For such classes, multiple DSCP values are provided (two or three,=20 perhaps more using local values) to identify the traffic, a common=20 queue or class to store the aggregate and active queue management to = protect the network from it and to limit delays. Traffic is metered=20 as it enters the network, and traffic is variously marked depending=20 on the arrival rate of the aggregate. The premise is that it is=20 normal for users to occasionally use more capacity than their=20 contract stipulates, perhaps up to some bound. However, if traffic=20 must be lost or marked to manage the queue, this excess traffic will = be marked or lost first.=20 =20 1.3.3 Expedited Forwarding (EF)=20 =20 Expedited Forwarding RFC 3246[19] was originally proposed as a way=20 to implement a virtual wire, and can be used in such a manner. It is = an enhanced best effort service: traffic remains subject to loss due = to line errors and reordering during routing changes. However, using = queuing techniques, the probability of delay or variation in delay=20 is minimized. For this reason, it is generally used to carry voice=20 and for transport of data information that requires "wire like"=20 behavior through the IP network. Voice is an inelastic "real-time"=20 application that sends packets at the rate the codec produces them,=20 regardless of availability of capacity. As such, this service has=20 the potential to disrupt or congest a network if not controlled. It=20 also has the potential for abuse. =20 =20 To protect the network, at minimum one must police traffic at=20 various points to ensure that the design of a queue is not over-run, = and then the traffic must be given a low delay queue (often using=20 priority, although it is asserted that a rate-based queue can do=20 this) to ensure that variation in delay is not an issue, to meet=20 application needs.=20 =20 Babiarz et al. Expires April 2004 [Page 8]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 1.3.4 Class Selector (CS)=20 =20 Class Selector provides support for historical codepoint definitions = and PHB requirement. The Class Selector DS field provides a limited=20 backward compatibility with legacy (pre Diffserv) practice, as=20 described in RFC 2474 [7] section 4. Backward compatibility is=20 addressed in two ways. First, there are per-hop behaviors that are=20 already in widespread use (e.g. those satisfying the IPv4 Precedence = queuing requirements specified in [RFC 1812]), and we wish to permit = their continued use in DS-compliant networks. In addition, there are = some codepoints that correspond to historical use of the IP=20 Precedence field and we reserve these codepoints to map to PHBs that = meet the general requirements specified in RFC 2474 Sec. 4.2.2.2.=20 =20 No attempt is made to maintain backward compatibility with the "DTR" = or TOS bits of the IPv4 TOS octet, as defined in [RFC 791].=20 =20 A DS-compliant network can be deployed with a set of one or more=20 Class Selector Compliant PHB groups. As well, network administrator = may configure the network nodes to map codepoints to PHBs=20 irrespective of bits 3-5 of the DSCP field to yield a network that=20 is compatible with historical IP Precedence use. Thus, for example,=20 codepoint '011000' would map to the same PHB as codepoint '011010'.=20 =20 1.3.5 Admission Control=20 =20 Admission control including refusal when policy thresholds are=20 crossed, can assure high quality communication by ensuring the=20 availability of bandwidth to carry a load. Inelastic real-time flows = like VoIP (telephony) or video conferencing services can benefit=20 from use of admission control mechanism, as generally the telephony=20 service is configured with over subscription, meaning that some=20 user(s) may not be able to make a call during peak periods.=20 =20 For VoIP (telephony) service, a common approach is to use signaling=20 protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. to negotiate = admittance and usage of network transport capabilites. When a user=20 has been authorized to send voice traffic, this admission procedure=20 has verified that data rates will be within the capacity of the=20 network that it will use. Since RTP voice does not respond to loss=20 or marking in any substantive way, the network must police at=20 ingress to ensure that the voice traffic stays within its negotiated = bounds. Having thus assured a predictable input rate, the network=20 may use a priority queue to ensure nominal delay and variation in=20 delay.=20 =20 Another approach that may be used in small and bandwidth constrained = networks for limited number of flows is RSVP[4][13]. However, there=20 is concern with the Scalability [5] of this solution in large=20 networks and Aggregation [15] of sessions is considered to be a=20 requirement.=20 =20 Babiarz et al. Expires April 2004 [Page 9]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 1.3.6 Service Differentiation=20 =20 There are practical limits on the level of service differentiation=20 that should be offered in the IP networks. We believe we have=20 defined a practical approach in delivering service differentiation=20 by defining different service classes that networks may choose to=20 support to provide the appropriated level of behaviors and=20 performance needed by current and future applications and services.=20 The defined structure for providing services allows several=20 applications having similar traffic characteristics and performance=20 requirements to be grouped into one service class and therefore=20 forwarded by single queue in a router. Also we provide a method for=20 different application (flows) within a service class to have unique=20 DSCP marking so that different conditioning and policing polices may = be used for different flows, through the use of Class Selector (CS)=20 codepoints or locally defined DSCP (EXP/LU) values and associating=20 them with the standardized PHBs. This approach provides a lot of=20 flexibility in providing the appropriate level of service=20 differentiation for current and new yet unknown applications without = introducing significant changes to routers or network configurations = when new traffic type is added to the network. =20 =20 2. Traffic Categories and Service Classes=20 =20 This document divides traffic into five categories, one for network=20 control and four for user/subscriber traffic. The term "user" and=20 "subscriber" are used interchangeable in this document. Network=20 control traffic can further be divided into two service classes,=20 mainly flows that are critical, require lower delay or higher=20 probability of being serviced and normal network control flows. =20 User/subscriber traffic is broken down into four user traffic=20 categories, interactive, responsive, timely and non-critical as=20 defined by ITU-T Recommendation G.1010. These four user traffic=20 categories can further be subdivided into one or more different=20 service classes within each traffic category to provide further=20 behavior differentiation. End-to-end performance requirements for=20 these traffic categories and service classes are further defined in=20 ITU-T Recommendation Y.1541, Y.1540 and G.1010. Additionally,=20 network administrators may choose to define other service classes.=20 =20 The service classes define the required treatment for the traffic in = order to meet user, application or network expectations. Section 3=20 in this document defines the service classes that may be used for=20 forwarding network control traffic and section 4 defines the service = classes that may be used for forwarding user traffic with examples=20 of intended application types mapped into each of their service=20 classes. Note that the application types are only examples and are=20 not meant to be all-inclusive. Also it should be noted that the=20 service class naming or ordering does not imply any priority=20 ordering. They are simply reference names that are used in this=20 document with associated QoS behaviors that are optimized for the=20 =20 Babiarz et al. Expires April 2004 [Page 10]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 particular application types they support. Network administrators=20 may choose to assign different service class names, to the service=20 classes that they will support. Table 1 below defines the=20 relationship between service classes and DS codepoint(s) assignment=20 with application examples.=20 =20 ------------------------------------------------------------------=20 | Service | DSCP | DSCP | Application | = | Class name | name | value | Examples | = = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=20 |Administration | CS7 | 111000 | Heartbeats, SSH, Telnet | = |---------------+---------+-------------+--------------------------| = |Network Control| CS6 | 110000 | Network routing | = |---------------+---------+-------------+--------------------------| = | Telephony | EF,CS5 |101010,101000| IP Telephony | = |---------------+---------+-------------+--------------------------| = | Multimedia |AF41,AF42|100010,100100| Video conferencing | = | Conferencing | AF43 |100110 | Interactive gaming | = |---------------+---------+-------------+--------------------------| = | Multimedia |AF31,AF32|011010,011100|Broadcast TV, Pay per view| = | Streaming |AF33, CS4|011110,100000|Video surveillance | = |---------------+---------+-------------+--------------------------| = | Low Latency |AF21,AF22|010010,010100|Client/server transactions| = | Data |AF23, CS3|010110,011000|peer-to-peer signaling | = |---------------+---------+-------------+--------------------------| = |High Throughput|AF11,AF12|001010,001100|Store&forward applications| = | Data |AF13, CS2|001110,010000|Non-critcal OAM&P | = |---------------+---------+-------------+--------------------------| = | Standard | DF,(CS0)| 000000 | Undifferentiated | = | | | | applications | = |---------------+---------+-------------+--------------------------| = | Low Priority | CS1 | 001000 | Any flow that has no BW | = | Data | | | assurance | = ------------------------------------------------------------------=20 Table 1: DSCP to Service Class Mapping=20 =20 Note: The Class Selector 2,3 and 4 codepoints are aliases of AF11, = AF21 and AF31 codepoints respectfully. Class Selector 5 codepoint=20 is alias of EF codepoint. Default Forwarding and Class Selector 0=20 provide equivalent behavior and use the same DS codepoint.=20 =20 Table 2 provides a summary of DiffServ QoS mechanisms used for the = nine different service classes that are further defined in Section = 3 and 4 of this document. Based on what applications/service that=20 need to be differentiation, network administrators can choose the=20 service class(es) that needs to be supported in their network.=20 =20 Example 1:=20 A network administrator determines that they need in their network = to provide three different levels of network performance (quality=20 of service) for the services that they will be offering to their=20 customers. They need to enable their network to provide reliable=20 =20 Babiarz et al. Expires April 2004 [Page 11]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 VoIP (telephony) service, equivalent to PSTN. A low delay assured=20 bandwidth data service that customers will purchase plus access to = The Internet for basic connectivity. In this example, the network=20 administrator's needs are addressed with the deployment of the=20 following service classes:=20 - Standard service class for all traffic that will receive normal=20 (undifferentiated) forwarding treatment through their network.=20 - Telephony service class for VoIP (telephony) traffic. =20 - Low Latency Data service class for the differentiated data=20 service. =20 - Network Control service class for routing and control traffic=20 that is needed for reliable operation of the provider's network. = =20 Example 2:=20 A network administrator determines that they need to support two=20 service classes for control and administration of their network=20 plus six levels of service differentiation for user traffic use = the=20 following service classes:=20 - Administration=20 - Network Control=20 - Standard=20 - Telephony=20 - Low Latency Data=20 - High Throughput Data=20 - Multimedia Conferencing=20 - Multimedia Streaming=20 =20 Example 3:=20 An enterprise network administrator determines that thy need to=20 provide seven levels of service differentiation for user traffic=20 plus one for running of their network. They would configure their=20 network to support the following service classes:=20 - Network Control=20 - Telephony=20 - Multimedia Conferencing=20 - Multimedia Streaming=20 - Low Latency Data=20 - High Throughput Data=20 - Standard=20 - Low Priority Data=20 =20 It is expected that network administrators will choose the service = classes that they will support based on their need. Start off with = two or three service classes for user traffic and add others as = the=20 need arises. =20 =20 =20 Babiarz et al. Expires April 2004 [Page 12]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 ------------------------------------------------------------------=20 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| = | Class | | DS Edge |Reference| | | = = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D|=20 |Administration | CS7 |Police using sr+bs | RFC2474 |Priority| No | = |---------------+------+-------------------+---------+--------+----| = |Network Control| CS6 |Police using sr+bs | RFC2474 | Rate | No | = |---------------+------+-------------------+---------+--------+----| = | Telephony |EF,CS5|Police using sr+bs | RFC3246 |Priority| No | = |---------------+------+-------------------+---------+--------+----| = | | AF41 | | | | Yes| = | Multimedia | AF42 | Using trTCM | RFC2597 | Rate | per| = | Conferencing | AF43 | (RFC2698) | | |DSCP| = |---------------+------+-------------------+---------+--------+----| = | | AF31 | Police using sr+bs| | | | = | |------+-------------------| | | Yes| = | Multimedia | AF32 | Police sum using | | Rate | per| = | Streaming | AF33 | sr+bs | RFC2597 | |DSCP| = | |------+-------------------| | |----| = | | CS4 |Police using sr+bs | | | No | = |---------------+------+-------------------+---------+--------+----| = | | AF21 | | | | Yes| = | Low | AF22 | Using srTCM | | | per| = | Latency | AF23 | (RFC 2697) | RFC2597 | Rate |DSCP| = | Data |------+-------------------| | |----| = | | CS3 |Police using sr+bs | | | No | = |---------------+------+-------------------+---------+--------+----| = | | AF11 | | | | Yes| = | High | AF12 | Using srTCM | | | per| = | Throughput | AF13 | (RFC 2697) | RFC2597 | Rate |DSCP| = | Data |------+-------------------| | |----| = | | CS2 |Police using sr+bs | | | No | = |---------------+------+-------------------+---------+--------+----| = | Standard | DF | Not applicable | RFC2474 | Rate | Yes| = |---------------+------+-------------------+---------+--------+----| = | Low Priority | CS1 | Not applicable | pdb-le | Rate | Yes| = | Data | | | -draft | | | = ------------------------------------------------------------------=20 Table 2: Summary of QoS Mechanisms used for each Service Class=20 =20 Note: Conditioning at DS edge, means that traffic conditioning is=20 performed at the edge of the DiffServ network where untrusted=20 user/devices are connected or between two DiffServ networks. =20 =20 Note: "sr+bs" represents a policing mechanism that provides single = rate with burst size control. =20 =20 =20 =20 =20 =20 Babiarz et al. Expires April 2004 [Page 13]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 3. Network Control Traffic Category=20 =20 Network control traffic is defined as packet flows that are=20 essential for stable operation of the administered network as well=20 for information that may be exchanged between neighboring networks=20 across a peering point where SLAs are in place. Network control=20 traffic is different from user application control (signaling) that=20 may be generated by some applications or services. Network control=20 traffic is mostly between routers and network nodes that are used=20 for administering, controlling or managing the network segments and=20 the services that are provided in that network segment. A network=20 administrator may choose to split the network control traffic into=20 two service classes i.e., Administration and Network Control to=20 provide two different forwarding treatments or just support one=20 forwarding treatment for all network control flows.=20 =20 3.1 Administration Service Class=20 =20 The Administration service class is intended to be used for control=20 traffic that is within a single administrative network domain. If=20 such traffic does not get through, the administered network domain=20 may not function properly. Example of such type of traffic is=20 heartbeats between core network switches/routers. Such heartbeats=20 are used to determine if the next hop is reachable. If no heartbeat=20 is received within a specified time interval, then the sending=20 router assumes that the particular link or next hop node is=20 unreachable on a particular interface and subsequently reroutes the=20 traffic to a backup interface that can reach the next hop node. =20 This reroute is typically done in a time interval much shorter than=20 the time it would take for the routing protocol to determine that=20 the next hop node is unreachable.=20 =20 The Administration service class uses the DiffServ Class Selector=20 (CS) PHB defined in RFC 2474 [7] and should be configured to receive = sufficed forwarding resources so that all packets are forwarded=20 quickly. The Administration service class should be configured to=20 use Priority Queuing system such as defined in Section 1.2.1.1 of=20 this document. =20 =20 The following protocols and application should use the=20 Administration service class:=20 - Network administrator's telnet sessions from secure and trusted=20 terminals, Secure Shell (SSH)=20 - Protocol(s) that are transmitted between nodes within the=20 administered network for detecting of link and nodal failures=20 - Used for critical control traffic within an administrative=20 domain=20 - May be used for any control traffic that is forwarded within the = administered network domain such as NTP information that=20 requires very low delay variation (jitter)=20 - User traffic must not be mapped into this service class=20 =20 Babiarz et al. Expires April 2004 [Page 14]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 - Inter-network domain (across peering points) control traffic=20 should not be mapped into this service class=20 =20 Traffic characteristics of packet flows in the Administration=20 service class:=20 - Mostly messages between routers and network servers=20 - Typically small packet sizes, one packet at a time=20 - Packets require immediate forwarding =20 - No user-to-user traffic is allowed to use this service class=20 =20 Recommended DSCP marking is CS7 (Class Selector 7)=20 =20 Network edge conditioning:=20 - Drop or remark CS7 marked packets at ingress to DiffServ network = domain. =20 - Depending on policy within the administered network, CS7 marked=20 packets may be dropped or remarked to CS6 at egress of DiffServ=20 network or across peering points.=20 =20 3.2 Network Control Service Class=20 =20 The Network Control service class is used for transmitting packets=20 between network devices (routers, servers, etc.) that require=20 control information to be exchanged between different administrative = domains (across a peering point) and for non-critical network=20 control information exchange within one administrative domain.=20 Traffic transmitted in this service class is very important as it=20 keeps the network operational and needs to be forwarded in a timely=20 manner.=20 =20 The Network Control service class uses the DiffServ Class Selector=20 (CS) PHB defined in RFC 2474 [7]. This service class is configured=20 so that the traffic receives a minimum bandwidth guarantee, to=20 ensure that the packets always receive timely service. The=20 configured forwarding resources for Network Control service class=20 should be such that the probability of packet drop under peak load=20 is very low in this service class. The Network Control service class = should be configured to use Rate Queuing system such as defined in=20 Section 1.2.1.2 of this document.=20 =20 The following protocols and applications should use the Network=20 Control service class:=20 - Routing packet flows, OSPF, BGP, ISIS, RIP=20 - Policy management flows between nodes in the network, COPS,=20 RSVP-TE, etc.=20 - SIP-T signaling between high capacity telephony call servers or=20 soft switches. Such high capacity devices may control thousands = of telephony (VoIP) calls. =20 - Network services, DNS, DHCP, BootP, high priority OAM (SNMP)=20 like alarms, etc.=20 =20 Babiarz et al. Expires April 2004 [Page 15]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 - Used for control information exchange within and between=20 different administrative domains across a peering point where=20 SLAs are in place.=20 - In 3GPP wireless solutions, used to transport UMTS=20 signaling/control information between wireless nodes=20 - User traffic must not be mapped into this service class=20 =20 Traffic characteristics of packet flows in the Network Control=20 service class:=20 - Mostly messages between routers and network servers=20 - Ranging from 50 to 1,500 byte packet sizes, normally one packet=20 at a time but traffic can also burst (BGP)=20 - No user-to-user traffic is allowed to use this service class=20 =20 Recommended DSCP marking is CS6 (Class Selector 6)=20 =20 Network edge conditioning:=20 - At peering points (between two DiffServ networks) where SLAs are = in place, CS6 marked packets are policed using a single rate=20 with burst size (sr+bs) token bucket policer to keep the CS6=20 marked packet flows to within the traffic rate specified in the=20 SLA.=20 - CS6 marked packet flows from untrusted sources (end user=20 devices) are dropped or remarked at ingress to DiffServ network. = Packets from users are not permitted access to the Network=20 Control or Administration service classes.=20 =20 If Administration service class is not supported, then the Network=20 Control service class is used for both normal network control=20 traffic and network administration traffic defined in this document=20 and packets marked with CS7 DSCP receive the same forwarding=20 treatment as CS6 marked packets. =20 =20 4. User Traffic Categories=20 =20 User traffic is divided into four different categories, namely,=20 interactive, responsive and timely. An example of interactive=20 traffic is between two humans and is most sensitive to delay, loss=20 and jitter. Another example of interactive traffic is between two=20 servers where very low delay and loss is needed. Responsive traffic=20 is typically between a human and a server but also can be between=20 two servers. Responsive traffic is less affected by jitter and can=20 tolerate longer delays than interactive traffic. Timely traffic is=20 either between servers or servers and humans and the delay tolerance = is significantly longer than responsive traffic. Non-critical=20 traffic is normal between servers/machines where delivery may be=20 delay for period of time. The Four traffic categories follow=20 methodology defined by ITU-T Recommendation Y.1541 and G.1010. =20 =20 Network administrators can categorize their applications based on=20 the type of behavior that they require. Table 1 provides some=20 =20 Babiarz et al. Expires April 2004 [Page 16]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 common applications and the forwarding service class that best=20 supports them based on their performance requirements. =20 =20 =20 In summary: =20 - Telephony service class is best suited for applications that=20 require very low delay and are of constant rate, such as IP=20 telephony (VoIP) and circuit emulation over IP applications. =20 - Multimedia Conferencing service class is best suited for=20 applications that require very low delay but are of variable=20 rate, such as video conferencing and interactive gaming. =20 - Multimedia Streaming service class is best suited for streaming=20 media applications such as broadcast TV, pay-per-view, video=20 surveillance and security, etc. =20 - Low Latency Data service class is best suited for interactive=20 client / server or client-to-client applications such as web- based ordering, EPR application, peer-to-peer signaling, etc. =20 - High Throughput Data service class is best suited for store and=20 forward applications such as FTP, billing record transfer, etc. = =20 - Standard service class is for traffic that has not bean=20 identified as requiring differentiated treatment and is normally = referred as best effort. =20 - Low Priority Data service class is intended for packet flows=20 where bandwidth assurance is not required. =20 =20 Note, a network administrator may choose to support all or subsets=20 of the defined service classes and provide service differentiation=20 only to the applications/service that are mapped into them. =20 =20 =20 4.1 Interactive Traffic Category=20 =20 Interactive traffic category can be further split into two service=20 classes, Telephony and Multimedia Conferencing to provide=20 differentiation based on the different behavior of source traffic=20 being forwarded. =20 =20 4.1.1 Telephony Service Class =20 =20 Used for applications that require real-time, low delay, very low=20 packet loss for relatively constant-rate traffic sources (inelastic=20 traffic sources). This forwarding class is used predominantly for IP = telephony services and provides the low latency, jitter and loss=20 required.=20 =20 The fundamental service offered to traffic in the Telephony service=20 class is a higher priority service than best-effort up to a=20 specified upper bound with low delay and very low packet loss.=20 Operation is in some respect similar to an ATM CBR service, which=20 has guaranteed bandwidth and if it stays within the negotiated rate=20 =20 Babiarz et al. Expires April 2004 [Page 17]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 it experiences nominal delay and no loss. The EF PHB has a similar=20 guarantee.=20 =20 Typical configurations negotiate the setup of telephone calls over=20 IP using protocols such as H.248, MEGACO, H.323 or SIP. When a user = has been authorized to send telephony traffic, the call admission=20 procedure has verified that the newly admitted data rates will be=20 within the capacity of the Telephony service class forwarding=20 capability in the network that it will use. For VoIP (telephony)=20 service, the common approach is to use call admission control=20 performed by a telephony call server/gatekeeper using signaling=20 (SIP, H.323, H.248, MEGACO, etc.) on access points to the network.=20 The bandwidth in the core network and the number of simultaneous=20 VoIP sessions that can be supported needs to be engineered and=20 controlled so that there is no congestion for this service. Since=20 RTP telephony flows do not respond to loss or substantial delay in=20 any substantive way, the Telephony service class should forward=20 packet as soon as possible. =20 =20 The Telephony service class uses Expedited Forwarding (EF) PHB as=20 defined in RFC 3246 [19] and must be configured to receive=20 guaranteed forwarding resources so that all packets are forwarded=20 quickly. The Telephony service class should be configured to use=20 Priority Queuing system such as defined in Section 1.2.1.1 of this=20 document.=20 =20 Target applications for Telephony service class:=20 - VoIP (G.711, G.729 and other codecs)=20 - Telephony (trunk and/or stimulus) signaling between end device=20 (terminals/gateways) and the call server (H.248, MEGACO)=20 - Lawful Intercept=20 - Voice-band data over IP (modem, fax)=20 - T.38 fax over IP=20 - Circuit emulation over IP, virtual wire, etc.=20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Conversational Traffic Class=20 =20 Traffic characteristics: =20 - Mostly fixed size packets for VoIP (60 or 70 or 120 or 200 bytes = in size)=20 - Packet emitted at constant time intervals=20 - Admission control of new flows is provided by telephony call=20 server, media gateway, gatekeeper, edge router or access node=20 that provides "middlebox" function.=20 =20 Recommended DSCP marking EF for the following applications: =20 - VoIP (G.711, G.729 and other codecs)=20 - Lawful Intercept=20 - Voice-band data over IP (modem)=20 - Circuit emulation over IP, virtual wire, etc.=20 - Conversational UMTS Traffic Class=20 =20 Recommended DSCP marking CS5 for the following applications:=20 =20 Babiarz et al. Expires April 2004 [Page 18]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 - Telephony (trunk and/or stimulus) signaling between end device=20 (terminals/gateways) and the call server (H.248, MEGACO)=20 - T.38 fax over IP=20 =20 Both EF and CS5 DS codepoints are mapped into the Telephony service=20 classes and used the Expedited Forwarding (EF) PHB. The CS5 DS=20 codepoint is aliased to the EF codepoint and packets marked with CS5 = are forwarded using the EF PHB. =20 =20 Network Edge Conditioning:=20 - Packet flows from untrusted sources (end user devices) must be=20 policed at ingress to DiffServ network using single rate with=20 burst size token bucket policer to ensure that the telephony=20 traffic stays within its negotiated bounds. =20 - Packet flows from trusted sources (media gateways inside=20 administered network) do not require policing.=20 - Policing of Telephony packet flows across peering points where=20 SLA is in place is not required as telephony traffic will be=20 controlled by admission control mechanism between peering=20 points. =20 =20 Note: On low speed links (typically access links below 1Mbps), in=20 the attempt to minimize jitter/delay, it is recommended that=20 packetized audio streams are separated from processed telephony data = information flows like T.38 fax and telephony signaling and=20 forwarded using less stringent from delay/jitter perspective service = class. PCM voice when compressed produces very small packets i.e. 60 = bytes in size were T.38 fax and signaling packets can be much=20 bigger. The serialization delay, therefore delay/jitter for the=20 larger T.38 fax and signaling packets can be significantly bigger=20 over low speed links then for 60 byte voice packets. For this reason = it is recommended that packetized voice packets receive a higher=20 priority forwarding treatment then the less sensitive from=20 delay/jitter perspective T.38 fax and telephony signaling packets.=20 PCM audio streams (voice) have a strict end-to-end delay constrain=20 and should use Priority Queuing system where as T.38 fax or=20 telephony signaling have a more liberal jitter/delay constrain and=20 should use Rate Queuing system on access links below 1 Mbps. =20 =20 On higher speed links the difference in serialization delay is very=20 small, therefore both types of telephony packet flows are aggregated = in to a single forwarding service class to simplify network=20 engineering and use Priority Queuing system. As well, the forwarding = of voice packets and signaling packets with the same very low delay=20 forwarding service class minimizes delay as well as the difference=20 in delay between signaling and bearer path, therefore virtually=20 eliminating speech clipping and ring-clipping problems at start of=20 call when interfacing to PSTN. =20 =20 =20 =20 Babiarz et al. Expires April 2004 [Page 19]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 4.1.2 Multimedia Conferencing Service Class=20 =20 Used for applications that requires real-time and low delay for=20 variable rate elastic traffic source. The traffic sources=20 (applications) in this traffic class have the capability to change=20 their emitting rate based on feedback received from the receiving=20 end. Detection of packet loss by the receiver is sent using the=20 applications control stream to the transmitter as an indication of=20 possible congestion. The transmitter based on pre-configured=20 encoding rates (or transmitting rates) selects a lower rate for=20 transmission. =20 =20 Typical video conferencing configurations negotiate the setup of=20 multimedia session using protocols such as H.323 or SIP. When a=20 user/end-point has been authorized to start a multimedia session the = admission procedure has verified that the newly admitted data rates=20 will be within the engineered capacity of the Multimedia=20 Conferencing service class. The bandwidth in the core network and=20 the number of simultaneous video conferencing sessions that can be=20 supported needs to be engineered to control traffic load for this=20 service. =20 =20 The Multimedia Conferencing service class uses the Assured=20 Forwarding (AF) PHB defined in RFC 2597 [11]. This service class is=20 configured to provide a bandwidth assurance for AF41, AF42, and AF43 = marked packets to ensure that they get forwarded. The Multimedia=20 Conferencing service class should be configured to use Rate Queuing=20 system such as defined in Section 1.2.1.2 of this document.=20 =20 Target application for Multimedia Conferencing service class:=20 - Video conferencing (interactive video)=20 - Interactive gaming=20 - Server to server data transfer requiring very low delay=20 - IP VPN service that specifies two rates and mean network delay=20 that is slightly longer then network propagation delay.=20 Interactive, time critical and mission critical application=20 maybe encapsulated into this VPN service.=20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Interactive Traffic Class with Traffic=20 Handling Priority 1 (THP=3D1) =20 =20 Traffic characteristics: =20 - Variable size packets (50 to 1500 bytes in size)=20 - Higher the rate, higher density of large packets=20 - Variable packet emission time =20 - Source capable of reducing its transmission rate based on=20 detection of packet loss at the receiver=20 =20 Packet Marking:=20 - Interactive gaming packets are marked with AF41=20 - Video conferencing packets are marked with AF4x=20 =20 Babiarz et al. Expires April 2004 [Page 20]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 - VPN service may be marked with AF4x depending on the service=20 characteristics=20 - Server to server data transfer with AF4x depending on the=20 service characteristics=20 - UMTS Interactive THP=3D1 packets are marked with AF4x=20 =20 Packet flows from video conferencing equipment may be marked at=20 source by the video conferencing equipment or by the edge router=20 using Two Rate Three Color Marked (trTCM) as specified in RFC 2698=20 [18].=20 =20 Example of DSCP marking when performed by video conferencing=20 equipment:=20 - AF41 =3D H.323 video conferencing audio stream RTP/UDP=20 - AF41 =3D H.323 video conferencing video control RTCP/TCP=20 - AF41 =3D H.323 video conferencing video stream below specified=20 rate "A"=20 - AF42 =3D H.323 video conferencing video stream between specified = rate "A" and "B"=20 - AF43 =3D H.323 video conferencing video stream above specified=20 rate "B"=20 - Where rate "B" is greater in magnitude than rate "A"=20 =20 Conditioning Performed at DiffServ Network Edge:=20 The Two Rate Three Color Marker (trTCM) should be used as = specified=20 in RFC 2698 [18].=20 =20 If packets are marked by the sources or previous DiffServ domain,=20 then the trTCM should be configured to operate in Color-Aware = mode.=20 =20 If the packets are not marked by the source or previous DiffServ=20 domain, then the trTCM must be configured to operate in = Color-Blind=20 mode.=20 =20 The fundamental service offered to "Multimedia Conferencing" traffic = is best effort service with controlled rate and delay. Some traffic=20 in this service class may not respond dynamically to packet loss.=20 For video conferencing service, typically a 1% packet loss detected=20 at the receiver triggers encoding rate change, drop to next lower=20 provisioned video encoding rate. As such, Active Queue Management=20 [6] is used primarily to switch video encoding rate under=20 congestion, change from high rate to lower rate i.e. 1472 kbps to=20 768 kbps. The probability of loss of AF41 traffic may not exceed the = probability of loss of AF42 traffic, which in turn may not exceed=20 the probability of loss of AF43 traffic. =20 =20 =20 =20 =20 =20 =20 Babiarz et al. Expires April 2004 [Page 21]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 4.2 Responsive Traffic Category=20 =20 Responsive traffic category can be further split into two service=20 classes, Multimedia Streaming and Low Latency Data to provide=20 differentiation based on the different behavior of source traffic=20 being forwarded. =20 =20 =20 =20 4.2.1 Multimedia Streaming Service Class =20 =20 The Multimedia Streaming service class is used for applications that = require near-real-time packet forwarding of variable rate traffic=20 sources which are not as delay sensitive as applications using the=20 Multimedia Conferencing service class. Such applications include=20 broadcast TV, streaming audio and video, video (movies) on demand=20 and surveillance video. In general, the Multimedia Streaming=20 service class assumes that the traffic is buffered at the=20 source/destination and therefore, is less sensitive to delay and=20 jitter.=20 =20 The Multimedia Streaming service class uses the Assured Forwarding=20 (AF) PHB defined in RFC 2597 [11]. This service class is configured=20 to provide a minimum bandwidth assurance for AF31, AF32, AF33 and=20 CS4 marked packets to ensure that they get forwarded. The Multimedia = Streaming service class should be configured to use Rate Queuing=20 system such as defined in Section 1.2.1.2 of this document.=20 =20 Target application for Multimedia Streaming service class:=20 - Video surveillance and security (unicast)=20 - TV broadcast including HDTV (multicast)=20 - Pay per view movies and events (pre scheduled)=20 - Video on demand (unicast) with control (virtual DVD)=20 - Streaming audio (unicast)=20 - Streaming video (unicast)=20 - Web casts=20 - VPN service that supports different levels of flow assurance=20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Streaming Traffic Class =20 =20 Traffic Characteristics:=20 - Variable size packets (50 to 4196 bytes in size)=20 - Higher the rate, higher density of large packets=20 - Variable packet emission rate =20 - Some bursting at start of flow from some applications=20 - At about 2% packet loss, video session is usually terminated=20 =20 Both the AF3x and CS4 DS codepoints are mapped into the Multimedia=20 Streaming service classes and used the Assured Forwarding (AF) PHB=20 however, Active Queue Management (AQM) mechanism is not applied in=20 the router(s) to CS4 market packets. =20 =20 Babiarz et al. Expires April 2004 [Page 22]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 =20 Applications or end systems pre-mark their packets with DSCP values=20 as shown in Table 3 below. If host is unable to pre-mark their=20 packets, then marking is performed on the DiffServ edge router using = MF classification. Due to the nature of the service, it is=20 recommended that video surveillance and security flows are market=20 with a different DSCP value so that traffic conditioning and=20 policing policies can be different from other flows in the=20 Multimedia Streaming service class.=20 =20 ------------------------------------------------------------------=20 | Applications | Protocol |DSCP| = |------------------------------------+------------------------+----| = |Video surveillance and security |For RTP/UDP payload and |CS4 | = | (unicast) |RTSP/TCP control streams| | = |------------------------------------+------------------------+----| = |TV broadcast (multicast), pay per |For RTP/UDP payloads and| | = |view movies and events (multicast) |RTSP/TCP control streams|AF31| = |Video on demand(unicast)with control| | | = |------------------------------------+------------------------+----| = | | For RTP/UDP streams |AF33| = | |------------------------+----| = | Video clips (unicast), premium WEB | For RTP/TCP streams |AF32| = | casts, etc. |------------------------+----| = | | RTP/TCP or HTTP control|AF32| = |------------------------------------+------------------------+----| = | | For RTP/UDP streams |AF33| = | |------------------------+----| = | Audio streaming (unicast) | For RTP/TCP streams |AF32| = | |------------------------+----| = | |RTSP/TCP or HTTP control|AF31| = |------------------------------------+------------------------+----| = | VPN service that support different | |AF31| = | levels of assurance |Implementation dependent|AF32| = | | |AF33| = |------------------------------------+------------------------+----| = | | |AF31| = | UMTS Streaming packets | GPRS tunnel over IP |AF32| = | | |AF33| = ------------------------------------------------------------------=20 Table 3: Example of DSCP marking for Multimedia Streaming=20 =20 Network Edge Conditioning:=20 Packet flows from untrusted sources must be policed at the = DiffServ=20 network edge using single rate policers with a burst size control=20 for AF31, AF32, AF33 and CS4 marked packets. Policing policy is=20 based on the SLA for supported application(s). For the above=20 defined applications, three single rate policers with burst size=20 control should be provided; one for CS4 marked packets, another = for=20 AF31 marked packets and the third policer for AF32 and AF33 marked = packets. Packet flows from trusted sources i.e. TV broadcast=20 servers, etc. normally do not require policing.=20 =20 Babiarz et al. Expires April 2004 [Page 23]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 =20 The fundamental service offered to "Multimedia Streaming" traffic is = best effort service with controlled rate and delay. This traffic=20 does not respond dynamically to packet loss. Packets marked with=20 AF31 and CS4 DSCP requires very high assurance of delivery. Packets=20 marked with AF32 and AF33 can generally tolerated up to 1% and 2%=20 packet loss respectfully. As such, Active Queue Management [6] is=20 used primarily to reduce the number of flows at congestion points by = dropping packets from less important flows first before any AF31 and = CS4 marked packets are dropped. The service should be provisioned so = that CS4 and AF31 marked packet flows have high assurance for=20 bandwidth in the network. The probability of loss of CS4 traffic may = not exceed the probability of AF31 and AF31 traffic may not exceed=20 the probability of loss of AF32 traffic, which in turn may not=20 exceed the probability of loss of AF33. =20 =20 4.2.2 Low Latency Data Service Class =20 =20 The Low Latency Data service class is used for elastic and=20 responsive typically client/server based applications. Applications = forwarded by this service class are those requiring a relatively=20 fast response and typically have asymmetrical bandwidth need, i.e.=20 the client typically sends a short message to the server and the=20 server responds with a much larger data flow back to the client. =20 The most common example of this is when a user clicks a hyperlink=20 (~few dozen bytes) on a web page resulting in a new web page to be=20 loaded (Kbytes of data). This service class is configured to provide = good response for TCP [1] short lived flows that require real-time=20 packet forwarding of variable rate traffic sources.=20 =20 The Low Latency Data service class uses the Assured Forwarding (AF)=20 PHB defined in RFC 2597 [11]. This service class is configured to=20 provide a minimum bandwidth assurance for AF21, AF22 and AF23 marked = packets to ensure that they get forwarded. The Low Latency Data=20 service class should be configured to use Rate Queuing system such=20 as defined in Section 1.2.1.2 of this document.=20 =20 Target applications for Low Latency Data service class:=20 - Client / server applications=20 - SNA terminal to host transactions (SNA over IP using DLSw)=20 - Web based transactions (E-commerce)=20 - Credit card transactions=20 - Financial wire transfers=20 - ERP applications (.e.g. SAP / BaaN)=20 - Peer-to-peer signaling (SIP, H.323)=20 - VPN service that supports CIR (Committed Information Rate) with=20 up to two burst sizes =20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Interactive Traffic Class with Traffic=20 Handling Priority 2 (THP=3D2) =20 =20 =20 Babiarz et al. Expires April 2004 [Page 24]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 Traffic Characteristics:=20 - Variable size packets (50 to 1500 bytes in size)=20 - Variable packet emission rate =20 - With packet bursts of TCP window size=20 - Source capable of reducing its transmission rate based on=20 detection of packet loss at the receiver or through explicit=20 congestion notification.=20 =20 Both the AF2x and CS3 DS codepoints are mapped into the Low Latency=20 Data service classes and use the Assured Forwarding (AF) PHB=20 however, Active Queue Management (AQM) mechanism is not applied in=20 router(s) to CS3 market packets.=20 =20 DSCP marking:=20 - Peer-to-peer inelastic SIP, H.323 signaling packer flows are=20 marked with CS3=20 - Elastic TCP flows are marked with AF2x =20 - VPN service may be marked with AF2x or CS3 depending on the=20 service characteristics=20 - UMTS Interactive THP=3D2 packets are marked with AF2x=20 =20 Marking of the DSCP may be performed by a host or by an edge router. = =20 =20 Conditioning Performed at the DiffServ Network Edge:=20 Conditioning may be performed on per-flow or on aggregated-flows=20 depending on the configuration and service offered. Metering and=20 (re)marking of flows is required at DiffServ edge node and on=20 DiffServ boundary node. The Low Latency Data service class uses a = Single Rate Three Color Marker (srTCM) conditioner for AF2x flows. = =20 Conditioning Requirements for AF2x marked packets:=20 Conditioning of aggregated packet flows destined for the Low=20 Latency Data service class must be performed at the DiffServ edge=20 of the network. Furthermore, conditioning should be performed = using=20 Single Rate Three Color Marker (srTCM) as defined in RFC 2697 = [17]. =20 =20 If the packets are not pre-marked then the srTCM must be = configured=20 to operate in the Color-Blind mode.=20 =20 If the packets are pre-marked by the source or previous network=20 (boundary node) then the srTCM should be configured to operate in=20 the Color-Aware mode. =20 =20 Conditioning Requirements for CS3 marked Packets:=20 DiffServ edge and boundary nodes must police CS3 marked packets so = both rate and burst size can be enforced. =20 =20 The fundamental service offered to "Low Latency Data" traffic is=20 best effort service with controlled rate and delay. The service=20 should be engineered so that AF21 and CS3 marked packet flows have=20 sufficed bandwidth in the network to provide high assurance of=20 delivery. Since this traffic is marked with AF2x DSCP is elastic and = responds dynamically to packet loss, Active Queue Management [6] is=20 =20 Babiarz et al. Expires April 2004 [Page 25]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 used primarily to control TCP flow rates at congestion points by=20 dropping packet from TCP flows where the burst length is high. The=20 probability of loss of CS3 traffic may not exceed the probability of = loss of AF21 and AF21 traffic may not exceed the probability of loss = of AF22 traffic, which in turn may not exceed the probability of=20 loss of AF23. Active queue management may also be implemented using=20 Explicit Congestion Notification (ECN) [17] method as defined in RFC = 3168.=20 =20 4.3 Timely Traffic Category=20 =20 Timely traffic category can be further split into two service=20 classes, High Throughput Data and Standard to provide=20 differentiation based on the different behavior of source traffic=20 being forwarded. =20 =20 4.3.1 High Throughput Data Service Class =20 =20 The High Throughput Data service class is configured to support=20 elastic applications that require timely packet forwarding of=20 variable rate traffic sources and more specifically is configured to = provide good throughput for TCP longer lived flows. TCP[1] or a=20 transport with a consistent Congestion Avoidance Procedure[9][10]=20 normally will drive as high a data rate as it can obtain over a long = period of time. The FTP protocol is a common example, although one=20 cannot definitively say that all FTP transfers are moving data in=20 bulk. =20 =20 The High Throughput Data service class uses the Assured Forwarding=20 (AF) PHB defined in RFC 2597 [11]. This service class is configured=20 to provide a minimum bandwidth assurance for AF11, AF12, AF13 and=20 CS2 marked packets to ensure that they are forwarded. The High=20 Throughput Data service class should be configured to use Rate=20 Queuing system such as defined in Section 1.2.1.2 of this document.=20 =20 Target applications for High Throughput Data service class:=20 - Store and forward applications=20 - File transfer applications=20 - Email=20 - Non-critical OAM&P (Operation and Management and Provisioning)=20 using SNMP, XML, etc.=20 - VPN service that supports CIR (Committed Information Rate) with=20 up to two burst sizes =20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Interactive Traffic Class with Traffic=20 Handling Priority 3 (THP=3D3) =20 =20 Traffic Characteristics:=20 - Variable size packets (50 to 1500 bytes in size)=20 - Variable packet emission rate =20 =20 Babiarz et al. Expires April 2004 [Page 26]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 - With packet bursts of TCP window size=20 - Source capable of reducing its transmission rate based on=20 detection of packet loss at the receiver or through explicit=20 congestion notification.=20 =20 Both the AF1x and CS2 DS codepoints are mapped into the High=20 Throughput Data service classes and use the Assured Forwarding (AF)=20 PHB however, Active Queue Management (AQM) mechanism is not applied=20 in router(s) to CS2 market packets.=20 =20 DSCP marking:=20 - Non-critical OAM&P (SNMP, XML, etc.) packets are marked with CS2 = - Elastic TCP flows are marked with AF1x =20 - VPN service may be marked with AF1x or CS2 depending on the=20 service characteristics=20 - UMTS Interactive THP=3D3 packets are marked with AF1x=20 =20 Note: Since the performance requirements for non-critical OAM&P=20 traffic can be met with the High Throughput Data service class and=20 the amount of non-critical OAM&P traffic is normally very small, we=20 recommend that non-critical OAM&P traffic be marked with CS2 DSCP=20 and forwarded using the High Throughput Data service class. The=20 marking of non-critical OAM&P traffic with CS2 DS codepoint is=20 recommended so that different conditioning, policing and queue=20 management policies can be used for non-critical OAM&P.=20 =20 Marking of the DSCP may be performed by a host or by an edge router. = =20 =20 Conditioning Performed at the DiffServ Network Edge:=20 Conditioning may be performed on per-flow or for aggregated flows=20 depending on the configuration and the service offered. Metering=20 and (re)marking of DSCP is required at the DiffServ edge node and=20 on the DiffServ boundary node. The High Throughput Data service=20 class uses a Single Rate Three Color Marker (srTCM) conditioner = for=20 AF1x flows and a single rate policer with a burst size limit for=20 CS2 flows.=20 =20 Conditioning Requirements for AF1x marked Packets:=20 Conditioning of aggregated packet flows destined for the High=20 Throughput Data service class must be performed at the DiffServ=20 edge of the network. Furthermore, conditioning should be performed = as defined in RFC 2697 [17]. =20 =20 If the packets are not pre-marked, then the srTCM must be=20 configured to operate in the Color-Blind mode.=20 =20 If the packets are pre-marked by the source or previous network=20 (boundary node) the srTCM should be configured to operate in the=20 Color-Aware mode.=20 =20 Conditioning Requirements for CS2 marked Packets:=20 DiffServ edge and boundary nodes must police CS2 marked packets so = both rate and burst size can be enforced. =20 =20 Babiarz et al. Expires April 2004 [Page 27]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 =20 The fundamental service offered to "High Throughput Data" traffic is = best effort service with a specified minimum rate. It can be assumed = that this class will consume any available bandwidth, and packets=20 traversing congested links may experience higher queuing delays=20 and/or packet loss. =20 =20 Typical configurations use Explicit Congestion Notification [14] as=20 defined in RFC 3168 or random packet dropping to implement Active=20 Queue Management [6] and may impose a minimum or maximum rate. The=20 probability of loss of AF11 traffic may not exceed the probability=20 of loss of AF12 traffic, which in turn may not exceed the=20 probability of loss of AF13 traffic. Ingress traffic conditioning=20 passes traffic in the class up to some specified threshold marked as = AF11, additional traffic up to some secondary threshold marked as=20 AF12, and potentially passes additional traffic marked as AF13. In=20 such a case, if one network customer is driving significant excess=20 and another seeks to use the link, any losses will be experienced by = the high rate user, causing him to reduce his rate. =20 =20 Packets marked with CS2 DSCP (OAM&P packets) should not be put=20 through Active Queue Management [6] function. =20 =20 4.3.2 Standard Service Class=20 =20 The Standard service class is used for all traffic that has not been = classified into one of the other supported forwarding service=20 classes in the DiffServ network domain. This service class provides=20 the Internet's "best effort" forwarding behavior. This service class = typically has no bandwidth, delay, loss or jitter assurances.=20 The Standard service class uses the Default Forwarding (DF) PHB=20 defined in RFC 2474 [7] and should be configured to receive a small=20 percentage of forwarding resources (at least 5%). This service class = should be configured to use Rate Queuing system such as defined in=20 Section 1.2.1.2 of this document.=20 =20 Target application for the Standard service class:=20 - Any undifferentiated application/packet flow transported through = the DiffServ enabled network=20 - In wireless 3GPP applications, used to forward traffic that is=20 mapped into the UMTS Background Traffic Class =20 =20 Traffic Characteristics:=20 - Non deterministic, mixture of everything=20 =20 The DSCP marking is DF (Default Forwarding)=20 =20 Network Edge Conditioning:=20 There is no requirement that conditioning of packet flows be=20 performed for this service class.=20 =20 =20 Babiarz et al. Expires April 2004 [Page 28]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 The fundamental service offered to the Standard service class is=20 best effort service with active queue management to limit over-all=20 delay. Typical configurations use Explicit Congestion Notification=20 [14] or random packet dropping to implement Active Queue Management=20 [6], and may impose a minimum or maximum rate on the queue.=20 =20 4.4 Non-Critical Traffic Category=20 Non-critical traffic category currently has only one service class=20 defined for differentiation from Standard traffic. When a need arise = other service class could be defined in the future. =20 4.4.1 Low Priority Data Service Class=20 =20 The Low Priority Data service class serves applications which run=20 over TCP [1] or a transport with a consistent congestion avoidance=20 procedure [9][10], and which the user is willing to accept service=20 without guarantees. This service class is specified in [20].=20 =20 Target application for the Low Priority Data service class:=20 - Any TCP based application/packet flow transported through the=20 DiffServ enabled network that does not require any bandwidth=20 assurances.=20 =20 Traffic Characteristics:=20 - Non real-time and elastic.=20 =20 The DSCP marking is CS1 (Class Selector 1)=20 =20 Network Edge Conditioning:=20 There is no requirement that conditioning of packet flows be=20 performed for this service class.=20 =20 The fundamental service offered to the Low Priority Data service=20 class is best effort service with zero bandwidth assurance. By=20 placing it into a separate queue or class, it may be treated in a=20 manner consistent with a specific service level agreement.=20 =20 Typical configurations use Explicit Congestion Notification [14] or=20 random loss to implement active queue management [6]. =20 =20 5. Mapping Applications to Service Classes=20 =20 Here we provide some examples for mapping different applications=20 into the defined service classes.=20 =20 Mapping for Signaling:=20 =20 There are many different signaling protocols, ways that signaling is = used and performance requirements from applications that are=20 controlled by these protocols. Therefore we have determined that the = =20 Babiarz et al. Expires April 2004 [Page 29]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 different signaling protocols be mapped to service classes that best = meet the objectives. The following mapping is recommended:=20 - SIP and H.323 are forwarded using Low Latency Data service class = - H.248 and MEGACO are forwarded using the Telephony service class = - SIP-T signaling between call servers in carrier's network using=20 Network Control service class.=20 - RSVP signaling, depends on the application. If RSVP signaling is = "on-path" as used in InServ or NSIS that it needs to be forward=20 from the same queue (service class) as application data that it=20 is controlling. If it is "off-path" not along the same path as=20 applications data than, Low Latency Data service class should be = used for RSVP signaling.=20 =20 Mapping for NTP:=20 =20 From tests that were performed, indications are that precise time=20 distribution requires a very low packet delay variation (jitter)=20 transport. Therefore we would suggest the following guidelines for=20 NTP be used:=20 - When NTP is used for providing high accuracy timing within=20 administrator's (carrier's) network, the Administration service=20 class should be used and NTP packets be marked with CS7 DSCP.=20 - When NTP is used for providing high accuracy timing to end=20 users/clients than the Telephony service class should be used=20 and NTP packets be marked with CS5 DSCP.=20 - For applications that require "wall clock" timing accuracy, the=20 Standard service class should be used and packets should be=20 marked with DF DSCP.=20 =20 6. Security Considerations=20 =20 This document discusses policy, and describes a common policy=20 configuration, for the use of a Differentiated Services Code Point=20 by transports and applications. If implemented as described, it=20 should require the network to do nothing that the network has not=20 already allowed. If that is the case, no new security issues should=20 arise from the use of such a policy. =20 =20 It is possible for the policy to be applied incorrectly, or for a=20 wrong policy to be applied in the network for the defined service=20 class. In that case, a policy issue exists which the network must=20 detect, assess, and deal with. This is a known security issue in any = network dependent on policy directed behavior. =20 =20 A well known flaw appears when bandwidth is reserved or enabled for=20 a service (for example, voice transport) and another service or an=20 attacking traffic stream uses it. This possibility is inherent in=20 DiffServ technology, which depends on appropriate packet markings.=20 When bandwidth reservation or a priority queuing system is used in a = vulnerable network, the use of authentication and flow admission is=20 recommended. To the author's knowledge, there is no known technical=20 =20 Babiarz et al. Expires April 2004 [Page 30]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 way to respond to an unauthenticated data stream using service that=20 it is not intended to use, and such is the nature of the Internet. =20 =20 =20 7. Acknowledgements=20 =20 The authors acknowledge a great many inputs, most notably from Bruce = Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,=20 Brian E Carpenter, Morgan Littlewood and Al Morton. Kimberly King,=20 Joe Zebarth and Alistair Munroe each did a thorough proof-reading,=20 and the document is better for their contributions.=20 =20 8. Normative References=20 =20 [1] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793,=20 September 1981.=20 =20 [2] BRADEN, B., CLARK, D. and S. SHENKER, "INTEGRATED SERVICES IN=20 THE INTERNET ARCHITECTURE: AN OVERVIEW", RFC 1633, June 1994.=20 =20 [3] BRADNER, S., "KEY WORDS FOR USE IN RFCS TO INDICATE REQUIREMENT = LEVELS", BCP 14, RFC 2119, March 1997.=20 =20 [4] ZHANG, L., BERSON, S., HERZOG, S. and S. JAMIN, "RESOURCE=20 RESERVATION PROTOCOL (RSVP) -- VERSION 1 FUNCTIONAL SPECIFICATION",=20 RFC 2205, September 1997.=20 =20 [5] BAKER, F., KRAWCZYK, J. and A. SASTRY, "RSVP MANAGEMENT=20 INFORMATION BASE USING SMIV2", RFC 2206, September 1997.=20 =20 [6] BRADEN, B., CLARK, D., CROWCROFT, J., DAVIE, B., DEERING, S.,=20 ESTRIN, D., FLOYD, S., JACOBSON, V., MINSHALL, G., PARTRIDGE, C.,=20 PETERSON, L., RAMAKRISHNAN, K., SHENKER, S., WROCLAWSKI, J. and L.=20 ZHANG, "RECOMMENDATIONS ON QUEUE MANAGEMENT AND CONGESTION AVOIDANCE = IN THE INTERNET", RFC 2309, April 1998.=20 =20 [7] NICHOLS, K., BLAKE, S., BAKER, F. and D. BLACK, "DEFINITION OF=20 THE DIFFERENTIATED SERVICES FIELD (DS FIELD) IN THE IPV4 AND IPV6=20 HEADERS", RFC 2474, December 1998.=20 =20 [8] BLAKE, S., BLACK, D., CARLSON, M., DAVIES, E., WANG, Z. and W.=20 WEISS, "AN ARCHITECTURE FOR DIFFERENTIATED SERVICES", RFC 2475,=20 December 1998.=20 =20 [9] ALLMAN, M., PAXSON, V. and W. STEVENS, "TCP CONGESTION=20 CONTROL", RFC 2581, April 1999.=20 =20 [10] FLOYD, S. and T. HENDERSON, "THE NEWRENO MODIFICATION TO TCP'S=20 FAST RECOVERY ALGORITHM", RFC 2582, April 1999.=20 =20 =20 Babiarz et al. Expires April 2004 [Page 31]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 [11] HEINANEN, J., BAKER, F., WEISS, W. and J. WROCLAWSKI, "ASSURED=20 FORWARDING PHB GROUP", RFC 2597, June 1999.=20 =20 [12] HERZOG, S., "RSVP EXTENSIONS FOR POLICY CONTROL", RFC 2750,=20 January 2000.=20 =20 [13] Bernet, Y., "FORMAT OF THE RSVP DCLASS OBJECT", RFC 2996,=20 November 2000.=20 =20 [14] Ramakrishnan, K., Floyd, S. and D. Black, "THE ADDITION OF=20 EXPLICIT CONGESTION NOTIFICATION (ECN) TO IP", RFC 3168, September=20 2001.=20 =20 [15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,=20 "AGGREGATION OF RSVP FOR IPV4 AND IPV6 RESERVATIONS", RFC 3175,=20 September 2001.=20 =20 [16] Herzog, S., "SIGNALED PREEMPTION PRIORITY POLICY ELEMENT", RFC=20 3181, October 2001.=20 =20 [17] Heinanen, J. and Guerin, R. "A SINGLE RATE THREE COLOR MARKER", = RFC 2697, September 1999.=20 =20 [18] Heinanen, J. and Guerin, R. "A TWO RATE THREE COLOR MARKER",=20 RFC 2698, September 1999.=20 =20 [19] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,=20 Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "AN EXPEDITED = FORWARDING PHB (PER-HOP BEHAVIOR)", RFC 3246, March 2002.=20 =20 [20] "QBone Scavenger Service (QBSS) Definition", Internet2=20 Technical Report Proposed Service Definition, March 2001.=20 =20 =20 9. Informative References=20 =20 [21] DURHAM, D., BOYLE, J., COHEN, R., HERZOG, S., RAJAN, R. and A.=20 SASTRY, "THE COPS (COMMON OPEN POLICY SERVICE) PROTOCOL", RFC 2748,=20 January 2000.=20 =20 [22] Bernet, Y. and R. Pabbati, "APPLICATION AND SUB APPLICATION=20 IDENTITY POLICY ELEMENT FOR USE WITH RSVP", RFC 2872, June 2000.=20 [23] Bonaventure, O. and S. De Cnodder, "A RATE ADAPTIVE SHAPER FOR=20 DIFFERENTIATED SERVICES", RFC 2963, October 2000.=20 =20 [24] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,=20 Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS USAGE=20 FOR POLICY PROVISIONING (COPS-PR)", RFC 3084, March 2001.=20 =20 =20 Babiarz et al. Expires April 2004 [Page 32]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 [25] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for = Congestion Avoidance", IEEE/ACM Transactions on Networking , August=20 1993.=20 =20 [26] Zhang, L., "Virtual Clock: A New Traffic control Algorithm for=20 Packet Switching Networks", ACM SIGCOMM 1990, September 1990.=20 =20 [27] Keshav, S., "On the Efficient Implementation of Fair Queueing", = Internetworking: Research and Experiences Vol 2, September 1991.=20 =20 [28] Katevenis, M., Sidiropoulos, S. and C. Courcoubetis, "Weighted=20 Round-Robin Cell Multiplexing in a General Purpose ATM Switch Chip", = IEEE JSAC Vol. 9, No. 8, October 1991.=20 =20 [29] "International Emergency Preparedness Scheme", ITU E.106, March = 2000.=20 =20 [30] "Service Description for an International Emergency Multimedia=20 Service (Draft)", ITU-T F.706, August 2001.=20 =20 =20 10. Author's Address=20 =20 Jozef Babiarz=20 Nortel Networks=20 3500 Carling Avenue=20 Ottawa, Ont. Canada=20 K2H 8E9=20 Phone: +1-613-763-6098=20 Fax: +1-613-768-2231=20 EMail: babiarz@nortelnetworks.com=20 =20 =20 Fred Baker=20 Cisco Systems=20 1121 Via Del Rey=20 Santa Barbara, CA 93117 USA=20 Phone: +1-408-526-4257=20 Fax: +1-413-473-2403=20 EMail: fred@cisco.com=20 =20 =20 Kwok Ho Chan=20 Nortel Networks=20 600 Technology Park Drive=20 Billerica, MA 01821 USA =20 Phone: +1-978-288-8175=20 Fax: +1-978-288-4690=20 EMail: khchan@nortelnetworks.com=20 =20 =20 =20 Babiarz et al. Expires April 2004 [Page 33]=20 =0CInternet Draft DiffServ-Basic-Classes October = 2003=20 =20 11. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it = or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an = "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Acknowledgement=20 =20 Funding for the RFC Editor function is currently provided by the=20 Internet Society.=20 =20 =20 Babiarz et al. Expires April 2004 [Page 34] ------_=_NextPart_000_01C39CA0.9ED70D20 Content-Type: text/plain; name="ATT2522089.txt" Content-Disposition: attachment; filename="ATT2522089.txt" ------_=_NextPart_000_01C39CA0.9ED70D20-- _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Tue Oct 28 11:28:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05509 for ; Tue, 28 Oct 2003 11:28:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWhQ-00014Z-1N for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 11:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SGS3Vr004101 for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 11:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWhN-00013W-Hc; Tue, 28 Oct 2003 11:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWhG-00012K-ES for diffserv-interest@optimus.ietf.org; Tue, 28 Oct 2003 11:27:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05401 for ; Tue, 28 Oct 2003 11:27:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEWhF-000042-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 11:27:53 -0500 Received: from firewall2.uwindsor.ca ([137.207.233.22] helo=internet2.uwindsor.ca) by ietf-mx with smtp (Exim 4.12) id 1AEWhE-00003x-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 11:27:52 -0500 Received: id LAA01075; Tue, 28 Oct 2003 11:01:45 -0500 Received: by gateway id 28942808 for ; Tue, 28 Oct 2003 10:43:27 -0500 From: "Feng Y" To: diffserv-interest@ietf.org X-Mailer: CommuniGate Pro Web Mailer v.4.0.6 Date: Tue, 28 Oct 2003 10:43:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA05402 Subject: [Diffserv-interest] congestion in diffserv network Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Recently, I have read a paper about admission control in Diffserv network. In the paper the author mentioned the well-know diffserv =93traffic overloading and internal network state changing=94 problem. I wonder why the overloading or even congestion occurs in diffserv network. In diffserv architecture, the =93DS ingress node is responsible for ensuring that the traffic entering the DS domain conforms to any traffic conditioning agreement (TCA) between it and the other domain to which the ingress node is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning performs metering, shaping, policing and/or re-marking to ensure that the traffic entering the DS domain conforms to the rules specified in the TCA, in accordance with the domain's service provisioning policy=94. So what causes the overloading or congestion in diffserv? Does anyone explain it for me or give me some references. Thanks in advance. Yang _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Tue Oct 28 12:32:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10873 for ; Tue, 28 Oct 2003 12:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXhK-00083o-K6 for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 12:32:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SHW2J3030969 for diffserv-interest-archive@odin.ietf.org; Tue, 28 Oct 2003 12:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXhJ-00083F-Oo; Tue, 28 Oct 2003 12:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEXgp-000822-R3 for diffserv-interest@optimus.ietf.org; Tue, 28 Oct 2003 12:31:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10821 for ; Tue, 28 Oct 2003 12:31:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEXgo-0002AT-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 12:31:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AEXgn-00029O-00 for diffserv-interest@ietf.org; Tue, 28 Oct 2003 12:31:29 -0500 Received: from jschnizl-w2k.cisco.com (rtp-vpn2-670.cisco.com [10.82.242.158]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9SHUuFI007397; Tue, 28 Oct 2003 12:30:56 -0500 (EST) Message-Id: <4.3.2.7.2.20031028122043.02283790@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Oct 2003 12:30:55 -0500 To: "Feng Y" From: John Schnizlein Subject: Re: [Diffserv-interest] congestion in diffserv network Cc: diffserv-interest@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA10822 Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The simple reason that congestion can occur is that the TCA need not limit incoming traffic sufficiently to avoid it. The TCA for expedited forwarding is the only one, of many=20 traffic classes, that seeks to eliminate potential congestion,=20 in order to minimize delay and jitter. The parameters of other class definitions, assured forwarding for example, are intended to mark traffic at different ingress rates for different treatment when congestion occurs. Note that this anticipates that congestion will occur. Please recall that the high link utilization in an IP network is obtained in large measure because traffic loads are high enough to produce occasional congestion. Cooperative management of this congestion is the responsibility of transport-layer protocols. John At 10:43 AM 10/28/2003, Feng Y wrote: >... I wonder why the >overloading or even congestion occurs in diffserv network. >In diffserv architecture, the =93DS ingress node is >responsible for ensuring that the traffic entering the DS >domain conforms to any traffic conditioning agreement (TCA) >between it and the other domain to which the ingress node >is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >performs metering, shaping, policing and/or re-marking to >ensure that the traffic entering the DS domain conforms to >the rules specified in the TCA, in accordance with the >domain's service provisioning policy=94. So what causes the >overloading or congestion in diffserv? Does anyone explain >it for me or give me some references. Thanks in advance. _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Wed Oct 29 06:10:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03079 for ; Wed, 29 Oct 2003 06:10:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEoDE-0002O4-4J for diffserv-interest-archive@odin.ietf.org; Wed, 29 Oct 2003 06:10:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TBA49M009168 for diffserv-interest-archive@odin.ietf.org; Wed, 29 Oct 2003 06:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEoDB-0002N5-KQ; Wed, 29 Oct 2003 06:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEoCv-0002M0-0K for diffserv-interest@optimus.ietf.org; Wed, 29 Oct 2003 06:09:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03065 for ; Wed, 29 Oct 2003 06:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEoCr-0006C4-00 for diffserv-interest@ietf.org; Wed, 29 Oct 2003 06:09:41 -0500 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEoCq-0006Bp-00 for diffserv-interest@ietf.org; Wed, 29 Oct 2003 06:09:40 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TB8pNb119288; Wed, 29 Oct 2003 12:08:52 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TB7ZZp206662; Wed, 29 Oct 2003 12:07:35 +0100 Received: from zurich.ibm.com (dyn-9-13-127-0.ge.ch.ibm.com [9.13.127.0]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA31906; Wed, 29 Oct 2003 12:07:34 +0100 Message-ID: <3F9F9F56.2917A11A@zurich.ibm.com> Date: Wed, 29 Oct 2003 12:07:02 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: John Schnizlein CC: Feng Y , diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] congestion in diffserv network References: <4.3.2.7.2.20031028122043.02283790@wells.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Another way to look at it is that what diffserv does is split the network= into several separate networks, but each of them retains the statistical properties of a single Internet. Brian John Schnizlein wrote: > = > The simple reason that congestion can occur is that the TCA > need not limit incoming traffic sufficiently to avoid it. > The TCA for expedited forwarding is the only one, of many > traffic classes, that seeks to eliminate potential congestion, > in order to minimize delay and jitter. > = > The parameters of other class definitions, assured forwarding > for example, are intended to mark traffic at different ingress > rates for different treatment when congestion occurs. Note > that this anticipates that congestion will occur. > = > Please recall that the high link utilization in an IP network > is obtained in large measure because traffic loads are high > enough to produce occasional congestion. Cooperative management > of this congestion is the responsibility of transport-layer > protocols. > = > John > = > At 10:43 AM 10/28/2003, Feng Y wrote: > >... I wonder why the > >overloading or even congestion occurs in diffserv network. > >In diffserv architecture, the =93DS ingress node is > >responsible for ensuring that the traffic entering the DS > >domain conforms to any traffic conditioning agreement (TCA) > >between it and the other domain to which the ingress node > >is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning > >performs metering, shaping, policing and/or re-marking to > >ensure that the traffic entering the DS domain conforms to > >the rules specified in the TCA, in accordance with the > >domain's service provisioning policy=94. So what causes the > >overloading or congestion in diffserv? Does anyone explain > >it for me or give me some references. Thanks in advance. > = > _______________________________________________ > Diffserv-interest mailing list > Diffserv-interest@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv-interest -- = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter = Distinguished Engineer, Internet Standards & Technology, IBM = NEW ADDRESS PLEASE UPDATE ADDRESS BOOK _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Thu Oct 30 14:41:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06712 for ; Thu, 30 Oct 2003 14:41:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIfH-0002hr-0T for diffserv-interest-archive@odin.ietf.org; Thu, 30 Oct 2003 14:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UJf2gn010397 for diffserv-interest-archive@odin.ietf.org; Thu, 30 Oct 2003 14:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIfF-0002hI-Py; Thu, 30 Oct 2003 14:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIec-0002dr-Br for diffserv-interest@optimus.ietf.org; Thu, 30 Oct 2003 14:40:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06688 for ; Thu, 30 Oct 2003 14:40:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFIeZ-0000pH-00 for diffserv-interest@ietf.org; Thu, 30 Oct 2003 14:40:19 -0500 Received: from a17-250-248-85.apple.com ([17.250.248.85] helo=smtpout.mac.com) by ietf-mx with esmtp (Exim 4.12) id 1AFIeY-0000pD-00 for diffserv-interest@ietf.org; Thu, 30 Oct 2003 14:40:19 -0500 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9UJeIKk023401 for ; Thu, 30 Oct 2003 11:40:18 -0800 (PST) Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id h9UJeHZq014310 for ; Thu, 30 Oct 2003 11:40:18 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 30 Oct 2003 09:37:55 -0800 From: "John H. Shuler" To: Message-ID: In-Reply-To: <20031029170004.1709.5925.Mailman@www1.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #104 - 2 msgs Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It is my understanding that DiffServ does not attempt to prevent congestion at all, but only to ensure the the best chance for services to get the treatment they need (vs. Want) by making choices about queuing priorities. It is up to the carrier to monitor congestion periodically to prevent lowest-priority traffic from being too congested. EF should ALWAYS get through on-time, and AF CIR should always get through, if somewhat delayed and jittery. The cases when this is NOT true should be rare and bizarre (earthquakes, major network outages, etc.) unless the carrier is not doing their job... Which is simply to make sure they engineer total network bandwidth above the level of peak CIR. The only alternative to this -- admission control -- imposes a signaling requirement that just adds to the total network burden and is not responsive enough to deal with the unpredictable burstiness of the internet. Am I off-base, here? j > From: diffserv-interest-request@ietf.org > Reply-To: diffserv-interest@ietf.org > Date: Wed, 29 Oct 2003 12:00:04 -0500 > To: diffserv-interest@ietf.org > Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs > > Send Diffserv-interest mailing list submissions to > diffserv-interest@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/diffserv-interest > or, via email, send a message with subject or body 'help' to > diffserv-interest-request@ietf.org > > You can reach the person managing the list at > diffserv-interest-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Diffserv-interest digest..." > > > Today's Topics: > > 1. Re: congestion in diffserv network (John Schnizlein) > 2. Re: congestion in diffserv network (Brian E Carpenter) > > --__--__-- > > Message: 1 > Date: Tue, 28 Oct 2003 12:30:55 -0500 > To: "Feng Y" > From: John Schnizlein > Subject: Re: [Diffserv-interest] congestion in diffserv network > Cc: diffserv-interest@ietf.org > > The simple reason that congestion can occur is that the TCA > need not limit incoming traffic sufficiently to avoid it. > The TCA for expedited forwarding is the only one, of many=20 > traffic classes, that seeks to eliminate potential congestion,=20 > in order to minimize delay and jitter. > > The parameters of other class definitions, assured forwarding > for example, are intended to mark traffic at different ingress > rates for different treatment when congestion occurs. Note > that this anticipates that congestion will occur. > > Please recall that the high link utilization in an IP network > is obtained in large measure because traffic loads are high > enough to produce occasional congestion. Cooperative management > of this congestion is the responsibility of transport-layer > protocols. > > John > > At 10:43 AM 10/28/2003, Feng Y wrote: >> ... I wonder why the >> overloading or even congestion occurs in diffserv network. >> In diffserv architecture, the =93DS ingress node is >> responsible for ensuring that the traffic entering the DS >> domain conforms to any traffic conditioning agreement (TCA) >> between it and the other domain to which the ingress node >> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >> performs metering, shaping, policing and/or re-marking to >> ensure that the traffic entering the DS domain conforms to >> the rules specified in the TCA, in accordance with the >> domain's service provisioning policy=94. So what causes the >> overloading or congestion in diffserv? Does anyone explain >> it for me or give me some references. Thanks in advance. > > > > --__--__-- > > Message: 2 > Date: Wed, 29 Oct 2003 12:07:02 +0100 > From: Brian E Carpenter > Organization: IBM > To: John Schnizlein > CC: Feng Y , diffserv-interest@ietf.org > Subject: Re: [Diffserv-interest] congestion in diffserv network > > Another way to look at it is that what diffserv does is split the network= > > into several separate networks, but each of them retains the statistical > properties of a single Internet. > > Brian > > John Schnizlein wrote: >> = > >> The simple reason that congestion can occur is that the TCA >> need not limit incoming traffic sufficiently to avoid it. >> The TCA for expedited forwarding is the only one, of many >> traffic classes, that seeks to eliminate potential congestion, >> in order to minimize delay and jitter. >> = > >> The parameters of other class definitions, assured forwarding >> for example, are intended to mark traffic at different ingress >> rates for different treatment when congestion occurs. Note >> that this anticipates that congestion will occur. >> = > >> Please recall that the high link utilization in an IP network >> is obtained in large measure because traffic loads are high >> enough to produce occasional congestion. Cooperative management >> of this congestion is the responsibility of transport-layer >> protocols. >> = > >> John >> = > >> At 10:43 AM 10/28/2003, Feng Y wrote: >>> ... I wonder why the >>> overloading or even congestion occurs in diffserv network. >>> In diffserv architecture, the =93DS ingress node is >>> responsible for ensuring that the traffic entering the DS >>> domain conforms to any traffic conditioning agreement (TCA) >>> between it and the other domain to which the ingress node >>> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >>> performs metering, shaping, policing and/or re-marking to >>> ensure that the traffic entering the DS domain conforms to >>> the rules specified in the TCA, in accordance with the >>> domain's service provisioning policy=94. So what causes the >>> overloading or congestion in diffserv? Does anyone explain >>> it for me or give me some references. Thanks in advance. >> = > >> _______________________________________________ >> Diffserv-interest mailing list >> Diffserv-interest@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv-interest > > -- = > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter = > > Distinguished Engineer, Internet Standards & Technology, IBM = > > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > > > --__--__-- > > _______________________________________________ > Diffserv-interest mailing list > Diffserv-interest@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv-interest > > > End of Diffserv-interest Digest _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Fri Oct 31 01:37:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02042 for ; Fri, 31 Oct 2003 01:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSu7-0000Dp-PQ for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 01:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V6b3UV000828 for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 01:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFSu5-0000CH-60; Fri, 31 Oct 2003 01:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFStB-00006p-Eh for diffserv-interest@optimus.ietf.org; Fri, 31 Oct 2003 01:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01996 for ; Fri, 31 Oct 2003 01:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFSt8-0002F2-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 01:36:02 -0500 Received: from a17-250-248-83.apple.com ([17.250.248.83] helo=smtpout.mac.com) by ietf-mx with esmtp (Exim 4.12) id 1AFSt7-0002Ey-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 01:36:01 -0500 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id h9V6dlbo015372 for ; Thu, 30 Oct 2003 22:39:47 -0800 (PST) Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id h9V6ZwZq006758 for ; Thu, 30 Oct 2003 22:35:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 30 Oct 2003 22:35:56 -0800 From: "John H. Shuler" To: Message-ID: In-Reply-To: <20031029170004.1709.5925.Mailman@www1.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #104 - 2 msgs Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Why make a distinction between "Standard Service Class" and "Low Priority Data"? In fact, it seems the most useful outcome of this paper is to help service providers standardize across and between their networks as to service class treatment for different service types. For this reason, it seems the best thing to do is, rather than to create these semi-artificial classes and sub-classes, to get quite specific about how to mark each specific service, e.g. IP telephony, SNA, HTTP, FTP, unidirectional video, interactive multimedia, etc. You have gone part of the way to this goal, but have put what seems to be an artificial middle step into the process... These service classes. I can see why you would do this in an attempt to consolidate the classes for ease of management, but by the time you are done, you have so many classes and variations that you have defeated this purpose anyway. And the net goal of standardizing treatment across the network is still not achieved because of the multiple options for several of the services. Just some thoughts on a single, careful reading. Also, there is some dumb editorial stuff: (1) Do a lookup for the word "respectfully" and make sure you don't really mean "respectively". (2) Look up "sufficed" and replace with "sufficient". (3) You also have a tendency to use "which" instead of "that" (4) There is an instance of using "then" instead of "than". Sorry I'm too lazy to be specific about where (it's late). j -- Jay Shuler President Beyond Category Consulting 4020 Halkins Drive San Jose, CA 95124 (408) 582-3682 Jay@BeyondCategory.US www.BeyondCategory.US > From: diffserv-interest-request@ietf.org > Reply-To: diffserv-interest@ietf.org > Date: Wed, 29 Oct 2003 12:00:04 -0500 > To: diffserv-interest@ietf.org > Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs > > Send Diffserv-interest mailing list submissions to > diffserv-interest@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/diffserv-interest > or, via email, send a message with subject or body 'help' to > diffserv-interest-request@ietf.org > > You can reach the person managing the list at > diffserv-interest-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Diffserv-interest digest..." > > > Today's Topics: > > 1. Re: congestion in diffserv network (John Schnizlein) > 2. Re: congestion in diffserv network (Brian E Carpenter) > > --__--__-- > > Message: 1 > Date: Tue, 28 Oct 2003 12:30:55 -0500 > To: "Feng Y" > From: John Schnizlein > Subject: Re: [Diffserv-interest] congestion in diffserv network > Cc: diffserv-interest@ietf.org > > The simple reason that congestion can occur is that the TCA > need not limit incoming traffic sufficiently to avoid it. > The TCA for expedited forwarding is the only one, of many=20 > traffic classes, that seeks to eliminate potential congestion,=20 > in order to minimize delay and jitter. > > The parameters of other class definitions, assured forwarding > for example, are intended to mark traffic at different ingress > rates for different treatment when congestion occurs. Note > that this anticipates that congestion will occur. > > Please recall that the high link utilization in an IP network > is obtained in large measure because traffic loads are high > enough to produce occasional congestion. Cooperative management > of this congestion is the responsibility of transport-layer > protocols. > > John > > At 10:43 AM 10/28/2003, Feng Y wrote: >> ... I wonder why the >> overloading or even congestion occurs in diffserv network. >> In diffserv architecture, the =93DS ingress node is >> responsible for ensuring that the traffic entering the DS >> domain conforms to any traffic conditioning agreement (TCA) >> between it and the other domain to which the ingress node >> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >> performs metering, shaping, policing and/or re-marking to >> ensure that the traffic entering the DS domain conforms to >> the rules specified in the TCA, in accordance with the >> domain's service provisioning policy=94. So what causes the >> overloading or congestion in diffserv? Does anyone explain >> it for me or give me some references. Thanks in advance. > > > > --__--__-- > > Message: 2 > Date: Wed, 29 Oct 2003 12:07:02 +0100 > From: Brian E Carpenter > Organization: IBM > To: John Schnizlein > CC: Feng Y , diffserv-interest@ietf.org > Subject: Re: [Diffserv-interest] congestion in diffserv network > > Another way to look at it is that what diffserv does is split the network= > > into several separate networks, but each of them retains the statistical > properties of a single Internet. > > Brian > > John Schnizlein wrote: >> = > >> The simple reason that congestion can occur is that the TCA >> need not limit incoming traffic sufficiently to avoid it. >> The TCA for expedited forwarding is the only one, of many >> traffic classes, that seeks to eliminate potential congestion, >> in order to minimize delay and jitter. >> = > >> The parameters of other class definitions, assured forwarding >> for example, are intended to mark traffic at different ingress >> rates for different treatment when congestion occurs. Note >> that this anticipates that congestion will occur. >> = > >> Please recall that the high link utilization in an IP network >> is obtained in large measure because traffic loads are high >> enough to produce occasional congestion. Cooperative management >> of this congestion is the responsibility of transport-layer >> protocols. >> = > >> John >> = > >> At 10:43 AM 10/28/2003, Feng Y wrote: >>> ... I wonder why the >>> overloading or even congestion occurs in diffserv network. >>> In diffserv architecture, the =93DS ingress node is >>> responsible for ensuring that the traffic entering the DS >>> domain conforms to any traffic conditioning agreement (TCA) >>> between it and the other domain to which the ingress node >>> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >>> performs metering, shaping, policing and/or re-marking to >>> ensure that the traffic entering the DS domain conforms to >>> the rules specified in the TCA, in accordance with the >>> domain's service provisioning policy=94. So what causes the >>> overloading or congestion in diffserv? Does anyone explain >>> it for me or give me some references. Thanks in advance. >> = > >> _______________________________________________ >> Diffserv-interest mailing list >> Diffserv-interest@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv-interest > > -- = > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter = > > Distinguished Engineer, Internet Standards & Technology, IBM = > > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > > > --__--__-- > > _______________________________________________ > Diffserv-interest mailing list > Diffserv-interest@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv-interest > > > End of Diffserv-interest Digest _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Fri Oct 31 04:42:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19254 for ; Fri, 31 Oct 2003 04:42:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVn9-0004CD-4W for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:42:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V9g2Xk016103 for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVn7-0004Aj-Gu; Fri, 31 Oct 2003 04:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVmq-000495-FP for diffserv-interest@optimus.ietf.org; Fri, 31 Oct 2003 04:41:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19251 for ; Fri, 31 Oct 2003 04:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVmn-0004gt-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:41:41 -0500 Received: from web15206.mail.cnb.yahoo.com ([202.3.77.136] helo=web15206.mail.bjs.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 1AFVmm-0004gb-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:41:40 -0500 Message-ID: <20031031094109.17799.qmail@web15206.mail.bjs.yahoo.com> Received: from [202.101.172.19] by web15206.mail.bjs.yahoo.com via HTTP; Fri, 31 Oct 2003 17:41:09 CST Date: Fri, 31 Oct 2003 17:41:09 +0800 (CST) From: =?gb2312?q?Jing=20Shen?= Subject: Re: [Diffserv-interest] Re: Diffserv-interest digest, Vol 1 #104 - 2 msgs To: "John H. Shuler" , diffserv-interest@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA19252 Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable IMHO, diffserv is just to define some basic rules to be followed by ISPS who will negotiate real SLA parameters. These parameters are to be 'implemented' in their network and supported by routers around. So, a coarse defination like EF, AF is enough. Anyway, as pointed out by other people here, DiffServ just make up logical network in physical network. This means there will be congestion in every logical networks. jing shen ' spamcontrol ' =20 --- "John H. Shuler" =B5=C4=D5=FD=CE=C4=A3=BA> Why make a distinction between "Standard Service > Class" and "Low Priority > Data"? >=20 > In fact, it seems the most useful outcome of this > paper is to help service > providers standardize across and between their > networks as to service class > treatment for different service types. For this > reason, it seems the best > thing to do is, rather than to create these > semi-artificial classes and > sub-classes, to get quite specific about how to mark > each specific service, > e.g. IP telephony, SNA, HTTP, FTP, unidirectional > video, interactive > multimedia, etc. You have gone part of the way to > this goal, but have put > what seems to be an artificial middle step into the > process... These service > classes. I can see why you would do this in an > attempt to consolidate the > classes for ease of management, but by the time you > are done, you have so > many classes and variations that you have defeated > this purpose anyway. And > the net goal of standardizing treatment across the > network is still not > achieved because of the multiple options for several > of the services. >=20 > Just some thoughts on a single, careful reading. >=20 > Also, there is some dumb editorial stuff: > (1) Do a lookup for the word "respectfully" and make > sure you don't really > mean "respectively". > (2) Look up "sufficed" and replace with > "sufficient". > (3) You also have a tendency to use "which" instead > of "that" > (4) There is an instance of using "then" instead of > "than". >=20 > Sorry I'm too lazy to be specific about where (it's > late). >=20 > j > --=20 > Jay Shuler > President > Beyond Category Consulting > 4020 Halkins Drive > San Jose, CA 95124 > (408) 582-3682 > Jay@BeyondCategory.US > www.BeyondCategory.US >=20 >=20 > > From: diffserv-interest-request@ietf.org > > Reply-To: diffserv-interest@ietf.org > > Date: Wed, 29 Oct 2003 12:00:04 -0500 > > To: diffserv-interest@ietf.org > > Subject: Diffserv-interest digest, Vol 1 #104 - 2 > msgs > >=20 > > Send Diffserv-interest mailing list submissions to > > diffserv-interest@ietf.org > >=20 > > To subscribe or unsubscribe via the World Wide > Web, visit > > > https://www1.ietf.org/mailman/listinfo/diffserv-interest > > or, via email, send a message with subject or body > 'help' to > > diffserv-interest-request@ietf.org > >=20 > > You can reach the person managing the list at > > diffserv-interest-admin@ietf.org > >=20 > > When replying, please edit your Subject line so it > is more specific > > than "Re: Contents of Diffserv-interest digest..." > >=20 > >=20 > > Today's Topics: > >=20 > > 1. Re: congestion in diffserv network (John > Schnizlein) > > 2. Re: congestion in diffserv network (Brian E > Carpenter) > >=20 > > --__--__-- > >=20 > > Message: 1 > > Date: Tue, 28 Oct 2003 12:30:55 -0500 > > To: "Feng Y" > > From: John Schnizlein > > Subject: Re: [Diffserv-interest] congestion in > diffserv network > > Cc: diffserv-interest@ietf.org > >=20 > > The simple reason that congestion can occur is > that the TCA > > need not limit incoming traffic sufficiently to > avoid it. > > The TCA for expedited forwarding is the only one, > of many=3D20 > > traffic classes, that seeks to eliminate potential > congestion,=3D20 > > in order to minimize delay and jitter. > >=20 > > The parameters of other class definitions, assured > forwarding > > for example, are intended to mark traffic at > different ingress > > rates for different treatment when congestion > occurs. Note > > that this anticipates that congestion will occur. > >=20 > > Please recall that the high link utilization in an > IP network > > is obtained in large measure because traffic loads > are high > > enough to produce occasional congestion. > Cooperative management > > of this congestion is the responsibility of > transport-layer > > protocols. > >=20 > > John > >=20 > > At 10:43 AM 10/28/2003, Feng Y wrote: > >> ... I wonder why the > >> overloading or even congestion occurs in diffserv > network. > >> In diffserv architecture, the =3D93DS ingress node > is > >> responsible for ensuring that the traffic > entering the DS > >> domain conforms to any traffic conditioning > agreement (TCA) > >> between it and the other domain to which the > ingress node > >> is connected=3D94 [RFC 2475]. Moreover, =20 > =3D93Traffic conditioning > >> performs metering, shaping, policing and/or > re-marking to > >> ensure that the traffic entering the DS domain > conforms to > >> the rules specified in the TCA, in accordance > with the > >> domain's service provisioning policy=3D94. So what > causes the > >> overloading or congestion in diffserv? Does > anyone explain > >> it for me or give me some references. Thanks in > advance. > >=20 > >=20 > >=20 > > --__--__-- > >=20 > > Message: 2 > > Date: Wed, 29 Oct 2003 12:07:02 +0100 > > From: Brian E Carpenter > > Organization: IBM > > To: John Schnizlein > > CC: Feng Y , > diffserv-interest@ietf.org > > Subject: Re: [Diffserv-interest] congestion in > diffserv network > >=20 > > Another way to look at it is that what diffserv > does is split the network=3D > >=20 > > into several separate networks, but each of them > retains the statistical > > properties of a single Internet. > >=20 > > Brian > >=20 > > John Schnizlein wrote: > >> =3D > >=20 > >> The simple reason that congestion can occur is > that the TCA > >> need not limit incoming traffic sufficiently to > avoid it. > >> The TCA for expedited forwarding is the only one, > of many > >> traffic classes, that seeks to eliminate > potential congestion, > >> in order to minimize delay and jitter. > >> =3D > >=20 > >> The parameters of other class definitions, > assured forwarding > >> for example, are intended to mark traffic at > different ingress > >> rates for different treatment when congestion > occurs.=20 =3D=3D=3D message truncated =3D=3D=3D=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Fri Oct 31 04:45:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19369 for ; Fri, 31 Oct 2003 04:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVq2-0004si-Ic for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:45:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V9j1kq018596 for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVq1-0004pq-7A; Fri, 31 Oct 2003 04:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVpB-0004iT-5y for diffserv-interest@optimus.ietf.org; Fri, 31 Oct 2003 04:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19318 for ; Fri, 31 Oct 2003 04:43:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVp8-0004id-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:44:06 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AFVp7-0004hz-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:44:05 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9V9fG3K037594; Fri, 31 Oct 2003 09:41:16 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9V9hT6H266730; Fri, 31 Oct 2003 10:43:30 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA65912; Fri, 31 Oct 2003 10:43:27 +0100 Message-ID: <3FA22E9E.ECAFD8CD@zurich.ibm.com> Date: Fri, 31 Oct 2003 10:42:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "John H. Shuler" CC: diffserv-interest@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: draft-baker-diffserv-basic-classes-01.txt Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, I guess your comment refers to the draft so I changed the subject. If you want to be sure the authors see your comments, you might want to write to them directly. My reactions inserted below. Brian "John H. Shuler" wrote: > > Why make a distinction between "Standard Service Class" and "Low Priority > Data"? There is a kitchen sink aspect to this draft that worries me. Rather than starting simple, with three or four generic service classes, the authors have chosen to present the union of a number of diffserv deployment models. I think that risks confusing operators by giving them too much complexity to choose from. > > In fact, it seems the most useful outcome of this paper is to help service > providers standardize across and between their networks as to service class > treatment for different service types. For this reason, it seems the best > thing to do is, rather than to create these semi-artificial classes and > sub-classes, to get quite specific about how to mark each specific service, > e.g. IP telephony, SNA, HTTP, FTP, unidirectional video, interactive > multimedia, etc. You have gone part of the way to this goal, but have put > what seems to be an artificial middle step into the process... These service > classes. I can see why you would do this in an attempt to consolidate the > classes for ease of management, but by the time you are done, you have so > many classes and variations that you have defeated this purpose anyway. And > the net goal of standardizing treatment across the network is still not > achieved because of the multiple options for several of the services. Exactly. > > Just some thoughts on a single, careful reading. > > Also, there is some dumb editorial stuff: > (1) Do a lookup for the word "respectfully" and make sure you don't really > mean "respectively". > (2) Look up "sufficed" and replace with "sufficient". > (3) You also have a tendency to use "which" instead of "that" > (4) There is an instance of using "then" instead of "than". > > Sorry I'm too lazy to be specific about where (it's late). > > j > -- > Jay Shuler > President > Beyond Category Consulting > 4020 Halkins Drive > San Jose, CA 95124 > (408) 582-3682 > Jay@BeyondCategory.US > www.BeyondCategory.US > > > From: diffserv-interest-request@ietf.org > > Reply-To: diffserv-interest@ietf.org > > Date: Wed, 29 Oct 2003 12:00:04 -0500 > > To: diffserv-interest@ietf.org > > Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Fri Oct 31 04:54:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19620 for ; Fri, 31 Oct 2003 04:54:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVyl-000615-2N for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V9s2Iw023117 for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 04:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVyi-0005z2-7p; Fri, 31 Oct 2003 04:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFVxu-0005wz-Tf for diffserv-interest@optimus.ietf.org; Fri, 31 Oct 2003 04:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19578 for ; Fri, 31 Oct 2003 04:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFVxr-0004qq-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:53:07 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1AFVxq-0004qm-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 04:53:06 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9V9qagZ018670; Fri, 31 Oct 2003 09:52:36 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9V9qaQf257068; Fri, 31 Oct 2003 10:52:36 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA28730; Fri, 31 Oct 2003 10:52:32 +0100 Message-ID: <3FA230BE.6AA9CE6E@zurich.ibm.com> Date: Fri, 31 Oct 2003 10:51:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "John H. Shuler" CC: diffserv-interest@ietf.org Subject: Re: [Diffserv-interest] congestion in diffserv network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "John H. Shuler" wrote: > > It is my understanding that DiffServ does not attempt to prevent congestion > at all, but only to ensure the the best chance for services to get the > treatment they need (vs. Want) by making choices about queuing priorities. That's what I meant about it creating several separate Internets - you put the traffic into the Internet that has the most appropriate queue handling for your traffic, but ultimately (even for EF behavior) the result is still statistical. Queueing theory doesn't go away just because it has unpleasant consequences. > > It is up to the carrier to monitor congestion periodically to prevent > lowest-priority traffic from being too congested. EF should ALWAYS get > through on-time, and AF CIR should always get through, if somewhat delayed > and jittery. The cases when this is NOT true should be rare and bizarre > (earthquakes, major network outages, etc.) unless the carrier is not doing > their job... Which is simply to make sure they engineer total network > bandwidth above the level of peak CIR. Exactly. Each traffic class (i.e. each queue) needs to be provisioned for the expected load with appropriate over- or under-provisioning. The new thing is that you can over-provision for some traffic and under-provision for other traffic. (New to IP, that is. It's hardly a new concept.) > > The only alternative to this -- admission control -- imposes a signaling > requirement that just adds to the total network burden and is not responsive > enough to deal with the unpredictable burstiness of the internet. I think that's correct. But there are people in the VoIP world who really do want to provision individual calls, which means adding signalling and admission control. That's fine if they can make it scale, but it isn't part of the diffserv model. > Am I off-base, here? No. Brian > > j > > > From: diffserv-interest-request@ietf.org > > Reply-To: diffserv-interest@ietf.org > > Date: Wed, 29 Oct 2003 12:00:04 -0500 > > To: diffserv-interest@ietf.org > > Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs > > > > Send Diffserv-interest mailing list submissions to > > diffserv-interest@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/diffserv-interest > > or, via email, send a message with subject or body 'help' to > > diffserv-interest-request@ietf.org > > > > You can reach the person managing the list at > > diffserv-interest-admin@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Diffserv-interest digest..." > > > > > > Today's Topics: > > > > 1. Re: congestion in diffserv network (John Schnizlein) > > 2. Re: congestion in diffserv network (Brian E Carpenter) > > > > --__--__-- > > > > Message: 1 > > Date: Tue, 28 Oct 2003 12:30:55 -0500 > > To: "Feng Y" > > From: John Schnizlein > > Subject: Re: [Diffserv-interest] congestion in diffserv network > > Cc: diffserv-interest@ietf.org > > > > The simple reason that congestion can occur is that the TCA > > need not limit incoming traffic sufficiently to avoid it. > > The TCA for expedited forwarding is the only one, of many=20 > > traffic classes, that seeks to eliminate potential congestion,=20 > > in order to minimize delay and jitter. > > > > The parameters of other class definitions, assured forwarding > > for example, are intended to mark traffic at different ingress > > rates for different treatment when congestion occurs. Note > > that this anticipates that congestion will occur. > > > > Please recall that the high link utilization in an IP network > > is obtained in large measure because traffic loads are high > > enough to produce occasional congestion. Cooperative management > > of this congestion is the responsibility of transport-layer > > protocols. > > > > John > > > > At 10:43 AM 10/28/2003, Feng Y wrote: > >> ... I wonder why the > >> overloading or even congestion occurs in diffserv network. > >> In diffserv architecture, the =93DS ingress node is > >> responsible for ensuring that the traffic entering the DS > >> domain conforms to any traffic conditioning agreement (TCA) > >> between it and the other domain to which the ingress node > >> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning > >> performs metering, shaping, policing and/or re-marking to > >> ensure that the traffic entering the DS domain conforms to > >> the rules specified in the TCA, in accordance with the > >> domain's service provisioning policy=94. So what causes the > >> overloading or congestion in diffserv? Does anyone explain > >> it for me or give me some references. Thanks in advance. > > > > > > > > --__--__-- > > > > Message: 2 > > Date: Wed, 29 Oct 2003 12:07:02 +0100 > > From: Brian E Carpenter > > Organization: IBM > > To: John Schnizlein > > CC: Feng Y , diffserv-interest@ietf.org > > Subject: Re: [Diffserv-interest] congestion in diffserv network > > > > Another way to look at it is that what diffserv does is split the network= > > > > into several separate networks, but each of them retains the statistical > > properties of a single Internet. > > > > Brian > > > > John Schnizlein wrote: > >> = > > > >> The simple reason that congestion can occur is that the TCA > >> need not limit incoming traffic sufficiently to avoid it. > >> The TCA for expedited forwarding is the only one, of many > >> traffic classes, that seeks to eliminate potential congestion, > >> in order to minimize delay and jitter. > >> = > > > >> The parameters of other class definitions, assured forwarding > >> for example, are intended to mark traffic at different ingress > >> rates for different treatment when congestion occurs. Note > >> that this anticipates that congestion will occur. > >> = > > > >> Please recall that the high link utilization in an IP network > >> is obtained in large measure because traffic loads are high > >> enough to produce occasional congestion. Cooperative management > >> of this congestion is the responsibility of transport-layer > >> protocols. > >> = > > > >> John > >> = > > > >> At 10:43 AM 10/28/2003, Feng Y wrote: > >>> ... I wonder why the > >>> overloading or even congestion occurs in diffserv network. > >>> In diffserv architecture, the =93DS ingress node is > >>> responsible for ensuring that the traffic entering the DS > >>> domain conforms to any traffic conditioning agreement (TCA) > >>> between it and the other domain to which the ingress node > >>> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning > >>> performs metering, shaping, policing and/or re-marking to > >>> ensure that the traffic entering the DS domain conforms to > >>> the rules specified in the TCA, in accordance with the > >>> domain's service provisioning policy=94. So what causes the > >>> overloading or congestion in diffserv? Does anyone explain > >>> it for me or give me some references. Thanks in advance. > >> = > > > >> _______________________________________________ > >> Diffserv-interest mailing list > >> Diffserv-interest@ietf.org > >> https://www1.ietf.org/mailman/listinfo/diffserv-interest > > > > -- = > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter = > > > > Distinguished Engineer, Internet Standards & Technology, IBM = > > > > > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > > > > > > > --__--__-- > > > > _______________________________________________ > > Diffserv-interest mailing list > > Diffserv-interest@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv-interest > > > > > > End of Diffserv-interest Digest > > _______________________________________________ > Diffserv-interest mailing list > Diffserv-interest@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv-interest -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From exim@www1.ietf.org Fri Oct 31 11:47:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07678 for ; Fri, 31 Oct 2003 11:47:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcQT-0003sV-9Q for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 11:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VGl5Do014902 for diffserv-interest-archive@odin.ietf.org; Fri, 31 Oct 2003 11:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcQP-0003qZ-Jo; Fri, 31 Oct 2003 11:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcPx-0003nQ-2K for diffserv-interest@optimus.ietf.org; Fri, 31 Oct 2003 11:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07578 for ; Fri, 31 Oct 2003 11:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFcPv-00038a-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 11:46:31 -0500 Received: from smtpout.mac.com ([17.250.248.87]) by ietf-mx with esmtp (Exim 4.12) id 1AFcPv-00038X-00 for diffserv-interest@ietf.org; Fri, 31 Oct 2003 11:46:31 -0500 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h9VGkU9H016542; Fri, 31 Oct 2003 08:46:30 -0800 (PST) Received: from [192.168.0.2] (12-235-5-14.client.attbi.com [12.235.5.14]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id h9VGkTZq013683; Fri, 31 Oct 2003 08:46:30 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 31 Oct 2003 08:46:29 -0800 From: "John H. Shuler" To: Brian E Carpenter CC: Message-ID: In-Reply-To: <3FA230BE.6AA9CE6E@zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: Admission and congestion control Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess my point is that admission control is an application-specific phenomenon. The DiffServ network simply sees control traffic between the client and VoIP server and treats it appropriately, then when/if the server tells the client to go ahead, the DS network then sees voice traffic and treats it appropriately. It is not up to the DS network to admit or not. Same concept as with TCP and congestion control. Not up to DS to do this, but up to TCP. DS only sets limits on total BE traffic and bursts. j > From: Brian E Carpenter > Organization: IBM > Date: Fri, 31 Oct 2003 10:51:58 +0100 > To: "John H. Shuler" > Cc: diffserv-interest@ietf.org > Subject: Re: [Diffserv-interest] congestion in diffserv network > > "John H. Shuler" wrote: >> >> It is my understanding that DiffServ does not attempt to prevent congestion >> at all, but only to ensure the the best chance for services to get the >> treatment they need (vs. Want) by making choices about queuing priorities. > > That's what I meant about it creating several separate Internets - you put > the traffic into the Internet that has the most appropriate queue handling > for your traffic, but ultimately (even for EF behavior) the result is still > statistical. Queueing theory doesn't go away just because it has unpleasant > consequences. > >> >> It is up to the carrier to monitor congestion periodically to prevent >> lowest-priority traffic from being too congested. EF should ALWAYS get >> through on-time, and AF CIR should always get through, if somewhat delayed >> and jittery. The cases when this is NOT true should be rare and bizarre >> (earthquakes, major network outages, etc.) unless the carrier is not doing >> their job... Which is simply to make sure they engineer total network >> bandwidth above the level of peak CIR. > > Exactly. Each traffic class (i.e. each queue) needs to be provisioned for > the expected load with appropriate over- or under-provisioning. The new > thing is that you can over-provision for some traffic and under-provision > for other traffic. (New to IP, that is. It's hardly a new concept.) > >> >> The only alternative to this -- admission control -- imposes a signaling >> requirement that just adds to the total network burden and is not responsive >> enough to deal with the unpredictable burstiness of the internet. > > I think that's correct. But there are people in the VoIP world who really do > want to provision individual calls, which means adding signalling and > admission > control. That's fine if they can make it scale, but it isn't part of the > diffserv > model. > >> Am I off-base, here? > > No. > > Brian > >> >> j >> >>> From: diffserv-interest-request@ietf.org >>> Reply-To: diffserv-interest@ietf.org >>> Date: Wed, 29 Oct 2003 12:00:04 -0500 >>> To: diffserv-interest@ietf.org >>> Subject: Diffserv-interest digest, Vol 1 #104 - 2 msgs >>> >>> Send Diffserv-interest mailing list submissions to >>> diffserv-interest@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www1.ietf.org/mailman/listinfo/diffserv-interest >>> or, via email, send a message with subject or body 'help' to >>> diffserv-interest-request@ietf.org >>> >>> You can reach the person managing the list at >>> diffserv-interest-admin@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Diffserv-interest digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: congestion in diffserv network (John Schnizlein) >>> 2. Re: congestion in diffserv network (Brian E Carpenter) >>> >>> --__--__-- >>> >>> Message: 1 >>> Date: Tue, 28 Oct 2003 12:30:55 -0500 >>> To: "Feng Y" >>> From: John Schnizlein >>> Subject: Re: [Diffserv-interest] congestion in diffserv network >>> Cc: diffserv-interest@ietf.org >>> >>> The simple reason that congestion can occur is that the TCA >>> need not limit incoming traffic sufficiently to avoid it. >>> The TCA for expedited forwarding is the only one, of many=20 >>> traffic classes, that seeks to eliminate potential congestion,=20 >>> in order to minimize delay and jitter. >>> >>> The parameters of other class definitions, assured forwarding >>> for example, are intended to mark traffic at different ingress >>> rates for different treatment when congestion occurs. Note >>> that this anticipates that congestion will occur. >>> >>> Please recall that the high link utilization in an IP network >>> is obtained in large measure because traffic loads are high >>> enough to produce occasional congestion. Cooperative management >>> of this congestion is the responsibility of transport-layer >>> protocols. >>> >>> John >>> >>> At 10:43 AM 10/28/2003, Feng Y wrote: >>>> ... I wonder why the >>>> overloading or even congestion occurs in diffserv network. >>>> In diffserv architecture, the =93DS ingress node is >>>> responsible for ensuring that the traffic entering the DS >>>> domain conforms to any traffic conditioning agreement (TCA) >>>> between it and the other domain to which the ingress node >>>> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >>>> performs metering, shaping, policing and/or re-marking to >>>> ensure that the traffic entering the DS domain conforms to >>>> the rules specified in the TCA, in accordance with the >>>> domain's service provisioning policy=94. So what causes the >>>> overloading or congestion in diffserv? Does anyone explain >>>> it for me or give me some references. Thanks in advance. >>> >>> >>> >>> --__--__-- >>> >>> Message: 2 >>> Date: Wed, 29 Oct 2003 12:07:02 +0100 >>> From: Brian E Carpenter >>> Organization: IBM >>> To: John Schnizlein >>> CC: Feng Y , diffserv-interest@ietf.org >>> Subject: Re: [Diffserv-interest] congestion in diffserv network >>> >>> Another way to look at it is that what diffserv does is split the network= >>> >>> into several separate networks, but each of them retains the statistical >>> properties of a single Internet. >>> >>> Brian >>> >>> John Schnizlein wrote: >>>> = >>> >>>> The simple reason that congestion can occur is that the TCA >>>> need not limit incoming traffic sufficiently to avoid it. >>>> The TCA for expedited forwarding is the only one, of many >>>> traffic classes, that seeks to eliminate potential congestion, >>>> in order to minimize delay and jitter. >>>> = >>> >>>> The parameters of other class definitions, assured forwarding >>>> for example, are intended to mark traffic at different ingress >>>> rates for different treatment when congestion occurs. Note >>>> that this anticipates that congestion will occur. >>>> = >>> >>>> Please recall that the high link utilization in an IP network >>>> is obtained in large measure because traffic loads are high >>>> enough to produce occasional congestion. Cooperative management >>>> of this congestion is the responsibility of transport-layer >>>> protocols. >>>> = >>> >>>> John >>>> = >>> >>>> At 10:43 AM 10/28/2003, Feng Y wrote: >>>>> ... I wonder why the >>>>> overloading or even congestion occurs in diffserv network. >>>>> In diffserv architecture, the =93DS ingress node is >>>>> responsible for ensuring that the traffic entering the DS >>>>> domain conforms to any traffic conditioning agreement (TCA) >>>>> between it and the other domain to which the ingress node >>>>> is connected=94 [RFC 2475]. Moreover, =93Traffic conditioning >>>>> performs metering, shaping, policing and/or re-marking to >>>>> ensure that the traffic entering the DS domain conforms to >>>>> the rules specified in the TCA, in accordance with the >>>>> domain's service provisioning policy=94. So what causes the >>>>> overloading or congestion in diffserv? Does anyone explain >>>>> it for me or give me some references. Thanks in advance. >>>> = >>> >>>> _______________________________________________ >>>> Diffserv-interest mailing list >>>> Diffserv-interest@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/diffserv-interest >>> >>> -- = >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> Brian E Carpenter = >>> >>> Distinguished Engineer, Internet Standards & Technology, IBM = >>> >>> >>> NEW ADDRESS PLEASE UPDATE ADDRESS BOOK >>> >>> >>> >>> --__--__-- >>> >>> _______________________________________________ >>> Diffserv-interest mailing list >>> Diffserv-interest@ietf.org >>> https://www1.ietf.org/mailman/listinfo/diffserv-interest >>> >>> >>> End of Diffserv-interest Digest >> >> _______________________________________________ >> Diffserv-interest mailing list >> Diffserv-interest@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv-interest > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest