From tsvwg-bounces@ietf.org Thu Jan 11 10:58:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52Ja-0000VJ-5e; Thu, 11 Jan 2007 10:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52JY-0000UL-Mv; Thu, 11 Jan 2007 10:58:04 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52JX-0004LX-B6; Thu, 11 Jan 2007 10:58:04 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 1D25FC275; Thu, 11 Jan 2007 10:58:00 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvumQ007815; Thu, 11 Jan 2007 10:57:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvuUs016666; Thu, 11 Jan 2007 10:57:56 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id krzYsOlfF34d; Thu, 11 Jan 2007 10:57:55 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvsNS016651;Thu, 11 Jan 2007 10:57:54 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id E35F54FE10; Thu, 11 Jan 2007 10:55:41 -0500 (EST) Date: Thu, 11 Jan 2007 10:55:41 -0500 From: Wesley Eddy To: iccrg@cs.ucl.ac.uk, tsvwg@ietf.org, tcpm@ietf.org, tsv-area@ietf.org, dccp@ietf.org, rmt@ietf.org Message-ID: <20070111155541.GA25291@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:65.94000 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Tsvwg] review solicitation for ICCRG congestion control survey X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org In the ICCRG's goal to foster a long-term congestion control architecture for the Internet, its initial step is to understand all of the current mechanisms in use. As an aid to this, the ICCRG is working on a document that summarizes all of the congestion control mechanisms and other guidance that the IETF has produced and published in the RFC series. The initial version of this document is online: http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt We think this is a fairly complete listing of the RFCs that relate to congestion control, but if you know of others that should be included, we would like to hear about it. Also, comments on what can be done to make this more useful or readable are welcome. Comments on and improvements to the text summarizing each RFC are also welcome. The goal is to gather these inputs before the ICCRG meeting in mid-February. After the ICCRG meeting, the document will be updated based on these comments and discussion from the meeting. Please send all comments to the ICCRG list (iccrg@cs.ucl.ak.uk). Although this request is being sent to multiple lists, this is only to notify people not on the ICCRG list; we do not want to burden the other mailing lists with replies, so please trim the "to" and "cc" fields of replies. Thanks in advance. -- Wesley M. Eddy Verizon Federal Network Systems From tsvwg-bounces@ietf.org Thu Jan 11 14:06:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55FQ-0003vm-MS; Thu, 11 Jan 2007 14:06:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55FO-0003vS-C3 for tsvwg@ietf.org; Thu, 11 Jan 2007 14:05:58 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55F3-0004GG-5I for tsvwg@ietf.org; Thu, 11 Jan 2007 14:05:58 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l0BJ5WQc004218 for ; Thu, 11 Jan 2007 11:05:32 -0800 (PST) Received: from [129.146.107.78] (d-mpk17-107-78.SFBay.Sun.COM [129.146.107.78]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0BJ5W8s277783 for ; Thu, 11 Jan 2007 11:05:32 -0800 (PST) Message-ID: <45A68ABA.9070501@sun.com> Date: Thu, 11 Jan 2007 11:06:34 -0800 From: Anders Persson User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Tsvwg] TCP and UDP MIB issues X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Everyone, During the v6ops meeting at IETF 66 we presented some issues with the current TCP and UDP MIBs, however, it was quickly pointed out that the TSVWG would be a more appropriate venue. The main issue that we are trying to address is how to present associations between system processes and TCP/UDP endpoints when there are multiple processes associated with one endpoint. A draft[1] is available that describes the issue and which also contains a first attempt at a TCP/UDP extension MIB. It would be highly appreciated if members of the TSVWG could help out reviewing this draft. Thanks, Anders [1] http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt From tsvwg-bounces@ietf.org Thu Jan 11 14:42:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55oF-0001BY-Ac; Thu, 11 Jan 2007 14:41:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55oE-0001A4-Ok for tsvwg@ietf.org; Thu, 11 Jan 2007 14:41:58 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55oB-0006Fl-GL for tsvwg@ietf.org; Thu, 11 Jan 2007 14:41:58 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l0BJfsCE020007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 14:41:54 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id l0BJfscK021644; Thu, 11 Jan 2007 14:41:54 -0500 Date: Thu, 11 Jan 2007 14:41:54 -0500 (EST) From: Matt Mathis To: Anders Persson Subject: Re: [Tsvwg] TCP and UDP MIB issues In-Reply-To: <45A68ABA.9070501@sun.com> Message-ID: References: <45A68ABA.9070501@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Does this conflict with http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt (currently between states in IESG review). The TCP Extended Statistics MIB also AUGMENTS both the tcpConnectionEntry and tcpListenerEntry. I am not enough of a mib person to understand how multiple AUGMENTS clauses might interact. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- On Thu, 11 Jan 2007, Anders Persson wrote: > Hi Everyone, > > During the v6ops meeting at IETF 66 we presented some issues with the > current TCP and UDP MIBs, however, it was quickly pointed out that the > TSVWG would be a more appropriate venue. The main issue that we are > trying to address is how to present associations between system > processes and TCP/UDP endpoints when there are multiple processes > associated with one endpoint. > > A draft[1] is available that describes the issue and which also contains > a first attempt at a TCP/UDP extension MIB. It would be highly > appreciated if members of the TSVWG could help out reviewing this draft. > > Thanks, > Anders > > [1] http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt > > From tsvwg-bounces@ietf.org Thu Jan 11 14:59:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H564P-0003YB-K6; Thu, 11 Jan 2007 14:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H564O-0003Y2-AL for tsvwg@ietf.org; Thu, 11 Jan 2007 14:58:40 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5647-0002yG-Jy for tsvwg@ietf.org; Thu, 11 Jan 2007 14:58:40 -0500 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBP0081DZGVYZ@firewall.mci.com> for tsvwg@ietf.org; Thu, 11 Jan 2007 19:58:10 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBP0010KZGVCE@dgismtp04.mcilink.com> for tsvwg@ietf.org; Thu, 11 Jan 2007 19:58:07 +0000 (GMT) Received: from XS344V8061891 ([153.39.146.250]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBP001AFZGR1Q@dgismtp04.mcilink.com> for tsvwg@ietf.org; Thu, 11 Jan 2007 19:58:07 +0000 (GMT) Date: Thu, 11 Jan 2007 14:57:59 -0500 From: Dave McDysan To: 'tsvwg' Message-id: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AccaFPGygUS34kv4QbSVoRtjToe+TgUZdSWQAc/2uGA= X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Subject: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Resending these comments. I did not receive a copy via the tsvwg mailing list and it was not in the archives. Dave -----Original Message----- From: Dave McDysan [mailto:dave.mcdysan@verizon.com] Sent: Tuesday, January 02, 2007 11:03 AM To: 'Magnus Westerlund'; 'tsvwg' Cc: 'Fred Baker'; 'Kwok-Ho Chan'; 'babiarz@nortel.com' Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr As requested, here is my review of the subject draft. Within Verizon and draft work in the MPLS FR ATM Alliance (MFA) we are using RFC 4594 and ITU-T Y.1541 in our definitions of Diffserv, PW and native MPLS deployments. An RFC that gave some guidance and a baseline for how to map these various services to treatment aggregates as defined by MPLS EXP bits would be extremely useful for internal use as well as use in specifying network interconnections. These comments are based upon a review of the various deployed and proposed uses of EXP bits within Verizon, experience on negogiating interconnects with other service providers, work within the MFA and the results of MIT Interprovider QoS workshops, as summarized in the following: http://cfp.mit.edu/resources/papers/Interprovider%20QoS%20MIT_CFP_WP_9_14_06 .pdf Suggest that in section 1, Introduction that the draft explicitly state the assumption that all traffic is IP and marked with a particular set of DSCP values, as described in RFC 4594. In some cases cited below bullet 5 in section 3, overview of service class aggregation, the traffic carried may not be IP (e.g., TDM, FR, ATM or Ethernet over pseudowire, VPLS). Section 2, Terminology, references RFC 3270 definitions of E-LSP and L-LSP, which include the concept of a Forwarding Equivalency Class (FEC). I suggest that either the scope of this draft should be constrained to only IP and these other applications be mentioned as out of scope, or else more text regarding handling of non-IP applications needs to be added. For example, there could be an IP FEC and a non-IP FEC for use with E-LSP or L-LSP from RFC 3270. Suggest that the authors add some text to section 4.1., Mapping Service Classes into Four Treatment Aggregates, explaining why those chose 4 instead of 3 or 5 treatment aggregates. From section 1, " Note that in a given domain, we may recommend that the supported service classes be aggregated into forwarding treatment aggregates; however, this does not mean all service classes need to be supported and hence not all forwarding treatment aggregates need to be supported." This text implies specification of a maximum set of treatment aggregates, and a means to map these to a minimum set. Is the intent of this draft to specify the minimum or maximum set? In Figure 1, Treatment Aggregate and Service Class Performance Requirements, I think that broadcast video is not Real-Time. Also, in enterprise VPNs, we have distinguished Telephony/Signaling from Mulitmedia conferencing in treatment aggregates in deployed networks. Section 4.1.1. Network Control Treatment Aggregate. We view network control as an IP-only service class, not subject to (MPLS) treatment aggregation. Although some VPN service providers have proposed extending this service class across an interconnect to their networks, we have convinced them that they should map customer network control traffic (e.g., BGP, or IGP information for an RFC 4364 VPN) or their own network control class to some other behavior or treatment aggregate. Suggest that the draft add some text indicating that network control traffic is for internal use to a network. For example, Section 4.2.1 of RFC 4274 could be cited: "The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network. [RFC791]" 4.1.2. Real Time Treatment Aggregate. As mentioned above, current and planned deployments break out telephony/signaling from multimedia conferencing and broadcast video. If the draft is proposing that the real-time treatment aggregate (as defined in 1994 from RFC 1633) is part of a minimum treatment aggregate set, then it should state this. I would like to see mention of a larger treatment aggregate set that at least splits out telephony/signaling from multimedia conferencing and broadcast video. 4.1.3. Assured Elastic Treatment Aggregate. Personally, I think that the indication of loss probability in a treatment aggregate is a good idea. However, some deployments and plans do not use this. Also, this means using up to an additional bit in the limited 3-bit MPLS EXP field. Suggest that the draft state that indicating the loss probability is highly desirable, but may not be part of the minimum set of treatment aggregates that a network segment may implement (see section 1). 4.1.4. Elastic Treatment Aggregate. Personally, I think that the indication of loss probability in a treatment aggregate is a good idea. However, some deployments and plans do not use this. Also, this means using up to an additional bit in the limited 3-bit MPLS EXP field. Suggest that the draft state that indicating the loss probability is highly desirable, but may not be part of the minimum set of treatment aggregates that a network segment may implement (see section 1). 5. Using MPLS for Treatment Aggregates, first paragraph. As mentioned above, suggest that the authors clarify whether this is the maximum or minimum set of treatment aggregates as described in section 1 that are recommended. This section is where the most significant issues exist. 5.1. Network Control Treatment Aggregate with E-LSP In discussions with internal users as well as discussions in the MFA, there is not much support for using a set of MPLS EXP bits for network control. Looking at the description for network control from RFC 4594, it appears that most of these uses would be IP only and not be subject to MPLS encapsulation. The one exception we discussed is how to handle network control DSCP marked packets from BGP IP MPLS VPN customers. This could be done using the proposed "110" codepoint in Figure 3, but another method would be for the service provider to map customer network control traffic to some other treatment aggregate (e.g., assured elastic). Suggest that the network control treatment aggregate usage with MPLS EXP bit marking be more clearly stated in the draft. Also, suggest that the network control treatment aggregate be part of the maximum treatment aggregate set. 5.2. Real Time Treatment Aggregate with E-LSP As mentioned above, this differs from uses within Verizon, the MIT QoS Interprovider workshop and discussions in the MFA. The MPLS EXP bit values of "101" are used in at least these contexts to indicate only telephony/signaling for EF/CS5. This is the most significant difference between the draft and other publications and industry work. Also we have assigned the AF4x DSCP for multimedia conferencing as MPLS EXP "100," and also treat broadcast video as another RFC 3270 FEC. In order to resolve this comment, suggest that the draft define a minimum subset of the "real-time" treatment aggregate and mention that some network segments (see section 1) may define a larger set along the lines of what I mention above. Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment Aggregate with E-LSP These MPLS EXP code points (without the loss probability bit encoding) are what is used in several VPN and public IP networks. Section 5 - Additional comments If the scope decision of this document is to expand to non-IP applications, then additional text on handling Pseudowires with client services having their own QoS definitions, VPLS and other potential uses of MPLS would need to be added. My recommendation would be to keep this document focused on the IP applications, and if anyone is interested then another document that covered non-IP applications could be drafted. 6. Treatment Aggregates and Inter-Provider Relationships Suggest addition of a reference to the MIT QoS Interprovider white paper mentioned above. After much discussion, the service providers involved in this effort were only able to agree on a minimum set of two treatment aggregates. Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. Appendix VI defines a minimum set of three QoS classes and a mapping to (sets of) IETF DSCP values as follows: Y.1221 Associated Y.1541 Transfer Diffserv QoS Capability PHBs Class(es) ------------ ---------- -------- Best Effort Default 5 Delay-Sensitive AF 2,3,4 Statistical BW Dedicated EF 0,1 Bandwidth (If you don't have ITU access, you can get up to three free ITU-T documents per Email address by going to www.itu.int and going to the purchase page and entering your email address.) Many international providers look to the ITU-T for guidance, and that would be the focus on many of our network provider interconnection uses of treatment aggregates and MPLS EXP bit markings. Therefore, at least some mention of a similar minimum subset of aggregations proposed by the ITU-T in this document would be valuable. Finally, I note that if network control is removed from the minimum subset in this draft, then the above set from ITU-T Y.1541 Appendix VI is equivalent in terms of number of treatment aggregates and a high-level mapping of service capabilities. Regards, Dave > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, December 07, 2006 10:32 AM > To: tsvwg > Subject: [Tsvwg] Need for volunteers for reviewing > draft-ietf-tsvwg-diffserv-class-aggr > > Hi, > > To make progress we need some reviewers to read and comment on > "Aggregation of DiffServ Service Classes": > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-ag > gr-01.txt > > We chairs don't think we can proceed with this draft until we seen > some confirming reviews from the WG participants. So please volunteer. > > If you are willing to do this review please indicate so to us chairs. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > From tsvwg-bounces@ietf.org Thu Jan 11 15:52:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56uB-0000KJ-2R; Thu, 11 Jan 2007 15:52:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56u9-0000If-LJ for tsvwg@ietf.org; Thu, 11 Jan 2007 15:52:09 -0500 Received: from clyde.ncr.disa.mil ([164.117.144.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H56tp-0008Ea-Kb for tsvwg@ietf.org; Thu, 11 Jan 2007 15:52:09 -0500 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by clyde.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 15:52:59 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr (UNCLASSIFIED) Date: Thu, 11 Jan 2007 15:52:59 -0500 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A973E7@vanualevu.disanet.disa-u.mil> In-Reply-To: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr (UNCLASSIFIED) Thread-Index: AccaFPGygUS34kv4QbSVoRtjToe+TgUZdSWQAc/2uGAAAN8mIA== From: "Nguyen, An P CIV NCS NC2" To: "Dave McDysan" X-OriginalArrivalTime: 11 Jan 2007 20:52:59.0702 (UTC) FILETIME=[7A69A560:01C735C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Nguyen, An P CIV NCS NC2" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Classification: UNCLASSIFIED=20 Caveats: NONE Dave, Just a question for verification: Does dedicated bandwidth in the Y.1221 column below mean fixed connectivity? Thanks, An -----------------------------------------------=20 6. Treatment Aggregates and Inter-Provider Relationships Suggest addition of a reference to the MIT QoS Interprovider white paper mentioned above. After much discussion, the service providers involved in this effort were only able to agree on a minimum set of two treatment aggregates. Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. Appendix VI defines a minimum set of three QoS classes and a mapping to (sets of) IETF DSCP values as follows: Y.1221 Associated Y.1541 Transfer Diffserv QoS Capability PHBs Class(es) ------------ ---------- -------- Best Effort Default 5 Delay-Sensitive AF 2,3,4 Statistical BW Dedicated EF 0,1 Bandwidth =20 Dave > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, December 07, 2006 10:32 AM > To: tsvwg > Subject: [Tsvwg] Need for volunteers for reviewing=20 > draft-ietf-tsvwg-diffserv-class-aggr >=20 > Hi, >=20 > To make progress we need some reviewers to read and comment on=20 > "Aggregation of DiffServ Service Classes": > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-ag > gr-01.txt >=20 > We chairs don't think we can proceed with this draft until we seen=20 > some confirming reviews from the WG participants. So please volunteer. >=20 > If you are willing to do this review please indicate so to us chairs. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 >=20 Classification: UNCLASSIFIED=20 Caveats: NONE From tsvwg-bounces@ietf.org Thu Jan 11 16:44:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57iY-0006pc-1y; Thu, 11 Jan 2007 16:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57iW-0006pR-Gx for tsvwg@ietf.org; Thu, 11 Jan 2007 16:44:12 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57iU-0004m2-TC for tsvwg@ietf.org; Thu, 11 Jan 2007 16:44:12 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0BLi6T08603; Thu, 11 Jan 2007 16:44:06 -0500 (EST) Received: from KCHAN-2K3.nortel.com ([47.16.54.125] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 16:44:04 -0500 Message-Id: <6.2.5.6.0.20070111163724.03332008@nortel.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Jan 2007 16:44:02 -0500 To: Dave McDysan From: "Kwok-Ho Chan" Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr In-Reply-To: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> References: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jan 2007 21:44:04.0704 (UTC) FILETIME=[9D4BD600:01C735C9] X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: 'tsvwg' X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dave: Thank you very much for the detail comments. I will need some time to go through them carefully and address them appropriately. Thanks! -- Kwok -- At 02:57 PM 1/11/2007, Dave McDysan wrote: >Resending these comments. I did not receive a copy via the tsvwg mailing >list and it was not in the archives. > >Dave > >-----Original Message----- >From: Dave McDysan [mailto:dave.mcdysan@verizon.com] >Sent: Tuesday, January 02, 2007 11:03 AM >To: 'Magnus Westerlund'; 'tsvwg' >Cc: 'Fred Baker'; 'Kwok-Ho Chan'; 'babiarz@nortel.com' >Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr > >As requested, here is my review of the subject draft. > >Within Verizon and draft work in the MPLS FR ATM Alliance (MFA) we are using >RFC 4594 and ITU-T Y.1541 in our definitions of Diffserv, PW and native MPLS >deployments. An RFC that gave some guidance and a baseline for how to map >these various services to treatment aggregates as defined by MPLS EXP bits >would be extremely useful for internal use as well as use in specifying >network interconnections. These comments are based upon a review of the >various deployed and proposed uses of EXP bits within Verizon, experience on >negogiating interconnects with other service providers, work within the MFA >and the results of MIT Interprovider QoS workshops, as summarized in the >following: >http://cfp.mit.edu/resources/papers/Interprovider%20QoS%20MIT_CFP_WP_9_14_06 >.pdf > >Suggest that in section 1, Introduction that the draft explicitly state the >assumption that all traffic is IP and marked with a particular set of DSCP >values, as described in RFC 4594. > >In some cases cited below bullet 5 in section 3, overview of service class >aggregation, the traffic carried may not be IP (e.g., TDM, FR, ATM or >Ethernet over pseudowire, VPLS). Section 2, Terminology, references RFC 3270 >definitions of E-LSP and L-LSP, which include the concept of a Forwarding >Equivalency Class (FEC). I suggest that either the scope of this draft >should be constrained to only IP and these other applications be mentioned >as out of scope, or else more text regarding handling of non-IP applications >needs to be added. For example, there could be an IP FEC and a non-IP FEC >for use with E-LSP or L-LSP from RFC 3270. > >Suggest that the authors add some text to section 4.1., Mapping Service >Classes into Four Treatment Aggregates, explaining why those chose 4 instead >of 3 or 5 treatment aggregates. From section 1, " Note that in a given >domain, we may recommend that the supported service classes be aggregated >into forwarding treatment aggregates; however, this does not mean all >service classes need to be supported and hence not all forwarding treatment >aggregates need to be supported." This text implies specification of a >maximum set of treatment aggregates, and a means to map these to a minimum >set. Is the intent of this draft to specify the minimum or maximum set? > >In Figure 1, Treatment Aggregate and Service Class Performance Requirements, >I think that broadcast video is not Real-Time. Also, in enterprise VPNs, we >have distinguished Telephony/Signaling from Mulitmedia conferencing in >treatment aggregates in deployed networks. > >Section 4.1.1. Network Control Treatment Aggregate. We view network control >as an IP-only service class, not subject to (MPLS) treatment aggregation. >Although some VPN service providers have proposed extending this service >class across an interconnect to their networks, we have convinced them that >they should map customer network control traffic (e.g., BGP, or IGP >information for an RFC 4364 VPN) or their own network control class to some >other behavior or treatment aggregate. > >Suggest that the draft add some text indicating that network control traffic >is for internal use to a network. For example, Section 4.2.1 of RFC 4274 >could be cited: "The Network Control precedence designation is intended to >be used within a network only. The actual use and control of that >designation is up to each network. [RFC791]" > >4.1.2. Real Time Treatment Aggregate. As mentioned above, current and >planned deployments break out telephony/signaling from multimedia >conferencing and broadcast video. If the draft is proposing that the >real-time treatment aggregate (as defined in 1994 from RFC 1633) is part of >a minimum treatment aggregate set, then it should state this. I would like >to see mention of a larger treatment aggregate set that at least splits out >telephony/signaling from multimedia conferencing and broadcast video. > >4.1.3. Assured Elastic Treatment Aggregate. Personally, I think that the >indication of loss probability in a treatment aggregate is a good idea. >However, some deployments and plans do not use this. Also, this means using >up to an additional bit in the limited 3-bit MPLS EXP field. Suggest that >the draft state that indicating the loss probability is highly desirable, >but may not be part of the minimum set of treatment aggregates that a >network segment may implement (see section 1). > >4.1.4. Elastic Treatment Aggregate. Personally, I think that the indication >of loss probability in a treatment aggregate is a good idea. However, some >deployments and plans do not use this. Also, this means using up to an >additional bit in the limited 3-bit MPLS EXP field. Suggest that the draft >state that indicating the loss probability is highly desirable, but may not >be part of the minimum set of treatment aggregates that a network segment >may implement (see section 1). > >5. Using MPLS for Treatment Aggregates, first paragraph. As mentioned >above, suggest that the authors clarify whether this is the maximum or >minimum set of treatment aggregates as described in section 1 that are >recommended. > >This section is where the most significant issues exist. > >5.1. Network Control Treatment Aggregate with E-LSP > >In discussions with internal users as well as discussions in the MFA, there >is not much support for using a set of MPLS EXP bits for network control. >Looking at the description for network control from RFC 4594, it appears >that most of these uses would be IP only and not be subject to MPLS >encapsulation. The one exception we discussed is how to handle network >control DSCP marked packets from BGP IP MPLS VPN customers. This could be >done using the proposed "110" codepoint in Figure 3, but another method >would be for the service provider to map customer network control traffic to >some other treatment aggregate (e.g., assured elastic). Suggest that the >network control treatment aggregate usage with MPLS EXP bit marking be more >clearly stated in the draft. Also, suggest that the network control >treatment aggregate be part of the maximum treatment aggregate set. > >5.2. Real Time Treatment Aggregate with E-LSP > >As mentioned above, this differs from uses within Verizon, the MIT QoS >Interprovider workshop and discussions in the MFA. The MPLS EXP bit values >of "101" are used in at least these contexts to indicate only >telephony/signaling for EF/CS5. This is the most significant difference >between the draft and other publications and industry work. Also we have >assigned the AF4x DSCP for multimedia conferencing as MPLS EXP "100," and >also treat broadcast video as another RFC 3270 FEC. > >In order to resolve this comment, suggest that the draft define a minimum >subset of the "real-time" treatment aggregate and mention that some network >segments (see section 1) may define a larger set along the lines of what I >mention above. > >Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment Aggregate with E-LSP > >These MPLS EXP code points (without the loss probability bit encoding) are >what is used in several VPN and public IP networks. > >Section 5 - Additional comments > >If the scope decision of this document is to expand to non-IP applications, >then additional text on handling Pseudowires with client services having >their own QoS definitions, VPLS and other potential uses of MPLS would need >to be added. My recommendation would be to keep this document focused on the >IP applications, and if anyone is interested then another document that >covered non-IP applications could be drafted. > >6. Treatment Aggregates and Inter-Provider Relationships > >Suggest addition of a reference to the MIT QoS Interprovider white paper >mentioned above. After much discussion, the service providers involved in >this effort were only able to agree on a minimum set of two treatment >aggregates. > >Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. Appendix >VI defines a minimum set of three QoS classes and a mapping to (sets of) >IETF DSCP values as follows: > >Y.1221 Associated Y.1541 >Transfer Diffserv QoS >Capability PHBs Class(es) >------------ ---------- -------- >Best Effort Default 5 > >Delay-Sensitive AF 2,3,4 >Statistical BW > >Dedicated EF 0,1 >Bandwidth > >(If you don't have ITU access, you can get up to three free ITU-T documents >per Email address by going to www.itu.int and going to the purchase page and >entering your email address.) > >Many international providers look to the ITU-T for guidance, and that would >be the focus on many of our network provider interconnection uses of >treatment aggregates and MPLS EXP bit markings. Therefore, at least some >mention of a similar minimum subset of aggregations proposed by the ITU-T in >this document would be valuable. Finally, I note that if network control is >removed from the minimum subset in this draft, then the above set from ITU-T >Y.1541 Appendix VI is equivalent in terms of number of treatment aggregates >and a high-level mapping of service capabilities. > >Regards, > >Dave > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, December 07, 2006 10:32 AM > > To: tsvwg > > Subject: [Tsvwg] Need for volunteers for reviewing > > draft-ietf-tsvwg-diffserv-class-aggr > > > > Hi, > > > > To make progress we need some reviewers to read and comment on > > "Aggregation of DiffServ Service Classes": > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-ag > > gr-01.txt > > > > We chairs don't think we can proceed with this draft until we seen > > some confirming reviews from the WG participants. So please volunteer. > > > > If you are willing to do this review please indicate so to us chairs. > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > > > From tsvwg-bounces@ietf.org Thu Jan 11 17:34:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Uc-0003qz-G3; Thu, 11 Jan 2007 17:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Ub-0003mI-Ac for tsvwg@ietf.org; Thu, 11 Jan 2007 17:33:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58UW-0001Gg-Kd for tsvwg@ietf.org; Thu, 11 Jan 2007 17:33:53 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2007 14:33:49 -0800 X-IronPort-AV: i="4.13,175,1167638400"; d="scan'208"; a="355841294:sNHT123359898" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0BMXl5n019140; Thu, 11 Jan 2007 14:33:47 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0BMXlDm001628; Thu, 11 Jan 2007 14:33:47 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:33:30 -0800 Received: from [10.32.241.73] ([10.32.241.73]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:33:29 -0800 In-Reply-To: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> References: <0JBP001AHZGU1Q@dgismtp04.mcilink.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5726EFB0-E059-452E-B87C-3CFBCCC2DE70@cisco.com> Content-Transfer-Encoding: 7bit From: Bruce Davie Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: Thu, 11 Jan 2007 17:33:26 -0500 To: tsvwg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jan 2007 22:33:29.0103 (UTC) FILETIME=[843739F0:01C735D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=48183; t=1168554828; x=1169418828; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[Tsvwg]=20FW=3A=20Review=20of=20=20draft-ietf-tsvwg-d iffserv-class-aggr |Sender:=20; bh=JA6jwv6V0Lgrgde/gG4wviejqJd8PJ0R09gapIv3FV4=; b=FK5dYbUyoP4czF6PtqOyvqev1Djd4eL1jcDYJCHN68bVu40slWFaFvdDm5MowkqdLd/f/jHn vGRkOjTImx8MiIJ2UpefeLQRDk0YNP/4ueBOdhgtJIVvApviN+yqWd0L; Authentication-Results: sj-dkim-4; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: eed7ea9c02f6a53fd173427a25738752 Cc: Magnus Westerlund X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org I too send comments that never made it to the archive. Here they are again. Bruce From: bdavie@cisco.com Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: December 21, 2006 11:20:33 AM EST To: magnus.westerlund@ericsson.com Cc: tsvwg@ietf.org As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- aggr-01.txt My line by line comments are below, prefaced by [BD] My top level comments are as follows: 1. The main contribution of this draft can be summarized very briefly: you can aggregate different classes of traffic into bigger classes that get the same treatment as long as that treatment is good enough to meet the needs of the most stringent class. 2. A second contribution is to observe that if you do aggregate, it would be nice to preserve markings such that de-aggregation can be performed later. 3. Beyond that, the document makes a lot of specific recommendations about precisely how you should aggregate in both IP and MPLS networks. My concern with this aspect of the document is that there are essentially an infinite number of valid ways to aggregate traffic. For example, one of the most popular is to give all traffic in the core of an over-provisioned network the same treatment - so- called "best effort" treatment, but actually it is a treatment that is so good that even the most stringent class of traffic gets adequate service. This approach to aggregation goes unmentioned in the document, as does the fact that many other options are valid. At a minimum, this document should be revised to make it clear that it is describing ONE possible approach out of many more that are possible. Since it is being progressed by the TSVWG, statements that begin "we recommend..." should probably be rewritten to be of the form "A possible option is..." A great deal of effort went into writing the DiffServ standards in such a way that operators and vendors would not be overly constrained. A set of recommendations from the TSVWG, even in an informational RFC, to the effect that there is only one valid way to run a Diffserv network, does not seem like something we want to produce. Bruce -------- TSVWG K. Chan Internet-Draft J. Babiarz Intended status: Informational Nortel Networks Expires: April 23, 2007 F. Baker Cisco Systems October 20, 2006 Aggregation of DiffServ Service Classes draft-ietf-tsvwg-diffserv-class-aggr-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In the core of a high capacity network, service differentiation is still needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into diffserv service classes based on end- to-end behavior requirements of the applications as indicated by Diffserv Service Classes [5]. However, some network segments may be Chan, et al. Expires April 23, 2007 [Page 1] Internet-Draft Document October 2006 configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv Service Classes [5] into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv Service Classes [5] into forwarding treatments. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10 5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11 5.1. Network Control Treatment Aggregate with E- LSP . . . . . . 13 5.2. Real Time Treatment Aggregate with E- LSP . . . . . . . . . 13 5.3. Assured Elastic Treatment Aggregate with E- LSP . . . . . . 13 5.4. Elastic Treatment Aggregate with E- LSP . . . . . . . . . . 13 5.5. Treatment Aggregates and L- LSP . . . . . . . . . . . . . . 14 6. Treatment Aggregates and Inter-Provider Relationships . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Chan, et al. Expires April 23, 2007 [Page 2] Internet-Draft Document October 2006 1. Introduction In the core of a high capacity network, it is common for the network to be engineered in such a way that a major link, switch, or router can fail and the result will be a routed network that still meets ambient SLAs. The implication of this is that there is sufficient capacity on any given link such that all SLAs sold can be simultaneously supported at their respective maximum rates, and that this remains true after re-routing (either IP re-routing or MPLS protection-mode switching) has occurred. Over-provisioning is generally considered to meet the requirements of all traffic without further QoS treatment, and in the general case that is true in high capacity backbones. However, as the process of network convergence continues, and with the increasing speed of the access networks, certain services still have issues. Delay, jitter, and occasional loss are perfectly acceptable for elastic applications. However, sub-second surges that occur in the best- designed of networks [14] affect real-time applications. Moreover, DOS loads, worms, and network disruptions such as that of 11 September 2001 affect routing [15]. Our objective is to prevent disruption to routing (which in turn affects all services), and jitter-sensitive services that may be revenue-bearing. [BD] It took me a long time to understand the above sentence. It could be read to mean that an objective of the draft is to prevent jitter sensitive services, which is probably not the intent. Also, I think the comment about preventing disruption to routing relates to the desire to protect network control traffic from loss, so perhaps you should say that (since there are lots of ways that routing may get disrupted that are outside the scope of this draft). The document "Diffserv Service Classes" [5] defines the basic diffserv classes from the points of view of the application requiring specific end-to-end behaviors from the network. The service classes are differentiated based on the traffic-payload's tolerance to packet loss, delay, and delay variation (jitter). Different degrees of these criterions form the foundation for supporting the needs of [BD] criterions -> criteria, or even better "Different values of these metrics form..." real-time and elastic traffic. The "Diffserv Service Classes" [5] document also provides recommendations for the treatment method of these service classes. But, at some network segments of the end-to- end path, the number of levels of network treatment differentiation may be less than the number of service classes that the network segment needs to support. In such a situation, that network segment may use the same treatment to support more than one service class. In this document we provide guidelines on how multiple service classes may be aggregated into a forwarding treatment aggregate. Note that in a given domain, we may recommend that the supported service classes be aggregated into forwarding treatment aggregates; however, this does not mean all service classes need to be supported and hence not all forwarding treatment aggregates need to be supported. Which service classes and which forwarding treatment aggregates are supported by a domain is up to the domain administration and may be influenced by business reasons. In this document, we've provided: Chan, et al. Expires April 23, 2007 [Page 3] Internet-Draft Document October 2006 o definitions for terminology we use in this document, o requirements for performing this aggregation, o an example of performing this aggregation over MPLS using E-LSP. The treatment aggregate recommendations are designed to aggregate the service classes [5] in such a manner as to protect real-time traffic and routing, on the assumption that real-time sessions are protected from each other by admission at the edge. An example of aggregation over MPLS networks using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to realize the treatment aggregates is provided. Note that the MPLS E-LSP is just an example; this document does not exclude the use of other methods. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. Terminology This document assumes the reader is familiar with the terms used in differentiated services. This document provides the definitions for new terms introduced by this document and referencing information for existing none differentiated services terms defined in existing RFCs. For new terms introduced by this document, we provide the definition here: o Treatment Aggregate. This term is used here to indicate the aggregate of DiffServ service classes. This is different from Behavior Aggregate and Traffic Aggregate because Treatment Aggregate is only concerned with the treatment of the aggregated traffic. It does not concern itself with how the aggregated traffic is marked, and hence does not put a restriction on the aggregated traffic having a single diffserv codepoint that have a single PHB. For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition: o Real-Time and Elastic Applications and their traffic. Section 3.1 of RFC 1633 [6]. Chan, et al. Expires April 23, 2007 [Page 4] Internet-Draft Document October 2006 o Diffserv Service Class. Section 1.3 of draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of RFC 3270 [8]. o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.3 of RFC 3270 [8]. 3. Overview of Service Class Aggregation In diffserv domains where less granular traffic treatment differentiation is provided, aggregation of the different service classes [5] may be required. These aggregations have the following requirements: [BD] I don't understand where these requirements come from. 1. The end-to-end network performance characteristic required by the application must be supported. This performance characteristic is represented by the use of Diffserv Service Classes [5]. 2. The treatment aggregate must exhibit the strictest requirement of its member service classes. 3. The treatment aggregate should only contain member service classes with similar traffic characteristic and performance requirements. [BD] Why? Isn't it OK to aggregate wildly different service classes and give them all treatment that is a good as the most stringent requirements of any class? 4. The notion of the individual end-to-end service classes must not be destroyed when aggregation is performed. Each domain along the end-to-end path may perform aggregation differently, based on the original end-to-end service classes. We recommend an easy way to accomplish this by not altering the DSCP used to indicate the end-to-end service class. But some administrative domains may require the use of their own marking; when this is needed, the original end-to-end service class indication must be restored upon exiting such administrative domains. [BD] You seem to have strayed away from stating requirements when you start recommending how to mark the DSCP. I *think* that what you are trying to say is that the information about which service class belongs to should not be lost during aggregation; such information loss would occur, for example, if several different classes were remarked to a common DSCP value. 5. Each treatment aggregate has limited resources, hence traffic conditioning and/or admission control must be performed for each service class aggregated into the treatment aggregate. [BD] Where is this requirement from? Are you saying that it's not possible to aggregate traffic with also performing admission control or traffic conditioning? Many SPs would disagree. with the following suggestions: 1. The treatment aggregate and assigned resources may consider historical traffic patterns and the variability of these patterns. For example, a point-point service (e.g., pseudowire) Chan, et al. Expires April 23, 2007 [Page 5] Internet-Draft Document October 2006 may have a very predictable pattern, while a multipoint service (e.g., VPLS) may have a much less predictable pattern. Even the traffic patterns within the Internet may vary widely. 2. In addition to Diffserv, other controls are available to influence the traffic level offered to a particular traffic aggregate. These include adjustment of routing metrics, usage of MPLS-based traffic engineering techniques. 4. Service Classes to Treatment Aggregate Mapping The service class and DSCP selection in "Diffserv Service Classes" [5] has been defined to allow, in many instances, mapping of two or possibly more service classes into a single forwarding treatment aggregate. Notice that there is a relationship/trade-off between link speed, queue depth, delay, and jitter. [BD] The preceding sentence should also mention link utilization. The degree of aggregation and hence the number of treatment aggregates will depend on whether the speed of the links and scheduler behavior, being used to implement the aggregation, can minimize the affects of mixing traffic with different packet sizes and transmit rates on queue depth. And their impacts on loss, delay, and jitter. A general rule-of-thumb is that higher link speeds allow for more aggregation/ smaller number of treatment aggregates. [BD] That rule of thumb seems to be incorrect if a link is run at 100% utilization. A more useful rule of thumb might take utilization into accoutn. 4.1. Mapping Service Classes into Four Treatment Aggregates [BD] It is probably worth mentioning that this is just an example and that more or fewer treatment aggregates may be required. This section explains one way of performing this aggregation by using four treatment aggregates. The use of four treatment aggregates assumes that the resources allocated to each treatment aggregate is sufficient to honor the required behavior of each service class [5] in each of the four treatment aggregates. We use the performance requirement (tolerance to loss, delay, and jitter) from the application/end-user as a guide on how to map the service classes into treatment aggregates. We have also used Section 3.1 of RFC 1633 [6] to provide us with guidance on the definition of Real-Time and Elastic applications. An overview of the mapping between service classes and the four treatment aggregates is provided by Figure 1, with the mapping being based on performance requirements. In Figure 1, the right side columns of "Service Class", "Tolerance to Loss/ Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. It is recommended that certain service classes be mapped into specific treatment aggregates. But this does not mean that all the service classes recommended for that treatment aggregate need to be supported. Hence, for a given domain, a treatment aggregate may contain only a subset of the service classes recommended in this document, they being the service classes supported by that domain. A Chan, et al. Expires April 23, 2007 [Page 6] Internet-Draft Document October 2006 domain's treatment of non-supported service classes should be based on the domain's local policy. This local policy may be influenced by its agreement with its customers. Such treatment may use the Elastic Treatment Aggregate, dropping the packets, or some other arrangements. --------------------------------------------------------------------- |Treatment | Tolerance to ||Service Class | Tolerance to | |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| |==========+======+======+======++===============+======+======+======| | Network | Low | Low | Yes || Network | Low | Low | Yes | | Control | | | || Control | | | | |==========+======+======+======++===============+======+======+======| | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | | Time | Low | Low | Low ||---------------+------+------+------| | | | | || Signaling | Low | Low | Yes | | | | | ||---------------+------+------+------| | | | | || Multimedia |Low - | Very | Low | | | | | || Conferencing |Medium| Low | | | | | | ||---------------+------+------+------| | | | | || Real-time | Low | Very | Low | | | | | || Interactive | | Low | | | | | | ||---------------+------+------+------| | | | | || Broadcast | Very |Medium| Low | | | | | || Video | Low | | | |==========+======+======+======++===============+======+======+======| | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | | Elastic | |Medium| || Streaming |Medium| | | | | | | ||---------------+------+------+------| | | | | || Low Latency | Low |Low - | Yes | | | | | || Data | |Medium| | | | | | ||---------------+------+------+------| | | | | || OAM | Low |Medium| Yes | | | | | ||---------------+------+------+------| | | | | ||High Throughput| Low |Medium| Yes | | | | | || Data | |- High| | |==========+======+======+======++===============+======+======+======| | Elastic | Not Specified || Standard | Not Specified | | | | | ||---------------+------+------+------| | | | | || Low Priority | High | High | Yes | | | | | || Data | | | | --------------------------------------------------------------------- Figure 1: Treatment Aggregate and Service Class Performance Requirements As we are recommending to preserve the notion of the individual end- to-end service classes, we also recommend that the original DSCP Chan, et al. Expires April 23, 2007 [Page 7] Internet-Draft Document October 2006 field marking not be changed when treatment aggregates are used. Instead, classifiers that select packets based on the contents of the DSCP field should be used to direct packets from the member DiffServ Service Classes into the queue that handles each of the treatment aggregates, without remarking the DSCP field of the packets. This is summarized in Figure 2, which shows the behavior each Treatment Aggregate should have, and the DSCP field marking of the packets that should be classified into each of the treatment aggregates. ------------------------------------------------------------ |Treatment |Treatment || DSCP | |Aggregate |Aggregate || | | |Behavior || | |==========+==========++=====================================| | Network | CS || CS6 | | Control |(RFC 2474)|| | |==========+==========++=====================================| | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | | Time |(RFC 3246)|| | |==========+==========++=====================================| | Assured | AF || CS2, AF31, AF21, AF11 | | Elastic |(RFC 2597)||-------------------------------------| | | || AF32, AF22, AF12 | | | ||-------------------------------------| | | || AF33, AF23, AF13 | |==========+==========++=====================================| | Elastic | Default || Default, (CS0) | | |(RFC 2474)||-------------------------------------| | | || CS1 | ------------------------------------------------------------ Figure 2: Treatment Aggregate Behavior 4.1.1. Network Control Treatment Aggregate The Network Control Treatment Aggregate aggregates all service classes that are functionally necessary for the survival of a network during a DOS attack or other high traffic load interval. The theory is that whatever else is true, the network must protect itself. This includes the traffic that "Diffserv Service Classes" [5] characterizes as being included in the Network Control Service Class. The DSCPs of the original service class remain an important consideration and should be preserved during aggregation. Traffic in the Network Control treatment aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [4] section 4.2.2.2. This treatment aggregate should have a lower probability of packet loss, bearing a relatively deep target mean queue depth (min- Chan, et al. Expires April 23, 2007 [Page 8] Internet-Draft Document October 2006 threshold if RED is being used). 4.1.2. Real Time Treatment Aggregate The Real Time Treatment Aggregate aggregates all real-time (inelastic) service classes. The theory is that real-time traffic is admitted under some model and controlled by a SLA managed at the edge of the network prior to aggregation. As such, there is a predictable and enforceable upper bound on the traffic that can enter such a queue, and to provide predictable variation in delay it must be protected from bursts of elastic traffic. The predictability of traffic level may be based upon admission control for a well known community of interest (e.g., a point-point service) and/or based upon historical measurements. This treatment aggregate may include the following service classes from the Diffserv Service Classes [5], in addition to other locally defined classes: Telephony, Signaling, Multimedia Conferencing, Real- time Interactive, Broadcast Video. Traffic in each service class that is going to be aggregated into the treatment aggregate should be conditioned prior to aggregation. It is recommended that per service class admission control procedures be used followed by per service class policing so that any individual service class does not generate more than what it is allowed. Furthermore, additional admission control and policing may be used on the sum of all service classes aggregated. The DSCPs of the original service classes remain an important consideration and should be preserved during aggregation. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 3246 [11] and RFC 3247 [12]. 4.1.3. Assured Elastic Treatment Aggregate The Assured Elastic Treatment Aggregate aggregates all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [10]. The premise of such a service is that a SLA is negotiated which includes a "committed rate" and the ability to exceed that rate (and perhaps a second "excess rate") in exchange for a higher probability of loss using AQM [9] or ECN flagging [13] for the portion of traffic deemed to be in excess. This treatment aggregate may include the following service classes from the Diffserv Service Classes [5], in addition to other locally defined classes: Multimedia Streaming, Low Latency Data, OAM, High Throughput Data. Chan, et al. Expires April 23, 2007 [Page 9] Internet-Draft Document October 2006 The DSCP values belonging to the AF PHB group of the original service classes remain an important consideration and should be preserved during aggregation. This treatment aggregate should maintain the AF PHB group marking of the original packet. For example, AF3x marked packets should remain AF3x marked within this treatment aggregate. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2597 [10]. In effect, appropriate target rate thresholds have been applied at the edge, dividing traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 (excess). The service should be engineered so that AFn1 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the traffic is elastic and responds dynamically to packet loss, Active Queue Management [9] should be used primarily to reduce the forwarding rate to the minimum assured rate at congestion points. The probability of loss of AFn1 traffic must not exceed the probability of loss of AFn2 traffic, which in turn must not exceed the probability of loss of AFn3 traffic. If RED [9] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each of AFn1, AFn2, AFn3, and the max- threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, the following inequalities should hold in queue configurations: o min-threshold AFn3 < max-threshold AFn3 o max-threshold AFn3 <= min-threshold AFn2 o min-threshold AFn2 < max-threshold AFn2 o max-threshold AFn2 <= min-threshold AFn1 o min-threshold AFn1 < max-threshold AFn1 o max-threshold AFn1 <= memory assigned to the queue Note: This configuration tends to drop AFn3 traffic before AFn2 and AFn2 before AFn1. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. [BD] This particular set of configuration rules seems reasonable but many other reasonable possibilities also exist. The existence of other valid options should be made clear. 4.1.4. Elastic Treatment Aggregate The Elastic Treatment Aggregate aggregates all remaining elastic traffic. The premise of such a service is that there is no intrinsic SLA differentiation of traffic, but that AQM [9] or ECN flagging [13] is appropriate for such traffic. This treatment aggregate may include the following service classes Chan, et al. Expires April 23, 2007 [Page 10] Internet-Draft Document October 2006 from the Diffserv Service Classes [5], in addition to other locally defined classes: Standard, Low Priority Data. The DSCPs of the original service classes remain an important consideration and should be preserved during aggregation. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be separately set, so that Low Priority Data traffic is dropped before Standard traffic, but this is not a requirement. 5. Using MPLS for Treatment Aggregates RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of DiffServ [8] provide a very good background on this topic. This document provides an example of using the E-LSP, EXP Inferred PHB Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS Support of DiffServ [8] for realizing the Treatment Aggregates. When Treatment Aggregates are represented in MPLS using EXP Inferred PSC LSP, we recommend the following usage of the MPLS EXP field for Treatment Aggregates. [BD] I'm not sure the TSVWG wants to publish a document that "recommends" a particular mapping of PHBs to MPLS EXP values. It seems to be that, like many other parts of this document, it would be better to say "here is one way of doing things; many other valid approaches exist" Chan, et al. Expires April 23, 2007 [Page 11] Internet-Draft Document October 2006 ------------------------------------------- |Treatment || MPLS || DSCP | DSCP | |Aggregate || EXP || name | value | |==========++======++=========|=============| | Network || 110 || CS6 | 110000 | | Control || || | | |==========++======++=========|=============| | Real || 100 || EF | 101110 | | Time || ||---------|-------------| | || || CS5 | 101000 | | || ||---------|-------------| | || ||AF41,AF42|100010,100100| | || || AF43 | 100110 | | || ||---------|-------------| | || || CS4 | 100000 | | || ||---------|-------------| | || || CS3 | 011000 | |==========++======++=========|=============| | Assured || 010* || CS2 | 010000 | | Elastic || || AF31 | 011010 | | || || AF21 | 010010 | | || || AF11 | 001010 | | ||------||---------|-------------| | || 011* || AF32 | 011100 | | || || AF22 | 010100 | | || || AF12 | 001100 | | || || AF33 | 011110 | | || || AF23 | 010110 | | || || AF13 | 001110 | |==========++======++=========|=============| | Elastic || 000* || Default | 000000 | | || || (CS0) | | | ||------||---------|-------------| | || 001* || CS1 | 001000 | ------------------------------------------- Figure 3: Treatment Aggregate and MPLS EXP Field Usage Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the usage of 010 or 011 (000 or 001) as EXP field value depends on the drop probability. Packets in the LSP with EXP field of 011 (001) have a higher probability of being dropped than packets with an EXP field of 010 (000). The above table indicates the recommended usage of EXP fields for Treatment Aggregates. Because many deployments of MPLS are on a per domain basis, each domain has total control of its EXP usage and each domain may use a different EXP field allocation for the domain's Chan, et al. Expires April 23, 2007 [Page 12] Internet-Draft Document October 2006 supported Treatment Aggregates. 5.1. Network Control Treatment Aggregate with E-LSP The usage of E-LSP for Network Control Treatment Aggregate needs to adhere to the recommendations indicated in section 4.1.1 of this document and section 3.2 of "Diffserv Service Classes" [5]. Reinforcing these recommendations, there should be no drop precedence associated with the MPLS PSC used for Network Control Treatment Aggregate because dropping of Network Control Treatment Aggregate traffic should be prevented. 5.2. Real Time Treatment Aggregate with E-LSP In addition to the recommendations provided in section 4.1.2 of this document and in member service classes' sections of "Diffserv Service Classes" [5], we want to indicate that Real Time Treatment Aggregate traffic should not be dropped, as some of the applications whose traffic is carried in the Real Time Treatment Aggregate do not react well to dropped packets. As indicated in section 4.1.2 of this document, admission control should be performed on each Service Class contributing to the Real Time Treatment Aggregate to prevent packet loss due to insufficient resources allocated to Real Time Treatment Aggregate. Further, admission control and policing may also be applied on the sum of all traffic aggregated into this treatment aggregate. 5.3. Assured Elastic Treatment Aggregate with E-LSP EXP field markings of 010 and 011 are used for the Assured Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 010 encoded traffic having a lower probability of being dropped than 011 encoded traffic. This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. 5.4. Elastic Treatment Aggregate with E-LSP EXP field markings of 000 and 001 are used for the Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 000 encoded traffic having a lower probability of being dropped than 001 encoded traffic. This provides for the mapping of Default/CS0 into 000; and CS1 into 001. Notice that with this mapping, during congestion, CS1 marked traffic may be starved. Chan, et al. Expires April 23, 2007 [Page 13] Internet-Draft Document October 2006 5.5. Treatment Aggregates and L-LSP Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per LSP, the support of each Treatment Aggregate is on a per LSP basis. This document does not further specify any additional recommendation (beyond what has been indicated in section 4 of this document) for Treatment Aggregate to L-LSP mapping, leaving this to each individual MPLS domain administrations. 6. Treatment Aggregates and Inter-Provider Relationships When Treatment Aggregates are used at provider boundaries, we recommend that the Inter-Provider Relationship be based on Diffserv Service Classes [5]. This allows the admission control into each Treatment Aggregate of a provider domain to be based on the admission control of traffic into the supported Service Classes, as indicated by the discussion in section 4 of this document. If the Inter-Provider Relationship needs to be based on Treatment Aggregates specified by this document, then the exact Treatment Aggregate content and representation must be agreed to by the peering providers. 7. Security Considerations This document discusses the policy of using Differentiated Services and its service classes. If implemented as described, it should require that the network do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy. It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined aggregation. In that case, a policy issue exists that the network must detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior. A well known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the best of the authors' knowledge, there is no known technical way to respond to or act upon a data stream that has been admitted for service but that it is not intended for Chan, et al. Expires April 23, 2007 [Page 14] Internet-Draft Document October 2006 authenticated use. 8. IANA Considerations This document does not request any IANA considerations. 9. Acknowledgements This document has benefited from discussions with numerous people, especially Shane Amante, Brian Carpenter, and Dave McDysan. It has also benefited from detailed reviews by David Black and Marvin Krym. 10. References 10.1. Normative References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [5] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, Chan, et al. Expires April 23, 2007 [Page 15] Internet-Draft Document October 2006 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. 10.2. Informative References [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay in an Operational Network", INFOCOMM 2004, March 2004, . [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, . Authors' Addresses Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-8175 Fax: +1-978-288-8700 Email: khchan@nortel.com Chan, et al. Expires April 23, 2007 [Page 16] Internet-Draft Document October 2006 Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Fax: +1-613-768-2231 Email: babiarz@nortel.com Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Chan, et al. Expires April 23, 2007 [Page 17] Internet-Draft Document October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chan, et al. Expires April 23, 2007 [Page 18] From tsvwg-bounces@ietf.org Thu Jan 11 17:36:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58X1-0005VT-Gu; Thu, 11 Jan 2007 17:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Wz-0005VO-P2 for tsvwg@ietf.org; Thu, 11 Jan 2007 17:36:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58Wz-0001pB-1U for tsvwg@ietf.org; Thu, 11 Jan 2007 17:36:21 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Jan 2007 14:36:20 -0800 X-IronPort-AV: i="4.13,175,1167638400"; d="scan'208"; a="100685611:sNHT77976864" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0BMaKQq021158 for ; Thu, 11 Jan 2007 14:36:20 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0BMaKUw006926 for ; Thu, 11 Jan 2007 14:36:20 -0800 (PST) Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:36:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Tsvwg] Need for volunteers forreviewing draft-ietf-tsvwg-diffserv-class-aggr Date: Thu, 11 Jan 2007 14:36:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Need for volunteers forreviewing draft-ietf-tsvwg-diffserv-class-aggr Thread-Index: AccaqJWR5xSLTPUZR8esqW90l6CQLwOk7G0gAyUdQJA= From: "Julie Ann Connary \(jconnary\)" To: "tsvwg" X-OriginalArrivalTime: 11 Jan 2007 22:36:20.0080 (UTC) FILETIME=[EA203F00:01C735D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10245; t=1168554980; x=1169418980; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jconnary@cisco.com; z=From:=20=22Julie=20Ann=20Connary=20\(jconnary\)=22=20 |Subject:=20FW=3A=20[Tsvwg]=20Need=20for=20volunteers=20forreviewing=09dr aft-ietf-tsvwg-diffserv-class-aggr |Sender:=20; bh=9zZVdyBjloSrlJh6Pzr8rwZCkN4D/XMtatCBzLOyMsE=; b=JQ4BvLK/hK+K9F5fYLfHLIF/45QbqmXTKccjeohY4ttu3A+x9xWjfvMKIPS8d92lwHOWV4R/ ggqEzWM23gPvpv1oplGXm4Udwzwf36bkboxGwBNEjC4IhbZEV1risiMH; Authentication-Results: sj-dkim-4; header.From=jconnary@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org RE-forwarding as well as I too did not see my review on the mailing list.=20 -----Original Message----- From: Julie Ann Connary (jconnary)=20 Sent: Wednesday, December 27, 2006 2:43 PM To: 'Magnus Westerlund' Cc: tsvwg Subject: RE: [Tsvwg] Need for volunteers forreviewing draft-ietf-tsvwg-diffserv-class-aggr Review of Draft-ietf-tsvwg-diffserv-class-aggr Overall - I am ok with the concept of this draft and believe it provides a valuable guideline along with RFC 4594. Thus most of my comments are editorial in nature with the exception of Unkown DSCP and discussions surrounding them. I believe that this part should be "beefed" up (section 4.1.4) to help provide clear guidelines to Network QoS Architects and Designers who frequently do not appropriately plan for what to do with traffic that is not marked with a DSCP that is to be classified for differential treatment within their DS domain and incorrectly assume that magically all traffic is marked/re-marked to DSCP 0. Thanks, JA ------------------------------------------------------ 1. Introduction, Page 3, 2nd and 4th paragraphs - wording consistency "However, sub-second surges that occur in the best-designed of networks [14] affect real-time applications. Moreover, Dos Loads, worms, and network disruptions such as that of 11 September 2001 affect routing [15]. Our objective is to prevent disruption to routing (which in turn affects all services), and jitter-sensitive services that may be revenue-bearing"=20 "The treatment aggregate recommendations are designed to aggregate the service classes [5] in such a manner as to protect real-time traffic and routing, on the assumption that real-time sessions are protected from each other by admission at the edge." I would suggest to be consistent in the wording and utilize "real-time" in both cases. Second would recommend to drop the "that may be revenue-bearing" in the first citation. Services in the elastic class like multi-media streaming may also be revenue-bearing. The protection is for the traffic characteristics with the main differentiator between the real-time and the assured elastic is that the first is jitter sensitive. Both have loss/delay requirements greater than BE/Standard and hence require special treatment throughout the network to prevent service disruption or service quality degredation during congestion events (whether they be at the access or momementary surges in the core as described here.) Might consider rewording the first to something like: "However, sub-second surges that occur in the best-designed of networks [14] affect real-time applications. Moreover, Dos Loads, worms, and network disruptions such as that of 11 September 2001 affect routing [15]. Our objective is to prevent disruption to routing (which in turn affects all services), protect real-time jitter sensitive traffic while minimizing loss and delay of sensitive elastic traffic"=20 2. Terminology - Page 4 - is a reference needed here to RFC 2475: "This document assumes the reader is familiar with the terms used in differentiated services." 3. Terminology - Page 4 - Remove word "none" from second sentence, first paragraph "This document provides the definitions for new terms introduced by this document and referencing information for existing none differentiated services terms defined in existing RFCs." 4. Terminology - Page 4 - Definition of Treatment Aggregate This definition is slightly confusing (as the Draft does suggest recommened standard DSCP's for the Aggregated DiffServ Classes) and suggest re-wording as well as well as references to RFC 2474 and RFC 3086 for the terms specified. "Treatment Aggregate. This term is used here to indicate the aggregate of DiffServ Service Classes. This is different from Behavior Aggregate and Traffic Aggregate because Treatement Aggregate is only concerned with the treatment of the aggregated traffic. It does not concern itself with how the aggregate traffic is marked, and hence does not put a restriction on the aggregated traffic having a signle diffserv codepoint that have a single PHB." To something like: "Treatment Aggregate: is defined as the aggregate of two or more DiffServ Service Classes[5]. A Treatment Aggregate is concerned only with the forwarding treatment of the aggregated traffic which may be marked with multiple DSCPs. A Treatment Aggregate differs from a Behavior Aggregate [4] and Traffic Aggregate [RFC 3086], each of which indicate the aggregation of traffic having the same DSCP and a utilizing a single PHB." 5. Terminology - DiffServ Service Class - update reference to be RFC 4594 vs. the draft cited. 7. Section 3 (number 5) and Section 4.1.2 - Real Time treatment Aggregate - reconcile use of words MUST and SHOULD. Section 3, number 5 -- says "must" while section 4.1.2 says "should": "5. Each treatment aggregate has limited resources, hence traffic conditioning and/or admission control MUST be performed for each service class aggregated into the treatment aggregate." "Traffic in each service class that is going to be aggregated into the treatment aggregate SHOULD be conditioned prior to aggregation...." Section 4.1.2 includes admission control and policing of the Treatment Aggregate as well: "Furthermore, additional admission control and policing may be used on the sum of all service classes aggregated." Suggest re-wording this to the same as in section 5.2: "Furthermore, additional admission control and policing may be used on the sum of all traffic aggregated into this Treatment Aggregate." 8. Figure 2, Figure 3 - Default Service Class, Section 4.1.4 Inconsistency in recommendation for DSCP mapped into the Default Service Class throughout Document. Text and Tables should be clear about "unkown" DSCP.=20 Figure 2 indicates Default or CS0 and CS1. Figure 3 indicates the same. Section 4.1.4 indicates "All remaining elastic traffic" and indicates it "may include the follwing service classes from the DiffServ Service Classes [5], in addition to other locally defined classes: Standard, Low priority Data." [5] indicates for Standard Service Class - also Default or CS0, but Figure 5 in [5] indicates DF(CS0) + other. Recommend that all tables have either a row for "other" or DF(CS0) + other for consistency with wording of text throughout this RFC and others including [5 - 4594, RFC 2474 etc.)=20 This is something that implementors and network architects struggle with in the Industry and often forget when making a plan - i.e. the plan just includes CS0. While an implementation "could" remark all unkown traffic to DSCP 0 at the edge - it is not required. Many implementations today defaultly classify all unkown traffic into the default queue with no configuration required to achieve this behavior.=20 Recommend adding some verbage to Section 4.1.4 to discuss and indication within the recommended standard DSCP tables to indicate what is to be done with "unkown" DSCP in this model. Especially since throughout the document, it is stressed that the original DSCP marking should be maintained. If a Domain does not provide all service classes - but is inter-connected with a domain that does, it may be necessary to carry that traffic as Elastic throughout the domain, while maintaining the original DSCP. 9. Security Considerations, 3rd paragraph - confusing wording: Paragraph 3 is a very important paragraph/concept that requires one DS domain to trust the other DS domains as well as endpoints etc. to do the right thing, not only in marking packets but adhering to admission control when utilized.=20 It is not quite understood what the author's intent of the last sentence of the 3rd paragraph is: "To the best of the author's knowledge, there is no known technical way to respond to or act upon a data stream that has been admitted for service but that it is not intended for authenticated use." Is the author meaning how to respond to traffic that is inappropriately marked as say real-time traffic, but that did not use admission control? 10. References: Add RFC 3086 due to reference to Traffic Aggregate within definitions. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, December 08, 2006 3:07 AM To: Magnus Westerlund Cc: tsvwg Subject: Re: [Tsvwg] Need for volunteers forreviewing draft-ietf-tsvwg-diffserv-class-aggr Hi And we would appreciate if the reviews where done before Christmas, i.e. within the next 2 weeks. Cheers Magnus Magnus Westerlund skrev: > Hi, >=20 > To make progress we need some reviewers to read and comment on=20 > "Aggregation of DiffServ Service Classes": > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr -01.txt=20 >=20 >=20 > We chairs don't think we can proceed with this draft until we seen some=20 > confirming reviews from the WG participants. So please volunteer. >=20 > If you are willing to do this review please indicate so to us chairs. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Thu Jan 11 18:32:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59OS-0006Oz-Ay; Thu, 11 Jan 2007 18:31:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59OR-0006Ot-1h for tsvwg@ietf.org; Thu, 11 Jan 2007 18:31:35 -0500 Received: from mailipao.ntcif.telstra.com.au ([202.12.233.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H59OM-0003Gp-6d for tsvwg@ietf.org; Thu, 11 Jan 2007 18:31:35 -0500 Received: from webi.ntcif.telstra.com.au (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipao.ntcif.telstra.com.au with ESMTP; 12 Jan 2007 10:31:22 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 5EB87FF87; Fri, 12 Jan 2007 10:31:22 +1100 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 0AC8541E7F; Fri, 12 Jan 2007 10:31:22 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 10:31:21 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: Fri, 12 Jan 2007 10:31:11 +1100 Message-ID: <651B5C0033306A45BC11E409451A60C502D5B4C6@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: <5726EFB0-E059-452E-B87C-3CFBCCC2DE70@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Thread-Index: Acc10LijcQ+UHI9uReWGTMFAwfwhgAABeCZA From: "Dickinson, Fil" To: "Bruce Davie" , "tsvwg" X-OriginalArrivalTime: 11 Jan 2007 23:31:21.0765 (UTC) FILETIME=[9A156550:01C735D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7be242970a3170dc572bd9934ae85b48 Cc: Magnus Westerlund X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Bruce. I may be misinterpeting your last point but I do not agree with it. I think we do need a "recommendation" on an approach to diffserv class aggregation. I agree that it should not be "to the effect that there is only one valid way to run a Diffserv network", but see a need for a defined recommended approach.=20 I think this is necessary so that service providers can refer to a documented approach by a recognised standards body when designing their own networks, agreeing interprovider implementations with peers and dealing with inter-vendor interpretations of diffserv class aggregation. -----Original Message----- From: Bruce Davie [mailto:bdavie@cisco.com]=20 Sent: Friday, 12 January 2007 9:33 AM To: tsvwg Cc: Magnus Westerlund Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr I too send comments that never made it to the archive. Here they are again. Bruce From: bdavie@cisco.com Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: December 21, 2006 11:20:33 AM EST To: magnus.westerlund@ericsson.com Cc: tsvwg@ietf.org As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- aggr-01.txt My line by line comments are below, prefaced by [BD] My top level comments are as follows: 1. The main contribution of this draft can be summarized very briefly: you can aggregate different classes of traffic into bigger classes that get the same treatment as long as that treatment is good enough to meet the needs of the most stringent class. 2. A second contribution is to observe that if you do aggregate, it would be nice to preserve markings such that de-aggregation can be performed later. 3. Beyond that, the document makes a lot of specific recommendations about precisely how you should aggregate in both IP and MPLS networks. My concern with this aspect of the document is that there are essentially an infinite number of valid ways to aggregate traffic. For example, one of the most popular is to give all traffic in the core of an over-provisioned network the same treatment - so- called "best effort" treatment, but actually it is a treatment that is so good that even the most stringent class of traffic gets adequate service. This approach to aggregation goes unmentioned in the document, as does the fact that many other options are valid. At a minimum, this document should be revised to make it clear that it is describing ONE possible approach out of many more that are possible. Since it is being progressed by the TSVWG, statements that begin "we recommend..." should probably be rewritten to be of the form "A possible option is..." A great deal of effort went into writing the DiffServ standards in such a way that operators and vendors would not be overly constrained. A set of recommendations from the TSVWG, even in an informational RFC, to the effect that there is only one valid way to run a Diffserv network, does not seem like something we want to produce. Bruce -------- TSVWG K. Chan Internet-Draft J. Babiarz Intended status: Informational Nortel Networks Expires: April 23, 2007 F. Baker Cisco Systems October 20, 2006 Aggregation of DiffServ Service Classes draft-ietf-tsvwg-diffserv-class-aggr-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In the core of a high capacity network, service differentiation is still needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into diffserv service classes based on end- to-end behavior requirements of the applications as indicated by Diffserv Service Classes [5]. However, some network segments may be Chan, et al. Expires April 23, 2007 [Page 1] Internet-Draft Document October 2006 configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv Service Classes [5] into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv Service Classes [5] into forwarding treatments. Table of Contents 1. =20 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. =20 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Service Class Aggregation . . . . . . . . . . . . 5 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . 6 4.1. Mapping Service Classes into Four Treatment Aggregates . . 6 4.1.1. Network Control Treatment Aggregate . . . . . . . . . 8 4.1.2. Real Time Treatment Aggregate . . . . . . . . . . . . 9 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . 9 4.1.4. Elastic Treatment Aggregate . . . . . . . . . . . . . 10 5. Using MPLS for Treatment Aggregates . . . . . . . . . . . . . 11 5.1. Network Control Treatment Aggregate with E- LSP . . . . . . 13 5.2. Real Time Treatment Aggregate with E- LSP . . . . . . . . . 13 5.3. Assured Elastic Treatment Aggregate with E- LSP . . . . . . 13 5.4. Elastic Treatment Aggregate with E- LSP . . . . . . . . . . 13 5.5. Treatment Aggregates and L- LSP . . . . . . . . . . . . . . 14 6. Treatment Aggregates and Inter-Provider Relationships . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. =20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. =20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' =20 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Chan, et al. Expires April 23, 2007 [Page 2] Internet-Draft Document October 2006 1. Introduction In the core of a high capacity network, it is common for the network to be engineered in such a way that a major link, switch, or router can fail and the result will be a routed network that still meets ambient SLAs. The implication of this is that there is sufficient capacity on any given link such that all SLAs sold can be simultaneously supported at their respective maximum rates, and that this remains true after re-routing (either IP re-routing or MPLS protection-mode switching) has occurred. Over-provisioning is generally considered to meet the requirements of all traffic without further QoS treatment, and in the general case that is true in high capacity backbones. However, as the process of network convergence continues, and with the increasing speed of the access networks, certain services still have issues. Delay, jitter, and occasional loss are perfectly acceptable for elastic applications. However, sub-second surges that occur in the best- designed of networks [14] affect real-time applications. Moreover, DOS loads, worms, and network disruptions such as that of 11 September 2001 affect routing [15]. Our objective is to prevent disruption to routing (which in turn affects all services), and jitter-sensitive services that may be revenue-bearing. [BD] It took me a long time to understand the above sentence. It could be read to mean that an objective of the draft is to prevent jitter sensitive services, which is probably not the intent. =20 Also, I think the comment about preventing disruption to routing relates to the desire to protect network control traffic from loss, so perhaps you should say that (since there are lots of ways that routing may get disrupted that are outside the scope of this draft). The document "Diffserv Service Classes" [5] defines the basic diffserv classes from the points of view of the application requiring specific end-to-end behaviors from the network. The service classes are differentiated based on the traffic-payload's tolerance to packet loss, delay, and delay variation (jitter). Different degrees of these criterions form the foundation for supporting the needs of [BD] criterions -> criteria, or even better "Different values of these metrics form..." real-time and elastic traffic. The "Diffserv Service Classes" [5] document also provides recommendations for the treatment method of these service classes. But, at some network segments of the end-to- end path, the number of levels of network treatment differentiation may be less than the number of service classes that the network segment needs to support. In such a situation, that network segment may use the same treatment to support more than one service class. In this document we provide guidelines on how multiple service classes may be aggregated into a forwarding treatment aggregate. Note that in a given domain, we may recommend that the supported service classes be aggregated into forwarding treatment aggregates; however, this does not mean all service classes need to be supported and hence not all forwarding treatment aggregates need to be supported. Which service classes and which forwarding treatment aggregates are supported by a domain is up to the domain administration and may be influenced by business reasons. In this document, we've provided: Chan, et al. Expires April 23, 2007 [Page 3] Internet-Draft Document October 2006 o definitions for terminology we use in this document, o requirements for performing this aggregation, o an example of performing this aggregation over MPLS using E-LSP. The treatment aggregate recommendations are designed to aggregate the service classes [5] in such a manner as to protect real-time traffic and routing, on the assumption that real-time sessions are protected from each other by admission at the edge. An example of aggregation over MPLS networks using E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to realize the treatment aggregates is provided. Note that the MPLS E-LSP is just an example; this document does not exclude the use of other methods. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. Terminology This document assumes the reader is familiar with the terms used in differentiated services. This document provides the definitions for new terms introduced by this document and referencing information for existing none differentiated services terms defined in existing RFCs. For new terms introduced by this document, we provide the definition here: o Treatment Aggregate. This term is used here to indicate the aggregate of DiffServ service classes. This is different from Behavior Aggregate and Traffic Aggregate because Treatment Aggregate is only concerned with the treatment of the aggregated traffic. It does not concern itself with how the aggregated traffic is marked, and hence does not put a restriction on the aggregated traffic having a single diffserv codepoint that have a single PHB. For terms from existing RFCs, we provide the reference to the appropriate section of the relevant RFC that contain the definition: o Real-Time and Elastic Applications and their traffic. Section 3.1 of RFC 1633 [6]. Chan, et al. Expires April 23, 2007 [Page 4] Internet-Draft Document October 2006 o Diffserv Service Class. Section 1.3 of draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.2 of RFC 3270 [8]. o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP). Section 1.3 of RFC 3270 [8]. 3. Overview of Service Class Aggregation In diffserv domains where less granular traffic treatment differentiation is provided, aggregation of the different service classes [5] may be required. These aggregations have the following requirements: [BD] I don't understand where these requirements come from. 1. The end-to-end network performance characteristic required by the application must be supported. This performance characteristic is represented by the use of Diffserv Service Classes [5]. 2. The treatment aggregate must exhibit the strictest requirement of its member service classes. 3. The treatment aggregate should only contain member service classes with similar traffic characteristic and performance requirements. [BD] Why? Isn't it OK to aggregate wildly different service classes and give them all treatment that is a good as the most stringent requirements of any class? 4. The notion of the individual end-to-end service classes must not be destroyed when aggregation is performed. Each domain along the end-to-end path may perform aggregation differently, based on the original end-to-end service classes. We recommend an easy way to accomplish this by not altering the DSCP used to indicate the end-to-end service class. But some administrative domains may require the use of their own marking; when this is needed, the original end-to-end service class indication must be restored upon exiting such administrative domains. [BD] You seem to have strayed away from stating requirements when you start recommending how to mark the DSCP. I *think* that what you are trying to say is that the information about which service class belongs to should not be lost during aggregation; such information loss would occur, for example, if several different classes were remarked to a common DSCP value. 5. Each treatment aggregate has limited resources, hence traffic conditioning and/or admission control must be performed for each service class aggregated into the treatment aggregate. [BD] Where is this requirement from? Are you saying that it's not possible to aggregate traffic with also performing admission control or traffic conditioning? Many SPs would disagree. with the following suggestions: 1. The treatment aggregate and assigned resources may consider historical traffic patterns and the variability of these patterns. For example, a point-point service (e.g., pseudowire) Chan, et al. Expires April 23, 2007 [Page 5] Internet-Draft Document October 2006 may have a very predictable pattern, while a multipoint service (e.g., VPLS) may have a much less predictable pattern. Even the traffic patterns within the Internet may vary widely. 2. In addition to Diffserv, other controls are available to influence the traffic level offered to a particular traffic aggregate. These include adjustment of routing metrics, usage of MPLS-based traffic engineering techniques. 4. Service Classes to Treatment Aggregate Mapping The service class and DSCP selection in "Diffserv Service Classes" [5] has been defined to allow, in many instances, mapping of two or possibly more service classes into a single forwarding treatment aggregate. Notice that there is a relationship/trade-off between link speed, queue depth, delay, and jitter. [BD] The preceding sentence should also mention link utilization. The degree of aggregation and hence the number of treatment aggregates will depend on whether the speed of the links and scheduler behavior, being used to implement the aggregation, can minimize the affects of mixing traffic with different packet sizes and transmit rates on queue depth. And their impacts on loss, delay, and jitter. A general rule-of-thumb is that higher link speeds allow for more aggregation/ smaller number of treatment aggregates. [BD] That rule of thumb seems to be incorrect if a link is run at 100% utilization. A more useful rule of thumb might take utilization into accoutn. 4.1. Mapping Service Classes into Four Treatment Aggregates [BD] It is probably worth mentioning that this is just an example and that more or fewer treatment aggregates may be required. This section explains one way of performing this aggregation by using four treatment aggregates. The use of four treatment aggregates assumes that the resources allocated to each treatment aggregate is sufficient to honor the required behavior of each service class [5] in each of the four treatment aggregates. We use the performance requirement (tolerance to loss, delay, and jitter) from the application/end-user as a guide on how to map the service classes into treatment aggregates. We have also used Section 3.1 of RFC 1633 [6] to provide us with guidance on the definition of Real-Time and Elastic applications. An overview of the mapping between service classes and the four treatment aggregates is provided by Figure 1, with the mapping being based on performance requirements. In Figure 1, the right side columns of "Service Class", "Tolerance to Loss/ Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. It is recommended that certain service classes be mapped into specific treatment aggregates. But this does not mean that all the service classes recommended for that treatment aggregate need to be supported. Hence, for a given domain, a treatment aggregate may contain only a subset of the service classes recommended in this document, they being the service classes supported by that domain. A Chan, et al. Expires April 23, 2007 [Page 6] Internet-Draft Document October 2006 domain's treatment of non-supported service classes should be based on the domain's local policy. This local policy may be influenced by its agreement with its customers. Such treatment may use the Elastic Treatment Aggregate, dropping the packets, or some other arrangements. --------------------------------------------------------------------- |Treatment | Tolerance to ||Service Class | Tolerance to | |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |Jitter| |=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| | Network | Low | Low | Yes || Network | Low | Low | Yes | | Control | | | || Control | | | | |=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| | Real | Very | Very | Very || Telephony | VLow | VLow | VLow | | Time | Low | Low | Low ||---------------+------+------+------| | | | | || Signaling | Low | Low | Yes | | | | | ||---------------+------+------+------| | | | | || Multimedia |Low - | Very | Low | | | | | || Conferencing |Medium| Low | | | | | | ||---------------+------+------+------| | | | | || Real-time | Low | Very | Low | | | | | || Interactive | | Low | | | | | | ||---------------+------+------+------| | | | | || Broadcast | Very |Medium| Low | | | | | || Video | Low | | | |=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| | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| Yes | | Elastic | |Medium| || Streaming |Medium| | | | | | | ||---------------+------+------+------| | | | | || Low Latency | Low |Low - | Yes | | | | | || Data | |Medium| | | | | | ||---------------+------+------+------| | | | | || OAM | Low |Medium| Yes | | | | | ||---------------+------+------+------| | | | | ||High Throughput| Low |Medium| Yes | | | | | || Data | |- High| | |=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| | Elastic | Not Specified || Standard | Not Specified | | | | | ||---------------+------+------+------| | | | | || Low Priority | High | High | Yes | | | | | || Data | | | | --------------------------------------------------------------------- Figure 1: Treatment Aggregate and Service Class Performance Requirements As we are recommending to preserve the notion of the individual end- to-end service classes, we also recommend that the original DSCP Chan, et al. Expires April 23, 2007 [Page 7] Internet-Draft Document October 2006 field marking not be changed when treatment aggregates are used. Instead, classifiers that select packets based on the contents of the DSCP field should be used to direct packets from the member DiffServ Service Classes into the queue that handles each of the treatment aggregates, without remarking the DSCP field of the packets. =20 This is summarized in Figure 2, which shows the behavior each Treatment Aggregate should have, and the DSCP field marking of the packets that should be classified into each of the treatment aggregates. ------------------------------------------------------------ |Treatment |Treatment || DSCP | |Aggregate |Aggregate || | | |Behavior || | = |=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| | Network | CS || CS6 | | Control |(RFC 2474)|| | = |=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| | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | | Time |(RFC 3246)|| | = |=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| | Assured | AF || CS2, AF31, AF21, AF11 | | Elastic |(RFC 2597)||-------------------------------------| | | || AF32, AF22, AF12 | | | ||-------------------------------------| | | || AF33, AF23, AF13 | = |=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| | Elastic | Default || Default, (CS0) | | |(RFC 2474)||-------------------------------------| | | || CS1 | ------------------------------------------------------------ Figure 2: Treatment Aggregate Behavior 4.1.1. Network Control Treatment Aggregate The Network Control Treatment Aggregate aggregates all service classes that are functionally necessary for the survival of a network during a DOS attack or other high traffic load interval. The theory is that whatever else is true, the network must protect itself. =20 This includes the traffic that "Diffserv Service Classes" [5] characterizes as being included in the Network Control Service Class. The DSCPs of the original service class remain an important consideration and should be preserved during aggregation. =20 Traffic in the Network Control treatment aggregate should be carried in a common queue or class with a PHB as described in RFC 2474 [4] section 4.2.2.2. This treatment aggregate should have a lower probability of packet loss, bearing a relatively deep target mean queue depth (min- Chan, et al. Expires April 23, 2007 [Page 8] Internet-Draft Document October 2006 threshold if RED is being used). 4.1.2. Real Time Treatment Aggregate The Real Time Treatment Aggregate aggregates all real-time (inelastic) service classes. The theory is that real-time traffic is admitted under some model and controlled by a SLA managed at the edge of the network prior to aggregation. As such, there is a predictable and enforceable upper bound on the traffic that can enter such a queue, and to provide predictable variation in delay it must be protected from bursts of elastic traffic. The predictability of traffic level may be based upon admission control for a well known community of interest (e.g., a point-point service) and/or based upon historical measurements. This treatment aggregate may include the following service classes from the Diffserv Service Classes [5], in addition to other locally defined classes: Telephony, Signaling, Multimedia Conferencing, Real- time Interactive, Broadcast Video. Traffic in each service class that is going to be aggregated into the treatment aggregate should be conditioned prior to aggregation. It is recommended that per service class admission control procedures be used followed by per service class policing so that any individual service class does not generate more than what it is allowed. Furthermore, additional admission control and policing may be used on the sum of all service classes aggregated. The DSCPs of the original service classes remain an important consideration and should be preserved during aggregation. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 3246 [11] and RFC 3247 [12]. 4.1.3. Assured Elastic Treatment Aggregate The Assured Elastic Treatment Aggregate aggregates all elastic traffic that uses the Assured Forwarding model as described in RFC 2597 [10]. The premise of such a service is that a SLA is negotiated which includes a "committed rate" and the ability to exceed that rate (and perhaps a second "excess rate") in exchange for a higher probability of loss using AQM [9] or ECN flagging [13] for the portion of traffic deemed to be in excess. This treatment aggregate may include the following service classes from the Diffserv Service Classes [5], in addition to other locally defined classes: Multimedia Streaming, Low Latency Data, OAM, High Throughput Data. Chan, et al. Expires April 23, 2007 [Page 9] Internet-Draft Document October 2006 The DSCP values belonging to the AF PHB group of the original service classes remain an important consideration and should be preserved during aggregation. This treatment aggregate should maintain the AF PHB group marking of the original packet. For example, AF3x marked packets should remain AF3x marked within this treatment aggregate. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2597 [10]. In effect, appropriate target rate thresholds have been applied at the edge, dividing traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 (excess). The service should be engineered so that AFn1 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Since the traffic is elastic and responds dynamically to packet loss, Active Queue Management [9] should be used primarily to reduce the forwarding rate to the minimum assured rate at congestion points. The probability of loss of AFn1 traffic must not exceed the probability of loss of AFn2 traffic, which in turn must not exceed the probability of loss of AFn3 traffic. If RED [9] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each of AFn1, AFn2, AFn3, and the max- threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this Treatment Aggregate, the following inequalities should hold in queue configurations: o min-threshold AFn3 < max-threshold AFn3 o max-threshold AFn3 <=3D min-threshold AFn2 o min-threshold AFn2 < max-threshold AFn2 o max-threshold AFn2 <=3D min-threshold AFn1 o min-threshold AFn1 < max-threshold AFn1 o max-threshold AFn1 <=3D memory assigned to the queue Note: This configuration tends to drop AFn3 traffic before AFn2 and AFn2 before AFn1. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. [BD] This particular set of configuration rules seems reasonable but many other reasonable possibilities also exist. The existence of other valid options should be made clear. 4.1.4. Elastic Treatment Aggregate The Elastic Treatment Aggregate aggregates all remaining elastic traffic. The premise of such a service is that there is no intrinsic SLA differentiation of traffic, but that AQM [9] or ECN flagging [13] is appropriate for such traffic. This treatment aggregate may include the following service classes Chan, et al. Expires April 23, 2007 [Page 10] Internet-Draft Document October 2006 from the Diffserv Service Classes [5], in addition to other locally defined classes: Standard, Low Priority Data. The DSCPs of the original service classes remain an important consideration and should be preserved during aggregation. Traffic bearing these DSCPs is carried in a common queue or class with a PHB as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM thresholds for Elastic traffic MAY be separately set, so that Low Priority Data traffic is dropped before Standard traffic, but this is not a requirement. 5. Using MPLS for Treatment Aggregates RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS Support of DiffServ [8] provide a very good background on this topic. This document provides an example of using the E-LSP, EXP Inferred PHB Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS Support of DiffServ [8] for realizing the Treatment Aggregates. When Treatment Aggregates are represented in MPLS using EXP Inferred PSC LSP, we recommend the following usage of the MPLS EXP field for Treatment Aggregates. [BD] I'm not sure the TSVWG wants to publish a document that "recommends" a particular mapping of PHBs to MPLS EXP values. It seems to be that, like many other parts of this document, it would be better to say "here is one way of doing things; many other valid approaches exist" Chan, et al. Expires April 23, 2007 [Page 11] Internet-Draft Document October 2006 ------------------------------------------- |Treatment || MPLS || DSCP | DSCP | |Aggregate || EXP || name | value | = |=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| | Network || 110 || CS6 | 110000 | | Control || || | | = |=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| | Real || 100 || EF | 101110 | | Time || ||---------|-------------| | || || CS5 | 101000 | | || ||---------|-------------| | || ||AF41,AF42|100010,100100| | || || AF43 | 100110 | | || ||---------|-------------| | || || CS4 | 100000 | | || ||---------|-------------| | || || CS3 | 011000 | = |=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| | Assured || 010* || CS2 | 010000 | | Elastic || || AF31 | 011010 | | || || AF21 | 010010 | | || || AF11 | 001010 | | ||------||---------|-------------| | || 011* || AF32 | 011100 | | || || AF22 | 010100 | | || || AF12 | 001100 | | || || AF33 | 011110 | | || || AF23 | 010110 | | || || AF13 | 001110 | = |=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| | Elastic || 000* || Default | 000000 | | || || (CS0) | | | ||------||---------|-------------| | || 001* || CS1 | 001000 | ------------------------------------------- Figure 3: Treatment Aggregate and MPLS EXP Field Usage Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, the usage of 010 or 011 (000 or 001) as EXP field value depends on the drop probability. Packets in the LSP with EXP field of 011 (001) have a higher probability of being dropped than packets with an EXP field of 010 (000). The above table indicates the recommended usage of EXP fields for Treatment Aggregates. Because many deployments of MPLS are on a per domain basis, each domain has total control of its EXP usage and each domain may use a different EXP field allocation for the domain's Chan, et al. Expires April 23, 2007 [Page 12] Internet-Draft Document October 2006 supported Treatment Aggregates. 5.1. Network Control Treatment Aggregate with E-LSP The usage of E-LSP for Network Control Treatment Aggregate needs to adhere to the recommendations indicated in section 4.1.1 of this document and section 3.2 of "Diffserv Service Classes" [5]. Reinforcing these recommendations, there should be no drop precedence associated with the MPLS PSC used for Network Control Treatment Aggregate because dropping of Network Control Treatment Aggregate traffic should be prevented. 5.2. Real Time Treatment Aggregate with E-LSP In addition to the recommendations provided in section 4.1.2 of this document and in member service classes' sections of "Diffserv Service Classes" [5], we want to indicate that Real Time Treatment Aggregate traffic should not be dropped, as some of the applications whose traffic is carried in the Real Time Treatment Aggregate do not react well to dropped packets. As indicated in section 4.1.2 of this document, admission control should be performed on each Service Class contributing to the Real Time Treatment Aggregate to prevent packet loss due to insufficient resources allocated to Real Time Treatment Aggregate. Further, admission control and policing may also be applied on the sum of all traffic aggregated into this treatment aggregate. 5.3. Assured Elastic Treatment Aggregate with E-LSP EXP field markings of 010 and 011 are used for the Assured Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 010 encoded traffic having a lower probability of being dropped than 011 encoded traffic. This provides for the mapping of CS2, AF31, AF21, and AF11 into EXP 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. 5.4. Elastic Treatment Aggregate with E-LSP EXP field markings of 000 and 001 are used for the Elastic Treatment Aggregate. The two encodings are used to provide two levels of drop precedence indications, with 000 encoded traffic having a lower probability of being dropped than 001 encoded traffic. This provides for the mapping of Default/CS0 into 000; and CS1 into 001. Notice that with this mapping, during congestion, CS1 marked traffic may be starved. Chan, et al. Expires April 23, 2007 [Page 13] Internet-Draft Document October 2006 5.5. Treatment Aggregates and L-LSP Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC per LSP, the support of each Treatment Aggregate is on a per LSP basis. This document does not further specify any additional recommendation (beyond what has been indicated in section 4 of this document) for Treatment Aggregate to L-LSP mapping, leaving this to each individual MPLS domain administrations. 6. Treatment Aggregates and Inter-Provider Relationships When Treatment Aggregates are used at provider boundaries, we recommend that the Inter-Provider Relationship be based on Diffserv Service Classes [5]. This allows the admission control into each Treatment Aggregate of a provider domain to be based on the admission control of traffic into the supported Service Classes, as indicated by the discussion in section 4 of this document. If the Inter-Provider Relationship needs to be based on Treatment Aggregates specified by this document, then the exact Treatment Aggregate content and representation must be agreed to by the peering providers. 7. Security Considerations This document discusses the policy of using Differentiated Services and its service classes. If implemented as described, it should require that the network do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy. It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined aggregation. In that case, a policy issue exists that the network must detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior. A well known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the best of the authors' knowledge, there is no known technical way to respond to or act upon a data stream that has been admitted for service but that it is not intended for Chan, et al. Expires April 23, 2007 [Page 14] Internet-Draft Document October 2006 authenticated use. 8. IANA Considerations This document does not request any IANA considerations. 9. Acknowledgements This document has benefited from discussions with numerous people, especially Shane Amante, Brian Carpenter, and Dave McDysan. It has also benefited from detailed reviews by David Black and Marvin Krym. 10. References 10.1. Normative References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate =20 Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Nichols, K., Blake, S., Baker, F., and D. Black, =20 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [5] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [6] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, Chan, et al. Expires April 23, 2007 [Page 15] Internet-Draft Document October 2006 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998. [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. 10.2. Informative References [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay in an Operational Network", INFOCOMM 2004, March 2004, . [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on 9/11", March 2002, . Authors' Addresses Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-8175 Fax: +1-978-288-8700 Email: khchan@nortel.com Chan, et al. Expires April 23, 2007 [Page 16] Internet-Draft Document October 2006 Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Fax: +1-613-768-2231 Email: babiarz@nortel.com Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com Chan, et al. Expires April 23, 2007 [Page 17] Internet-Draft Document October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. =20 Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chan, et al. Expires April 23, 2007 [Page 18] From tsvwg-bounces@ietf.org Thu Jan 11 19:15:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5A49-0006OK-4o; Thu, 11 Jan 2007 19:14:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5A47-0006Nt-GK; Thu, 11 Jan 2007 19:14:39 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5A46-0001ed-3B; Thu, 11 Jan 2007 19:14:39 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PJfzW1bGVTLYQu5wq5ELrJFM6gqUiBo4s8nvmdXUMz7Ql+iiX25lWLsNgp+WNGiH; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.174.169] (helo=earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H5A44-0005Wc-3v; Thu, 11 Jan 2007 19:14:36 -0500 Message-ID: <45A6D0DD.9CDD9189@earthlink.net> Date: Thu, 11 Jan 2007 16:05:49 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] review solicitation for ICCRG congestion control survey References: <20070111155541.GA25291@grc.nasa.gov> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79475e8221968e47fb0ccdd56e563e7b49350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.174.169 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tcpm@ietf.org, tsvwg@ietf.org, iccrg@cs.ucl.ac.uk, dccp@ietf.org, tsv-area@ietf.org, rmt@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org To the world, Doesn't this document initially imply that ONLY "feedback-based adjustment" type responses are available to ameloriate congestion. As congestion approaches, the lack of acks/feedback can also indicate congestion. So I would first modify section "1" to indicate that the loss of feedback is also a level of feedback that needs to be considered. IMO, in full congestion collapse with a significant number of non congestion aware flows, any adjustment of congestion aware flows would not effect the overall congested environment. Thus, most if not all congestion avoidance algorithms assume that congestion can be altered by the aware flows. This document needs to be cognizant of that fact and state that no algorithm would be successful in any congestion event that is controlled by unaware flows. Thus, to guarantee a congestion collapse free "area/AS" or minimize the amount of congestion, the bandwidth consumption needs to be controlled. It can be controlled at either the entry to the area/AS by a transit flow or controlled at the src end point. Doing neither ameliorates any effect of any congestion control algorithm. Thus, this document mostly covers the investigaion of "area/ASs" where congestion is a concern and what has been proposed to minimize the effects of congestion. In addition, this reader is unaware whether this document prefers flows that are at the precipice of congestion or whether a significant buffer of lost bandwidth should be used to minimize any congestion type behaviours. Lastly, IMO a general concensus needs to be developed to determine what are the initial measured indications of congestion. The general TCP method is the loss of a pkt/segment. Should it be increased RTTs due to longer queues? Or should it be the combination of the two? Is a time aware (real-time) flow in congestion if required parameters are exceeded? etc.. Mitchell Erblich =========== Wesley Eddy wrote: > > In the ICCRG's goal to foster a long-term congestion control > architecture for the Internet, its initial step is to understand all of > the current mechanisms in use. As an aid to this, the ICCRG is working > on a document that summarizes all of the congestion control mechanisms > and other guidance that the IETF has produced and published in the RFC > series. The initial version of this document is online: > http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt > > We think this is a fairly complete listing of the RFCs that relate to > congestion control, but if you know of others that should be included, > we would like to hear about it. > > Also, comments on what can be done to make this more useful or readable > are welcome. Comments on and improvements to the text summarizing each > RFC are also welcome. > > The goal is to gather these inputs before the ICCRG meeting in > mid-February. After the ICCRG meeting, the document will be updated > based on these comments and discussion from the meeting. > > Please send all comments to the ICCRG list (iccrg@cs.ucl.ak.uk). Although > this request is being sent to multiple lists, this is only to notify > people not on the ICCRG list; we do not want to burden the other mailing > lists with replies, so please trim the "to" and "cc" fields of replies. > > Thanks in advance. > > -- > Wesley M. Eddy > Verizon Federal Network Systems From tsvwg-bounces@ietf.org Thu Jan 11 22:51:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DRR-0003w8-P8; Thu, 11 Jan 2007 22:50:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DRQ-0003vu-5s for tsvwg@ietf.org; Thu, 11 Jan 2007 22:50:56 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5DRM-0000NY-Kt for tsvwg@ietf.org; Thu, 11 Jan 2007 22:50:55 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jan 2007 19:50:52 -0800 X-IronPort-AV: i="4.13,175,1167638400"; d="scan'208"; a="759071766:sNHT44752660" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0C3op1h032657; Thu, 11 Jan 2007 19:50:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0C3okDm006591; Thu, 11 Jan 2007 19:50:47 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:50:46 -0800 Received: from [192.168.116.180] ([10.21.96.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:50:45 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89FB19D5-4F09-4AA8-A947-DA01462CCF3F@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Tsvwg] Admitted Real Time Services Date: Fri, 12 Jan 2007 04:50:34 +0100 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jan 2007 03:50:45.0880 (UTC) FILETIME=[D704DF80:01C735FC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=963; t=1168573851; x=1169437851; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[Tsvwg]=20Admitted=20Real=20Time=20Services |Sender:=20; bh=F+0WrrYKdjkXu2lwY/s/X4AJcF5m7nnSvHR2bb3UJeA=; b=opfgO/VwftBM1Ivn5JceeY3dachb7PjBy/D3JBrD9VvW2KWOiEj4pzuQrzl2LxbaK7iw32yE X8DGBAhT5dRWa6YPohiFw9W5546HLzEZXfPPiaO/ZxqYWOVTDQ3cVvN8; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Lars Eggert , "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Dec 18, 2006, at 9:22 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > i should have been more specific - the whole discussion about > signaling is beyond the scope this document whether performed at at > the network (RSVP) or the session layer (SIP) or any other > signaling technique being currently under discussion at IETF - this > doc. should not discuss about the call-level but stick to packet- > level processing and related operations (that should translated in > a DS configuration profile) Given that we already have a class for voice in RFC 4594, and this is is creating one with the specific characteristic that it requires (as opposed to the existing-and-deployed one that merely recommends and in many cases doesn't use) capacity admission, I'm at a loss to figure out why you would want to remove capacity admission from the document. Can you please state why you think this is as you see it? From tsvwg-bounces@ietf.org Thu Jan 11 22:52:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DT7-0004kw-Cp; Thu, 11 Jan 2007 22:52:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DT6-0004jx-7c for tsvwg@ietf.org; Thu, 11 Jan 2007 22:52:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5DT3-0000SP-BC for tsvwg@ietf.org; Thu, 11 Jan 2007 22:52:40 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 19:52:36 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0C3qadm010693; Thu, 11 Jan 2007 19:52:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0C3qaho028554; Thu, 11 Jan 2007 19:52:36 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:52:35 -0800 Received: from [192.168.116.180] ([10.21.96.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:52:32 -0800 In-Reply-To: <0JB9002CN0LMPA@dgismtp03.mcilink.com> References: <0JB9002CN0LMPA@dgismtp03.mcilink.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 12 Jan 2007 04:52:28 +0100 To: Dave McDysan X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jan 2007 03:52:32.0846 (UTC) FILETIME=[16C696E0:01C735FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11481; t=1168573956; x=1169437956; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Review=20of=20=20draft-ietf-tsvwg-diffserv-class-aggr |Sender:=20; bh=h6NSi4UGFJJxBAy7xOnikHFjrAsWRsSgQWIZd3pGsQk=; b=tu3YX+lYg1alpBXqRCafwsq1CSCzstKo7gG4V1M3H8DsVIfOM8i5JvC7GFfqGH+MhCMr1Br+ Lt6RCYa7t+Mk2p5ApXHcBPu9nbKgRRsoVEhC1te4sa0pyOQzMLqw9opH; Authentication-Results: sj-dkim-5; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: 'Magnus Westerlund' , babiarz@nortel.com, 'tsvwg' , 'Kwok-Ho Chan' Subject: [Tsvwg] Re: Review of draft-ietf-tsvwg-diffserv-class-aggr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Thanks for your review, Dave. Given that we update per your comments, do you feel that the document serves Verizon? Do you feel this is going in a direction that is useful to you? On Jan 2, 2007, at 5:03 PM, Dave McDysan wrote: > As requested, here is my review of the subject draft. > > Within Verizon and draft work in the MPLS FR ATM Alliance (MFA) we > are using > RFC 4594 and ITU-T Y.1541 in our definitions of Diffserv, PW and > native MPLS > deployments. An RFC that gave some guidance and a baseline for how > to map > these various services to treatment aggregates as defined by MPLS > EXP bits > would be extremely useful for internal use as well as use in > specifying > network interconnections. These comments are based upon a review of > the > various deployed and proposed uses of EXP bits within Verizon, > experience on > negogiating interconnects with other service providers, work within > the MFA > and the results of MIT Interprovider QoS workshops, as summarized > in the > following: > http://cfp.mit.edu/resources/papers/Interprovider%20QoS% > 20MIT_CFP_WP_9_14_06 > .pdf > > Suggest that in section 1, Introduction that the draft explicitly > state the > assumption that all traffic is IP and marked with a particular set > of DSCP > values, as described in RFC 4594. > > In some cases cited below bullet 5 in section 3, overview of > service class > aggregation, the traffic carried may not be IP (e.g., TDM, FR, ATM or > Ethernet over pseudowire, VPLS). Section 2, Terminology, references > RFC 3270 > definitions of E-LSP and L-LSP, which include the concept of a > Forwarding > Equivalency Class (FEC). I suggest that either the scope of this draft > should be constrained to only IP and these other applications be > mentioned > as out of scope, or else more text regarding handling of non-IP > applications > needs to be added. For example, there could be an IP FEC and a non- > IP FEC > for use with E-LSP or L-LSP from RFC 3270. > > Suggest that the authors add some text to section 4.1., Mapping > Service > Classes into Four Treatment Aggregates, explaining why those chose > 4 instead > of 3 or 5 treatment aggregates. From section 1, " Note that in a given > domain, we may recommend that the supported service classes be > aggregated > into forwarding treatment aggregates; however, this does not mean > all > service classes need to be supported and hence not all forwarding > treatment > aggregates need to be supported." This text implies specification of a > maximum set of treatment aggregates, and a means to map these to a > minimum > set. Is the intent of this draft to specify the minimum or maximum > set? > > In Figure 1, Treatment Aggregate and Service Class Performance > Requirements, > I think that broadcast video is not Real-Time. Also, in enterprise > VPNs, we > have distinguished Telephony/Signaling from Mulitmedia conferencing in > treatment aggregates in deployed networks. > > Section 4.1.1. Network Control Treatment Aggregate. We view > network control > as an IP-only service class, not subject to (MPLS) treatment > aggregation. > Although some VPN service providers have proposed extending this > service > class across an interconnect to their networks, we have convinced > them that > they should map customer network control traffic (e.g., BGP, or IGP > information for an RFC 4364 VPN) or their own network control class > to some > other behavior or treatment aggregate. > > Suggest that the draft add some text indicating that network > control traffic > is for internal use to a network. For example, Section 4.2.1 of RFC > 4274 > could be cited: "The Network Control precedence designation is > intended to > be used within a network only. The actual use and control of that > designation is up to each network. [RFC791]" > > 4.1.2. Real Time Treatment Aggregate. As mentioned above, current and > planned deployments break out telephony/signaling from multimedia > conferencing and broadcast video. If the draft is proposing that the > real-time treatment aggregate (as defined in 1994 from RFC 1633) is > part of > a minimum treatment aggregate set, then it should state this. I > would like > to see mention of a larger treatment aggregate set that at least > splits out > telephony/signaling from multimedia conferencing and broadcast video. > > 4.1.3. Assured Elastic Treatment Aggregate. Personally, I think > that the > indication of loss probability in a treatment aggregate is a good > idea. > However, some deployments and plans do not use this. Also, this > means using > up to an additional bit in the limited 3-bit MPLS EXP field. > Suggest that > the draft state that indicating the loss probability is highly > desirable, > but may not be part of the minimum set of treatment aggregates that a > network segment may implement (see section 1). > > 4.1.4. Elastic Treatment Aggregate. Personally, I think that the > indication > of loss probability in a treatment aggregate is a good idea. > However, some > deployments and plans do not use this. Also, this means using up to an > additional bit in the limited 3-bit MPLS EXP field. Suggest that > the draft > state that indicating the loss probability is highly desirable, but > may not > be part of the minimum set of treatment aggregates that a network > segment > may implement (see section 1). > > 5. Using MPLS for Treatment Aggregates, first paragraph. As mentioned > above, suggest that the authors clarify whether this is the maximum or > minimum set of treatment aggregates as described in section 1 that are > recommended. > > This section is where the most significant issues exist. > > 5.1. Network Control Treatment Aggregate with E-LSP > > In discussions with internal users as well as discussions in the > MFA, there > is not much support for using a set of MPLS EXP bits for network > control. > Looking at the description for network control from RFC 4594, it > appears > that most of these uses would be IP only and not be subject to MPLS > encapsulation. The one exception we discussed is how to handle network > control DSCP marked packets from BGP IP MPLS VPN customers. This > could be > done using the proposed "110" codepoint in Figure 3, but another > method > would be for the service provider to map customer network control > traffic to > some other treatment aggregate (e.g., assured elastic). Suggest > that the > network control treatment aggregate usage with MPLS EXP bit marking > be more > clearly stated in the draft. Also, suggest that the network control > treatment aggregate be part of the maximum treatment aggregate set. > > 5.2. Real Time Treatment Aggregate with E-LSP > > As mentioned above, this differs from uses within Verizon, the MIT QoS > Interprovider workshop and discussions in the MFA. The MPLS EXP bit > values > of "101" are used in at least these contexts to indicate only > telephony/signaling for EF/CS5. This is the most significant > difference > between the draft and other publications and industry work. Also we > have > assigned the AF4x DSCP for multimedia conferencing as MPLS EXP > "100," and > also treat broadcast video as another RFC 3270 FEC. > > In order to resolve this comment, suggest that the draft define a > minimum > subset of the "real-time" treatment aggregate and mention that some > network > segments (see section 1) may define a larger set along the lines of > what I > mention above. > > Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment Aggregate > with E-LSP > > These MPLS EXP code points (without the loss probability bit > encoding) are > what is used in several VPN and public IP networks. > > Section 5 - Additional comments > > If the scope decision of this document is to expand to non-IP > applications, > then additional text on handling Pseudowires with client services > having > their own QoS definitions, VPLS and other potential uses of MPLS > would need > to be added. My recommendation would be to keep this document > focused on the > IP applications, and if anyone is interested then another document > that > covered non-IP applications could be drafted. > > 6. Treatment Aggregates and Inter-Provider Relationships > > Suggest addition of a reference to the MIT QoS Interprovider white > paper > mentioned above. After much discussion, the service providers > involved in > this effort were only able to agree on a minimum set of two treatment > aggregates. > > Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. > Appendix > VI defines a minimum set of three QoS classes and a mapping to > (sets of) > IETF DSCP values as follows: > > Y.1221 Associated Y.1541 > Transfer Diffserv QoS > Capability PHBs Class(es) > ------------ ---------- -------- > Best Effort Default 5 > > Delay-Sensitive AF 2,3,4 > Statistical BW > > Dedicated EF 0,1 > Bandwidth > > (If you don't have ITU access, you can get up to three free ITU-T > documents > per Email address by going to www.itu.int and going to the purchase > page and > entering your email address.) > > Many international providers look to the ITU-T for guidance, and > that would > be the focus on many of our network provider interconnection uses of > treatment aggregates and MPLS EXP bit markings. Therefore, at least > some > mention of a similar minimum subset of aggregations proposed by the > ITU-T in > this document would be valuable. Finally, I note that if network > control is > removed from the minimum subset in this draft, then the above set > from ITU-T > Y.1541 Appendix VI is equivalent in terms of number of treatment > aggregates > and a high-level mapping of service capabilities. > > Regards, > > Dave > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, December 07, 2006 10:32 AM >> To: tsvwg >> Subject: [Tsvwg] Need for volunteers for reviewing >> draft-ietf-tsvwg-diffserv-class-aggr >> >> Hi, >> >> To make progress we need some reviewers to read and comment >> on "Aggregation of DiffServ Service Classes": >> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class- > aggr-01. > txt >> >> We chairs don't think we can proceed with this draft until we >> seen some confirming reviews from the WG participants. So >> please volunteer. >> >> If you are willing to do this review please indicate so to us chairs. >> >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> --------------------------------------------------------------------- >> - >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> --------------------------------------------------------------------- >> - >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >> >> >> From tsvwg-bounces@ietf.org Thu Jan 11 22:54:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DVG-00060I-JE; Thu, 11 Jan 2007 22:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DVE-0005v4-8f for tsvwg@ietf.org; Thu, 11 Jan 2007 22:54:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5DV9-0003C3-G1 for tsvwg@ietf.org; Thu, 11 Jan 2007 22:54:52 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2007 19:54:47 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0C3skv5014303; Thu, 11 Jan 2007 19:54:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0C3sSnX024719; Thu, 11 Jan 2007 19:54:46 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:54:46 -0800 Received: from [192.168.116.180] ([10.21.96.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 19:54:39 -0800 In-Reply-To: <651B5C0033306A45BC11E409451A60C502D5B4C6@WSMSG2103V.srv.dir.telstra.com> References: <651B5C0033306A45BC11E409451A60C502D5B4C6@WSMSG2103V.srv.dir.telstra.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: Fri, 12 Jan 2007 04:54:36 +0100 To: "Dickinson, Fil" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jan 2007 03:54:40.0849 (UTC) FILETIME=[63124C10:01C735FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=52121; t=1168574086; x=1169438086; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[Tsvwg]=20FW=3A=20Review=20of=20=20draft-ietf-tsvwg-d iffserv-class-aggr |Sender:=20; bh=rpWQnXnXiS2By0bVodvFqf8c2ltzlXJzb0msOFU0jjs=; b=axntkhaOWXjM6bbv7mZjAqqDUtWnbtNfOAHhSGPf+qSdgaMAA/KjSDQuoieNmSYQFEFhE/NV Y1m1UeIVe5VK6GP87O6Gp4SVeMENAzjJHE3J+66nVMZ7Kpn9b9RGw3H1; Authentication-Results: sj-dkim-6; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 933574082e9c73b77c13a13d45bce65c Cc: tsvwg , Magnus Westerlund X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org I'll ask you the same question I just asked Dave. Given that we update to reflect Bruce's comments, do you think this draft is going in a direction that is beneficial to Telstra? It sounds like "yes", but I'd like to hear the statement made. On Jan 12, 2007, at 12:31 AM, Dickinson, Fil wrote: > Hi Bruce. > I may be misinterpeting your last point but I do not agree with it. > I think we do need a "recommendation" on an approach to diffserv class > aggregation. I agree that it should not be "to the effect that > there is > only one valid way to run a Diffserv network", but see a need for a > defined recommended approach. > I think this is necessary so that service providers can refer to a > documented approach by a recognised standards body when designing > their > own networks, agreeing interprovider implementations with peers and > dealing with inter-vendor interpretations of diffserv class > aggregation. > > -----Original Message----- > From: Bruce Davie [mailto:bdavie@cisco.com] > Sent: Friday, 12 January 2007 9:33 AM > To: tsvwg > Cc: Magnus Westerlund > Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class- > aggr > > I too send comments that never made it to the archive. > > Here they are again. > > Bruce > > From: bdavie@cisco.com > Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr > Date: December 21, 2006 11:20:33 AM EST > To: magnus.westerlund@ericsson.com > Cc: tsvwg@ietf.org > > As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- > aggr-01.txt > > My line by line comments are below, prefaced by [BD] > > My top level comments are as follows: > > 1. The main contribution of this draft can be summarized very > briefly: you can aggregate different classes of traffic into bigger > classes that get the same treatment as long as that treatment is good > enough to meet the needs of the most stringent class. > > 2. A second contribution is to observe that if you do aggregate, it > would be nice to preserve markings such that de-aggregation can be > performed later. > > 3. Beyond that, the document makes a lot of specific recommendations > about precisely how you should aggregate in both IP and MPLS networks. > My concern with this aspect of the document is that there are > essentially an infinite number of valid ways to aggregate traffic. For > example, one of the most popular is to give all traffic in the core of > an over-provisioned network the same treatment - so- called "best > effort" treatment, but actually it is a treatment that is so good that > even the most stringent class of traffic gets adequate service. This > approach to aggregation goes unmentioned in the document, as does the > fact that many other options are valid. > > At a minimum, this document should be revised to make it clear that it > is describing ONE possible approach out of many more that are > possible. > Since it is being progressed by the TSVWG, statements that begin "we > recommend..." should probably be rewritten to be of the form "A > possible > option is..." A great deal of effort went into writing the DiffServ > standards in such a way that operators and vendors would not be overly > constrained. A set of recommendations from the TSVWG, even in an > informational RFC, to the effect that there is only one valid way > to run > a Diffserv network, does not seem like something we want to produce. > > Bruce > -------- > > > > TSVWG K. > Chan > Internet-Draft J. > Babiarz > Intended status: Informational Nortel > Networks > Expires: April 23, 2007 F. > Baker > Cisco > Systems > October 20, > 2006 > > > Aggregation of DiffServ Service Classes > draft-ietf-tsvwg-diffserv-class-aggr-01 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents > at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 23, 2007. > > Copyright Notice > > Copyright (C) The Internet Society (2006). > > Abstract > > In the core of a high capacity network, service differentiation is > still needed to support applications' utilization of the network. > Applications with similar traffic characteristics and performance > requirements are mapped into diffserv service classes based on > end- > to-end behavior requirements of the applications as indicated by > Diffserv Service Classes [5]. However, some network segments > may be > > > > Chan, et al. Expires April 23, 2007 > [Page 1] > Internet-Draft Document October > 2006 > > > configured in such a way that a single forwarding treatment may > satisfy the traffic characteristics and performance > requirements of > two or more service classes. In these cases, it may be > desirable to > aggregate two or more Diffserv Service Classes [5] into a single > forwarding treatment. This document provides guidelines for the > aggregation of Diffserv Service Classes [5] into forwarding > treatments. > > > Table of Contents > > 1. > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Requirements > Notation . . . . . . . . . . . . . . . . . . 4 > 2. > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Overview of Service Class > Aggregation . . . . . . . . . . . . 5 > 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . > 6 > 4.1. Mapping Service Classes into Four Treatment Aggregates . . > 6 > 4.1.1. Network Control Treatment Aggregate . . . . . . . . . > 8 > 4.1.2. Real Time Treatment > Aggregate . . . . . . . . . . . . 9 > 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . > 9 > 4.1.4. Elastic Treatment > Aggregate . . . . . . . . . . . . . 10 > 5. Using MPLS for Treatment > Aggregates . . . . . . . . . . . . . 11 > 5.1. Network Control Treatment Aggregate with E- > LSP . . . . . . > 13 > 5.2. Real Time Treatment Aggregate with E- > LSP . . . . . . . . . > 13 > 5.3. Assured Elastic Treatment Aggregate with E- > LSP . . . . . . > 13 > 5.4. Elastic Treatment Aggregate with E- > LSP . . . . . . . . . . > 13 > 5.5. Treatment Aggregates and L- > LSP . . . . . . . . . . . . . . > 14 > 6. Treatment Aggregates and Inter-Provider Relationships . . . . > 14 > 7. Security > Considerations . . . . . . . . . . . . . . . . . . . 14 > 8. IANA > Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 9. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 > 10. > References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 10.1. Normative > References . . . . . . . . . . . . . . . . . . . 15 > 10.2. Informative > References . . . . . . . . . . . . . . . . . . 16 > Authors' > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 > Intellectual Property and Copyright Statements . . . . . . . . . . > 18 > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 > [Page 2] > Internet-Draft Document October > 2006 > > > 1. Introduction > > In the core of a high capacity network, it is common for the > network > to be engineered in such a way that a major link, switch, or > router > can fail and the result will be a routed network that still meets > ambient SLAs. The implication of this is that there is sufficient > capacity on any given link such that all SLAs sold can be > simultaneously supported at their respective maximum rates, and > that > this remains true after re-routing (either IP re-routing or MPLS > protection-mode switching) has occurred. > > Over-provisioning is generally considered to meet the requirements > of > all traffic without further QoS treatment, and in the general case > that is true in high capacity backbones. However, as the > process of > network convergence continues, and with the increasing speed of > the > access networks, certain services still have issues. Delay, > jitter, > and occasional loss are perfectly acceptable for elastic > applications. However, sub-second surges that occur in the best- > designed of networks [14] affect real-time applications. > Moreover, > DOS loads, worms, and network disruptions such as that of 11 > September 2001 affect routing [15]. Our objective is to prevent > disruption to routing (which in turn affects all services), and > jitter-sensitive services that may be revenue-bearing. > > [BD] It took me a long time to understand the above sentence. It could > be read to mean that an objective of the draft is to prevent jitter > sensitive services, which is probably not the intent. > Also, I think the comment about preventing disruption to routing > relates > to the desire to protect network control traffic from loss, so perhaps > you should say that (since there are lots of ways that routing may get > disrupted that are outside the scope of this draft). > > > The document "Diffserv Service Classes" [5] defines the basic > diffserv classes from the points of view of the application > requiring > specific end-to-end behaviors from the network. The service > classes > are differentiated based on the traffic-payload's tolerance to > packet > loss, delay, and delay variation (jitter). Different degrees of > these criterions form the foundation for supporting the needs of > > [BD] criterions -> criteria, or even better "Different values of these > metrics form..." > > real-time and elastic traffic. The "Diffserv Service Classes" [5] > document also provides recommendations for the treatment method of > these service classes. But, at some network segments of the > end-to- > end path, the number of levels of network treatment > differentiation > may be less than the number of service classes that the network > segment needs to support. In such a situation, that network > segment > may use the same treatment to support more than one service class. > In this document we provide guidelines on how multiple service > classes may be aggregated into a forwarding treatment aggregate. > Note that in a given domain, we may recommend that the supported > service classes be aggregated into forwarding treatment > aggregates; > however, this does not mean all service classes need to be > supported > and hence not all forwarding treatment aggregates need to be > supported. Which service classes and which forwarding treatment > aggregates are supported by a domain is up to the domain > administration and may be influenced by business reasons. > > In this document, we've provided: > > > > Chan, et al. Expires April 23, 2007 > [Page 3] > Internet-Draft Document October > 2006 > > > o definitions for terminology we use in this document, > > o requirements for performing this aggregation, > > o an example of performing this aggregation over MPLS using E- > LSP. > > The treatment aggregate recommendations are designed to aggregate > the > service classes [5] in such a manner as to protect real-time > traffic > and routing, on the assumption that real-time sessions are > protected > from each other by admission at the edge. > > An example of aggregation over MPLS networks using E-LSP, EXP > Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to > realize the treatment aggregates is provided. Note that the MPLS > E-LSP is just an example; this document does not exclude the > use of > other methods. > > 1.1. Requirements Notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in RFC 2119 [3]. > > > 2. Terminology > > This document assumes the reader is familiar with the terms > used in > differentiated services. This document provides the > definitions for > new terms introduced by this document and referencing information > for > existing none differentiated services terms defined in existing > RFCs. > > For new terms introduced by this document, we provide the > definition > here: > > o Treatment Aggregate. This term is used here to indicate the > aggregate of DiffServ service classes. This is different from > Behavior Aggregate and Traffic Aggregate because Treatment > Aggregate is only concerned with the treatment of the > aggregated > traffic. It does not concern itself with how the aggregated > traffic is marked, and hence does not put a restriction on the > aggregated traffic having a single diffserv codepoint that > have a > single PHB. > > For terms from existing RFCs, we provide the reference to the > appropriate section of the relevant RFC that contain the > definition: > > o Real-Time and Elastic Applications and their traffic. Section > 3.1 > of RFC 1633 [6]. > > > > Chan, et al. Expires April 23, 2007 > [Page 4] > Internet-Draft Document October > 2006 > > > o Diffserv Service Class. Section 1.3 of > draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. > > o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label > Switched > Path (LSP). Section 1.2 of RFC 3270 [8]. > > o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) > Label > Switched Path (LSP). Section 1.3 of RFC 3270 [8]. > > > 3. Overview of Service Class Aggregation > > In diffserv domains where less granular traffic treatment > differentiation is provided, aggregation of the different service > classes [5] may be required. > > These aggregations have the following requirements: > > [BD] I don't understand where these requirements come from. > > 1. The end-to-end network performance characteristic required by > the > application must be supported. This performance > characteristic > is represented by the use of Diffserv Service Classes [5]. > > 2. The treatment aggregate must exhibit the strictest requirement > of > its member service classes. > > 3. The treatment aggregate should only contain member service > classes with similar traffic characteristic and performance > requirements. > > [BD] Why? Isn't it OK to aggregate wildly different service classes > and > give them all treatment that is a good as the most stringent > requirements of any class? > > 4. The notion of the individual end-to-end service classes > must not > be destroyed when aggregation is performed. Each domain along > the end-to-end path may perform aggregation differently, based > on > the original end-to-end service classes. We recommend an easy > way to accomplish this by not altering the DSCP used to > indicate > the end-to-end service class. But some administrative domains > may require the use of their own marking; when this is needed, > the original end-to-end service class indication must be > restored > upon exiting such administrative domains. > > [BD] You seem to have strayed away from stating requirements when you > start recommending how to mark the DSCP. I *think* that what you are > trying to say is that the information about which service class > belongs > to should not be lost during aggregation; such information loss would > occur, for example, if several different classes were remarked to a > common DSCP value. > > 5. Each treatment aggregate has limited resources, hence traffic > conditioning and/or admission control must be performed for > each > service class aggregated into the treatment aggregate. > > [BD] Where is this requirement from? Are you saying that it's not > possible to aggregate traffic with also performing admission > control or > traffic conditioning? Many SPs would disagree. > > with the following suggestions: > > 1. The treatment aggregate and assigned resources may consider > historical traffic patterns and the variability of these > patterns. For example, a point-point service (e.g., > pseudowire) > > > > Chan, et al. Expires April 23, 2007 > [Page 5] > Internet-Draft Document October > 2006 > > > may have a very predictable pattern, while a multipoint > service > (e.g., VPLS) may have a much less predictable pattern. > Even the > traffic patterns within the Internet may vary widely. > > 2. In addition to Diffserv, other controls are available to > influence the traffic level offered to a particular traffic > aggregate. These include adjustment of routing metrics, usage > of > MPLS-based traffic engineering techniques. > > > 4. Service Classes to Treatment Aggregate Mapping > > The service class and DSCP selection in "Diffserv Service Classes" > [5] has been defined to allow, in many instances, mapping of > two or > possibly more service classes into a single forwarding treatment > aggregate. Notice that there is a relationship/trade-off between > link speed, queue depth, delay, and jitter. > > [BD] The preceding sentence should also mention link utilization. > > The degree of > aggregation and hence the number of treatment aggregates will > depend > on whether the speed of the links and scheduler behavior, being > used > to implement the aggregation, can minimize the affects of mixing > traffic with different packet sizes and transmit rates on queue > depth. And their impacts on loss, delay, and jitter. A general > rule-of-thumb is that higher link speeds allow for more > aggregation/ > smaller number of treatment aggregates. > > [BD] That rule of thumb seems to be incorrect if a link is run at 100% > utilization. A more useful rule of thumb might take utilization into > accoutn. > > > 4.1. Mapping Service Classes into Four Treatment Aggregates > > [BD] It is probably worth mentioning that this is just an example and > that more or fewer treatment aggregates may be required. > > This section explains one way of performing this aggregation by > using > four treatment aggregates. The use of four treatment aggregates > assumes that the resources allocated to each treatment > aggregate is > sufficient to honor the required behavior of each service class > [5] > in each of the four treatment aggregates. We use the performance > requirement (tolerance to loss, delay, and jitter) from the > application/end-user as a guide on how to map the service classes > into treatment aggregates. We have also used Section 3.1 of RFC > 1633 > [6] to provide us with guidance on the definition of Real-Time and > Elastic applications. An overview of the mapping between service > classes and the four treatment aggregates is provided by Figure 1, > with the mapping being based on performance requirements. In > Figure > 1, the right side columns of "Service Class", "Tolerance to Loss/ > Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. > > It is recommended that certain service classes be mapped into > specific treatment aggregates. But this does not mean that all > the > service classes recommended for that treatment aggregate need > to be > supported. Hence, for a given domain, a treatment aggregate may > contain only a subset of the service classes recommended in this > document, they being the service classes supported by that domain. > A > > > > Chan, et al. Expires April 23, 2007 > [Page 6] > Internet-Draft Document October > 2006 > > > domain's treatment of non-supported service classes should be > based > on the domain's local policy. This local policy may be influenced > by > its agreement with its customers. Such treatment may use the > Elastic > Treatment Aggregate, dropping the packets, or some other > arrangements. > > > --------------------------------------------------------------------- > |Treatment | Tolerance to ||Service Class | Tolerance > to | > |Aggregate | Loss |Delay |Jitter|| | Loss |Delay | > Jitter| > |==========+======+======+======++===============+======+====== > +======| > | Network | Low | Low | Yes || Network | Low | Low | > Yes | > | Control | | | || Control | | > | | > |==========+======+======+======++===============+======+====== > +======| > | Real | Very | Very | Very || Telephony | VLow | VLow | > VLow | > | Time | Low | Low | Low ||---------------+------+------ > +------| > | | | | || Signaling | Low | Low | > Yes | > | | | | ||---------------+------+------ > +------| > | | | | || Multimedia |Low - | Very | > Low | > | | | | || Conferencing |Medium| Low > | | > | | | | ||---------------+------+------ > +------| > | | | | || Real-time | Low | Very | > Low | > | | | | || Interactive | | Low > | | > | | | | ||---------------+------+------ > +------| > | | | | || Broadcast | Very |Medium| > Low | > | | | | || Video | Low | > | | > |==========+======+======+======++===============+======+====== > +======| > | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| > Yes | > | Elastic | |Medium| || Streaming |Medium| > | | > | | | | ||---------------+------+------ > +------| > | | | | || Low Latency | Low |Low - | > Yes | > | | | | || Data | | > Medium| | > | | | | ||---------------+------+------ > +------| > | | | | || OAM | Low |Medium| > Yes | > | | | | ||---------------+------+------ > +------| > | | | | ||High Throughput| Low |Medium| > Yes | > | | | | || Data | |- > High| | > |==========+======+======+======++===============+======+====== > +======| > | Elastic | Not Specified || Standard | Not > Specified | > | | | | ||---------------+------+------ > +------| > | | | | || Low Priority | High | High | > Yes | > | | | | || Data | | > | | > > --------------------------------------------------------------------- > > Figure 1: Treatment Aggregate and Service Class Performance > Requirements > > As we are recommending to preserve the notion of the individual > end- > to-end service classes, we also recommend that the original DSCP > > > > Chan, et al. Expires April 23, 2007 > [Page 7] > Internet-Draft Document October > 2006 > > > field marking not be changed when treatment aggregates are used. > Instead, classifiers that select packets based on the contents of > the > DSCP field should be used to direct packets from the member > DiffServ > Service Classes into the queue that handles each of the treatment > aggregates, without remarking the DSCP field of the packets. > This is > summarized in Figure 2, which shows the behavior each Treatment > Aggregate should have, and the DSCP field marking of the packets > that > should be classified into each of the treatment aggregates. > > ------------------------------------------------------------ > |Treatment |Treatment || DSCP | > |Aggregate |Aggregate || | > | |Behavior || | > |==========+==========++=====================================| > | Network | CS || CS6 | > | Control |(RFC 2474)|| | > |==========+==========++=====================================| > | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | > | Time |(RFC 3246)|| | > |==========+==========++=====================================| > | Assured | AF || CS2, AF31, AF21, AF11 | > | Elastic |(RFC 2597)||-------------------------------------| > | | || AF32, AF22, AF12 | > | | ||-------------------------------------| > | | || AF33, AF23, AF13 | > |==========+==========++=====================================| > | Elastic | Default || Default, (CS0) | > | |(RFC 2474)||-------------------------------------| > | | || CS1 | > ------------------------------------------------------------ > > Figure 2: Treatment Aggregate Behavior > > 4.1.1. Network Control Treatment Aggregate > > The Network Control Treatment Aggregate aggregates all service > classes that are functionally necessary for the survival of a > network > during a DOS attack or other high traffic load interval. The > theory > is that whatever else is true, the network must protect itself. > This > includes the traffic that "Diffserv Service Classes" [5] > characterizes as being included in the Network Control Service > Class. > > The DSCPs of the original service class remain an important > consideration and should be preserved during aggregation. > Traffic in > the Network Control treatment aggregate should be carried in a > common > queue or class with a PHB as described in RFC 2474 [4] section > 4.2.2.2. This treatment aggregate should have a lower probability > of > packet loss, bearing a relatively deep target mean queue depth > (min- > > > > Chan, et al. Expires April 23, 2007 > [Page 8] > Internet-Draft Document October > 2006 > > > threshold if RED is being used). > > 4.1.2. Real Time Treatment Aggregate > > The Real Time Treatment Aggregate aggregates all real-time > (inelastic) service classes. The theory is that real-time traffic > is > admitted under some model and controlled by a SLA managed at the > edge > of the network prior to aggregation. As such, there is a > predictable > and enforceable upper bound on the traffic that can enter such a > queue, and to provide predictable variation in delay it must be > protected from bursts of elastic traffic. The predictability of > traffic level may be based upon admission control for a well known > community of interest (e.g., a point-point service) and/or based > upon > historical measurements. > > This treatment aggregate may include the following service classes > from the Diffserv Service Classes [5], in addition to other > locally > defined classes: Telephony, Signaling, Multimedia Conferencing, > Real- > time Interactive, Broadcast Video. > > Traffic in each service class that is going to be aggregated into > the > treatment aggregate should be conditioned prior to > aggregation. It > is recommended that per service class admission control procedures > be > used followed by per service class policing so that any individual > service class does not generate more than what it is allowed. > Furthermore, additional admission control and policing may be used > on > the sum of all service classes aggregated. > > The DSCPs of the original service classes remain an important > consideration and should be preserved during aggregation. Traffic > bearing these DSCPs is carried in a common queue or class with > a PHB > as described in RFC 3246 [11] and RFC 3247 [12]. > > 4.1.3. Assured Elastic Treatment Aggregate > > The Assured Elastic Treatment Aggregate aggregates all elastic > traffic that uses the Assured Forwarding model as described in RFC > 2597 [10]. The premise of such a service is that a SLA is > negotiated > which includes a "committed rate" and the ability to exceed that > rate > (and perhaps a second "excess rate") in exchange for a higher > probability of loss using AQM [9] or ECN flagging [13] for the > portion of traffic deemed to be in excess. > > This treatment aggregate may include the following service classes > from the Diffserv Service Classes [5], in addition to other > locally > defined classes: Multimedia Streaming, Low Latency Data, OAM, High > Throughput Data. > > > > > Chan, et al. Expires April 23, 2007 > [Page 9] > Internet-Draft Document October > 2006 > > > The DSCP values belonging to the AF PHB group of the original > service > classes remain an important consideration and should be preserved > during aggregation. This treatment aggregate should maintain > the AF > PHB group marking of the original packet. For example, AF3x > marked > packets should remain AF3x marked within this treatment aggregate. > Traffic bearing these DSCPs is carried in a common queue or class > with a PHB as described in RFC 2597 [10]. In effect, appropriate > target rate thresholds have been applied at the edge, dividing > traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 > (excess). The service should be engineered so that AFn1 marked > packet flows have sufficient bandwidth in the network to provide > high > assurance of delivery. Since the traffic is elastic and responds > dynamically to packet loss, Active Queue Management [9] should be > used primarily to reduce the forwarding rate to the minimum > assured > rate at congestion points. The probability of loss of AFn1 > traffic > must not exceed the probability of loss of AFn2 traffic, which in > turn must not exceed the probability of loss of AFn3 traffic. > > If RED [9] is used as an AQM algorithm, the min-threshold > specifies > a > target queue depth for each of AFn1, AFn2, AFn3, and the max- > threshold specifies the queue depth above which all traffic with > such > a DSCP is dropped or ECN marked. Thus, in this Treatment > Aggregate, > the following inequalities should hold in queue configurations: > > o min-threshold AFn3 < max-threshold AFn3 > > o max-threshold AFn3 <= min-threshold AFn2 > > o min-threshold AFn2 < max-threshold AFn2 > > o max-threshold AFn2 <= min-threshold AFn1 > > o min-threshold AFn1 < max-threshold AFn1 > > o max-threshold AFn1 <= memory assigned to the queue > > Note: This configuration tends to drop AFn3 traffic before AFn2 > and > AFn2 before AFn1. Many other AQM algorithms exist and are used; > they > should be configured to achieve a similar result. > > [BD] This particular set of configuration rules seems reasonable but > many other reasonable possibilities also exist. The existence of > other valid options should be made clear. > > 4.1.4. Elastic Treatment Aggregate > > The Elastic Treatment Aggregate aggregates all remaining elastic > traffic. The premise of such a service is that there is no > intrinsic > SLA differentiation of traffic, but that AQM [9] or ECN flagging > [13] > is appropriate for such traffic. > > This treatment aggregate may include the following service classes > > > > Chan, et al. Expires April 23, 2007 > [Page 10] > Internet-Draft Document October > 2006 > > > from the Diffserv Service Classes [5], in addition to other > locally > defined classes: Standard, Low Priority Data. > > The DSCPs of the original service classes remain an important > consideration and should be preserved during aggregation. Traffic > bearing these DSCPs is carried in a common queue or class with > a PHB > as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM > thresholds for Elastic traffic MAY be separately set, so that Low > Priority Data traffic is dropped before Standard traffic, but this > is > not a requirement. > > > 5. Using MPLS for Treatment Aggregates > > RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS > Support of > DiffServ [8] provide a very good background on this topic. This > document provides an example of using the E-LSP, EXP Inferred PHB > Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS > Support of DiffServ [8] for realizing the Treatment Aggregates. > > When Treatment Aggregates are represented in MPLS using EXP > Inferred > PSC LSP, we recommend the following usage of the MPLS EXP field > for > Treatment Aggregates. > > [BD] I'm not sure the TSVWG wants to publish a document that > "recommends" a particular mapping of PHBs to MPLS EXP values. It seems > to be that, like many other parts of this document, it would be better > to say "here is one way of doing things; many other valid approaches > exist" > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 > [Page 11] > Internet-Draft Document October > 2006 > > > ------------------------------------------- > |Treatment || MPLS || DSCP | DSCP | > |Aggregate || EXP || name | value | > |==========++======++=========|=============| > | Network || 110 || CS6 | 110000 | > | Control || || | | > |==========++======++=========|=============| > | Real || 100 || EF | 101110 | > | Time || ||---------|-------------| > | || || CS5 | 101000 | > | || ||---------|-------------| > | || ||AF41,AF42|100010,100100| > | || || AF43 | 100110 | > | || ||---------|-------------| > | || || CS4 | 100000 | > | || ||---------|-------------| > | || || CS3 | 011000 | > |==========++======++=========|=============| > | Assured || 010* || CS2 | 010000 | > | Elastic || || AF31 | 011010 | > | || || AF21 | 010010 | > | || || AF11 | 001010 | > | ||------||---------|-------------| > | || 011* || AF32 | 011100 | > | || || AF22 | 010100 | > | || || AF12 | 001100 | > | || || AF33 | 011110 | > | || || AF23 | 010110 | > | || || AF13 | 001110 | > |==========++======++=========|=============| > | Elastic || 000* || Default | 000000 | > | || || (CS0) | | > | ||------||---------|-------------| > | || 001* || CS1 | 001000 | > ------------------------------------------- > > Figure 3: Treatment Aggregate and MPLS EXP Field Usage > > Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, > the > usage of 010 or 011 (000 or 001) as EXP field value depends on the > drop probability. Packets in the LSP with EXP field of 011 (001) > have a higher probability of being dropped than packets with an > EXP > field of 010 (000). > > The above table indicates the recommended usage of EXP fields for > Treatment Aggregates. Because many deployments of MPLS are on > a per > domain basis, each domain has total control of its EXP usage and > each > domain may use a different EXP field allocation for the domain's > > > > Chan, et al. Expires April 23, 2007 > [Page 12] > Internet-Draft Document October > 2006 > > > supported Treatment Aggregates. > > 5.1. Network Control Treatment Aggregate with E-LSP > > The usage of E-LSP for Network Control Treatment Aggregate > needs to > adhere to the recommendations indicated in section 4.1.1 of this > document and section 3.2 of "Diffserv Service Classes" [5]. > Reinforcing these recommendations, there should be no drop > precedence > associated with the MPLS PSC used for Network Control Treatment > Aggregate because dropping of Network Control Treatment Aggregate > traffic should be prevented. > > 5.2. Real Time Treatment Aggregate with E-LSP > > In addition to the recommendations provided in section 4.1.2 of > this > document and in member service classes' sections of "Diffserv > Service > Classes" [5], we want to indicate that Real Time Treatment > Aggregate > traffic should not be dropped, as some of the applications whose > traffic is carried in the Real Time Treatment Aggregate do not > react > well to dropped packets. As indicated in section 4.1.2 of this > document, admission control should be performed on each Service > Class > contributing to the Real Time Treatment Aggregate to prevent > packet > loss due to insufficient resources allocated to Real Time > Treatment > Aggregate. Further, admission control and policing may also be > applied on the sum of all traffic aggregated into this treatment > aggregate. > > 5.3. Assured Elastic Treatment Aggregate with E-LSP > > EXP field markings of 010 and 011 are used for the Assured Elastic > Treatment Aggregate. The two encodings are used to provide two > levels of drop precedence indications, with 010 encoded traffic > having a lower probability of being dropped than 011 encoded > traffic. > This provides for the mapping of CS2, AF31, AF21, and AF11 into > EXP > 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. > > 5.4. Elastic Treatment Aggregate with E-LSP > > EXP field markings of 000 and 001 are used for the Elastic > Treatment > Aggregate. The two encodings are used to provide two levels of > drop > precedence indications, with 000 encoded traffic having a lower > probability of being dropped than 001 encoded traffic. This > provides > for the mapping of Default/CS0 into 000; and CS1 into 001. Notice > that with this mapping, during congestion, CS1 marked traffic > may be > starved. > > > > > > > Chan, et al. Expires April 23, 2007 > [Page 13] > Internet-Draft Document October > 2006 > > > 5.5. Treatment Aggregates and L-LSP > > Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC > per > LSP, the support of each Treatment Aggregate is on a per LSP > basis. > This document does not further specify any additional > recommendation > (beyond what has been indicated in section 4 of this document) for > Treatment Aggregate to L-LSP mapping, leaving this to each > individual > MPLS domain administrations. > > > 6. Treatment Aggregates and Inter-Provider Relationships > > When Treatment Aggregates are used at provider boundaries, we > recommend that the Inter-Provider Relationship be based on > Diffserv > Service Classes [5]. This allows the admission control into each > Treatment Aggregate of a provider domain to be based on the > admission > control of traffic into the supported Service Classes, as > indicated > by the discussion in section 4 of this document. > > If the Inter-Provider Relationship needs to be based on Treatment > Aggregates specified by this document, then the exact Treatment > Aggregate content and representation must be agreed to by the > peering > providers. > > > 7. Security Considerations > > This document discusses the policy of using Differentiated > Services > and its service classes. If implemented as described, it should > require that the network do nothing that the network has not > already > allowed. If that is the case, no new security issues should arise > from the use of such a policy. > > It is possible for the policy to be applied incorrectly, or for a > wrong policy to be applied in the network for the defined > aggregation. In that case, a policy issue exists that the network > must detect, assess, and deal with. This is a known security > issue > in any network dependent on policy-directed behavior. > > A well known flaw appears when bandwidth is reserved or enabled > for > a > service (for example, voice transport) and another service or an > attacking traffic stream uses it. This possibility is inherent in > DiffServ technology, which depends on appropriate packet markings. > When bandwidth reservation or a priority queuing system is used > in a > vulnerable network, the use of authentication and flow > admission is > recommended. To the best of the authors' knowledge, there is no > known technical way to respond to or act upon a data stream > that has > been admitted for service but that it is not intended for > > > > Chan, et al. Expires April 23, 2007 > [Page 14] > Internet-Draft Document October > 2006 > > > authenticated use. > > > 8. IANA Considerations > > This document does not request any IANA considerations. > > > 9. Acknowledgements > > This document has benefited from discussions with numerous people, > especially Shane Amante, Brian Carpenter, and Dave McDysan. It > has > also benefited from detailed reviews by David Black and Marvin > Krym. > > > 10. References > > 10.1. Normative References > > [1] Postel, J., "Internet Protocol", STD 5, RFC 791, > September 1981. > > [2] Bradner, S., "The Internet Standards Process -- Revision 3", > BCP 9, RFC 2026, October 1996. > > [3] Bradner, S., "Key words for use in RFCs to Indicate > Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [4] Nichols, K., Blake, S., Baker, F., and D. Black, > "Definition of > the Differentiated Services Field (DS Field) in the IPv4 and > IPv6 Headers", RFC 2474, December 1998. > > [5] Babiarz, J., Chan, K., and F. Baker, "Configuration > Guidelines > for DiffServ Service Classes", RFC 4594, August 2006. > > [6] Braden, B., Clark, D., and S. Shenker, "Integrated > Services in > the Internet Architecture: an Overview", RFC 1633, June > 1994. > > [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, > October 2000. > > [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, > P., > Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol > Label Switching (MPLS) Support of Differentiated Services", > RFC 3270, May 2002. > > [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, > S., > Estrin, D., Floyd, S., Jacobson, V., Minshall, G., > Partridge, > > > > Chan, et al. Expires April 23, 2007 > [Page 15] > Internet-Draft Document October > 2006 > > > C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, > J., and L. Zhang, "Recommendations on Queue Management and > Congestion Avoidance in the Internet", RFC 2309, April 1998. > > [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, > "Assured > Forwarding PHB Group", RFC 2597, June 1999. > > [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, > J., > Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An > Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, > March 2002. > > [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., > Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. > Ramakrishnan, "Supplemental Information for the New > Definition > of the EF PHB (Expedited Forwarding Per-Hop Behavior)", > RFC 3247, March 2002. > > [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of > Explicit Congestion Notification (ECN) to IP", RFC 3168, > September 2001. > > 10.2. Informative References > > [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. > Diot, > "Analysis of Point-To-Point Packet Delay in an Operational > Network", INFOCOMM 2004, March 2004, > . > > [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on > 9/11", > March 2002, renesys-030502-NRC-911.pdf>. > > > Authors' Addresses > > Kwok Ho Chan > Nortel Networks > 600 Technology Park Drive > Billerica, MA 01821 > US > > Phone: +1-978-288-8175 > Fax: +1-978-288-8700 > Email: khchan@nortel.com > > > > > > > Chan, et al. Expires April 23, 2007 > [Page 16] > Internet-Draft Document October > 2006 > > > Jozef Z. Babiarz > Nortel Networks > 3500 Carling Avenue > Ottawa, Ont. K2H 8E9 > Canada > > Phone: +1-613-763-6098 > Fax: +1-613-768-2231 > Email: babiarz@nortel.com > > > Fred Baker > Cisco Systems > 1121 Via Del Rey > Santa Barbara, CA 93117 > US > > Phone: +1-408-526-4257 > Fax: +1-413-473-2403 > Email: fred@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 > [Page 17] > Internet-Draft Document October > 2006 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2006). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on > an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR > IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to > pertain to the implementation or use of the technology > described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention > any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). > > > > > > Chan, et al. Expires April 23, 2007 > [Page 18] From tsvwg-bounces@ietf.org Thu Jan 11 23:45:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5EHt-00022e-Sv; Thu, 11 Jan 2007 23:45:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5EHs-00021P-9I for tsvwg@ietf.org; Thu, 11 Jan 2007 23:45:08 -0500 Received: from mailipbo.ntcif.telstra.com.au ([202.12.233.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5EHm-0008JM-8Z for tsvwg@ietf.org; Thu, 11 Jan 2007 23:45:08 -0500 Received: from webi.ntcif.telstra.com.au (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbo.ntcif.telstra.com.au with ESMTP; 12 Jan 2007 15:44:55 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 4841DFF81; Fri, 12 Jan 2007 15:44:55 +1100 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id B640F41E85; Fri, 12 Jan 2007 15:44:54 +1100 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 15:44:53 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: Fri, 12 Jan 2007 15:41:58 +1100 Message-ID: <651B5C0033306A45BC11E409451A60C502D5B89C@WSMSG2103V.srv.dir.telstra.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Thread-Index: Acc1/Wy8jxk81oFNTFqxxWR+8fqRsQAAOq7A From: "Dickinson, Fil" To: "Fred Baker" X-OriginalArrivalTime: 12 Jan 2007 04:44:53.0963 (UTC) FILETIME=[670701B0:01C73604] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e09a9838b5d5fc403683e84b112cba8 Cc: tsvwg , Magnus Westerlund X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Fred, Although I work at Telstra, I do not represent Telstra. My opinion is that of an engineer in the ISP community. Yes, I am very supportive of the direction this draft is heading. I think that it will provide much needed guidance, clarity and a recognised standards reference from which to operate, whilst still allowing the flexibility of each domain to implement what is applicable to its business. -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Friday, 12 January 2007 2:55 PM To: Dickinson, Fil Cc: Bruce Davie; tsvwg; Magnus Westerlund Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr I'll ask you the same question I just asked Dave. Given that we =20 update to reflect Bruce's comments, do you think this draft is going =20 in a direction that is beneficial to Telstra? It sounds like "yes", =20 but I'd like to hear the statement made. On Jan 12, 2007, at 12:31 AM, Dickinson, Fil wrote: > Hi Bruce. > I may be misinterpeting your last point but I do not agree with it. > I think we do need a "recommendation" on an approach to diffserv class > aggregation. I agree that it should not be "to the effect that =20 > there is > only one valid way to run a Diffserv network", but see a need for a > defined recommended approach. > I think this is necessary so that service providers can refer to a > documented approach by a recognised standards body when designing =20 > their > own networks, agreeing interprovider implementations with peers and > dealing with inter-vendor interpretations of diffserv class =20 > aggregation. > > -----Original Message----- > From: Bruce Davie [mailto:bdavie@cisco.com] > Sent: Friday, 12 January 2007 9:33 AM > To: tsvwg > Cc: Magnus Westerlund > Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-=20 > aggr > > I too send comments that never made it to the archive. > > Here they are again. > > Bruce > > From: bdavie@cisco.com > Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr > Date: December 21, 2006 11:20:33 AM EST > To: magnus.westerlund@ericsson.com > Cc: tsvwg@ietf.org > > As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- > aggr-01.txt > > My line by line comments are below, prefaced by [BD] > > My top level comments are as follows: > > 1. The main contribution of this draft can be summarized very > briefly: you can aggregate different classes of traffic into bigger > classes that get the same treatment as long as that treatment is good > enough to meet the needs of the most stringent class. > > 2. A second contribution is to observe that if you do aggregate, it > would be nice to preserve markings such that de-aggregation can be > performed later. > > 3. Beyond that, the document makes a lot of specific recommendations > about precisely how you should aggregate in both IP and MPLS networks. > My concern with this aspect of the document is that there are > essentially an infinite number of valid ways to aggregate traffic. For > example, one of the most popular is to give all traffic in the core of > an over-provisioned network the same treatment - so- called "best > effort" treatment, but actually it is a treatment that is so good that > even the most stringent class of traffic gets adequate service. This > approach to aggregation goes unmentioned in the document, as does the > fact that many other options are valid. > > At a minimum, this document should be revised to make it clear that it > is describing ONE possible approach out of many more that are =20 > possible. > Since it is being progressed by the TSVWG, statements that begin "we > recommend..." should probably be rewritten to be of the form "A =20 > possible > option is..." A great deal of effort went into writing the DiffServ > standards in such a way that operators and vendors would not be overly > constrained. A set of recommendations from the TSVWG, even in an > informational RFC, to the effect that there is only one valid way =20 > to run > a Diffserv network, does not seem like something we want to produce. > > Bruce > -------- > > > > TSVWG K. =20 > Chan > Internet-Draft J. =20 > Babiarz > Intended status: Informational Nortel =20 > Networks > Expires: April 23, 2007 F. =20 > Baker > Cisco > Systems > October 20, > 2006 > > > Aggregation of DiffServ Service Classes > draft-ietf-tsvwg-diffserv-class-aggr-01 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents =20 > at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on April 23, 2007. > > Copyright Notice > > Copyright (C) The Internet Society (2006). > > Abstract > > In the core of a high capacity network, service differentiation is > still needed to support applications' utilization of the network. > Applications with similar traffic characteristics and performance > requirements are mapped into diffserv service classes based on =20 > end- > to-end behavior requirements of the applications as indicated by > Diffserv Service Classes [5]. However, some network segments =20 > may be > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 1] > Internet-Draft Document October =20 > 2006 > > > configured in such a way that a single forwarding treatment may > satisfy the traffic characteristics and performance =20 > requirements of > two or more service classes. In these cases, it may be =20 > desirable to > aggregate two or more Diffserv Service Classes [5] into a single > forwarding treatment. This document provides guidelines for the > aggregation of Diffserv Service Classes [5] into forwarding > treatments. > > > Table of Contents > > 1. > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Requirements > Notation . . . . . . . . . . . . . . . . . . 4 > 2. > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Overview of Service Class > Aggregation . . . . . . . . . . . . 5 > 4. Service Classes to Treatment Aggregate Mapping . . . . . . . . > 6 > 4.1. Mapping Service Classes into Four Treatment Aggregates . . > 6 > 4.1.1. Network Control Treatment Aggregate . . . . . . . . . > 8 > 4.1.2. Real Time Treatment > Aggregate . . . . . . . . . . . . 9 > 4.1.3. Assured Elastic Treatment Aggregate . . . . . . . . . > 9 > 4.1.4. Elastic Treatment > Aggregate . . . . . . . . . . . . . 10 > 5. Using MPLS for Treatment > Aggregates . . . . . . . . . . . . . 11 > 5.1. Network Control Treatment Aggregate with E- =20 > LSP . . . . . . > 13 > 5.2. Real Time Treatment Aggregate with E- =20 > LSP . . . . . . . . . > 13 > 5.3. Assured Elastic Treatment Aggregate with E- =20 > LSP . . . . . . > 13 > 5.4. Elastic Treatment Aggregate with E- =20 > LSP . . . . . . . . . . > 13 > 5.5. Treatment Aggregates and L- =20 > LSP . . . . . . . . . . . . . . > 14 > 6. Treatment Aggregates and Inter-Provider Relationships . . . . > 14 > 7. Security > Considerations . . . . . . . . . . . . . . . . . . . 14 > 8. IANA > Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 9. > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 > 10. > References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 10.1. Normative > References . . . . . . . . . . . . . . . . . . . 15 > 10.2. Informative > References . . . . . . . . . . . . . . . . . . 16 > Authors' > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 > Intellectual Property and Copyright Statements . . . . . . . . . . > 18 > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 2] > Internet-Draft Document October =20 > 2006 > > > 1. Introduction > > In the core of a high capacity network, it is common for the =20 > network > to be engineered in such a way that a major link, switch, or =20 > router > can fail and the result will be a routed network that still meets > ambient SLAs. The implication of this is that there is sufficient > capacity on any given link such that all SLAs sold can be > simultaneously supported at their respective maximum rates, and =20 > that > this remains true after re-routing (either IP re-routing or MPLS > protection-mode switching) has occurred. > > Over-provisioning is generally considered to meet the requirements > of > all traffic without further QoS treatment, and in the general case > that is true in high capacity backbones. However, as the =20 > process of > network convergence continues, and with the increasing speed of =20 > the > access networks, certain services still have issues. Delay, =20 > jitter, > and occasional loss are perfectly acceptable for elastic > applications. However, sub-second surges that occur in the best- > designed of networks [14] affect real-time applications. =20 > Moreover, > DOS loads, worms, and network disruptions such as that of 11 > September 2001 affect routing [15]. Our objective is to prevent > disruption to routing (which in turn affects all services), and > jitter-sensitive services that may be revenue-bearing. > > [BD] It took me a long time to understand the above sentence. It could > be read to mean that an objective of the draft is to prevent jitter > sensitive services, which is probably not the intent. > Also, I think the comment about preventing disruption to routing =20 > relates > to the desire to protect network control traffic from loss, so perhaps > you should say that (since there are lots of ways that routing may get > disrupted that are outside the scope of this draft). > > > The document "Diffserv Service Classes" [5] defines the basic > diffserv classes from the points of view of the application > requiring > specific end-to-end behaviors from the network. The service =20 > classes > are differentiated based on the traffic-payload's tolerance to > packet > loss, delay, and delay variation (jitter). Different degrees of > these criterions form the foundation for supporting the needs of > > [BD] criterions -> criteria, or even better "Different values of these > metrics form..." > > real-time and elastic traffic. The "Diffserv Service Classes" [5] > document also provides recommendations for the treatment method of > these service classes. But, at some network segments of the =20 > end-to- > end path, the number of levels of network treatment =20 > differentiation > may be less than the number of service classes that the network > segment needs to support. In such a situation, that network =20 > segment > may use the same treatment to support more than one service class. > In this document we provide guidelines on how multiple service > classes may be aggregated into a forwarding treatment aggregate. > Note that in a given domain, we may recommend that the supported > service classes be aggregated into forwarding treatment =20 > aggregates; > however, this does not mean all service classes need to be =20 > supported > and hence not all forwarding treatment aggregates need to be > supported. Which service classes and which forwarding treatment > aggregates are supported by a domain is up to the domain > administration and may be influenced by business reasons. > > In this document, we've provided: > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 3] > Internet-Draft Document October =20 > 2006 > > > o definitions for terminology we use in this document, > > o requirements for performing this aggregation, > > o an example of performing this aggregation over MPLS using E-=20 > LSP. > > The treatment aggregate recommendations are designed to aggregate > the > service classes [5] in such a manner as to protect real-time =20 > traffic > and routing, on the assumption that real-time sessions are =20 > protected > from each other by admission at the edge. > > An example of aggregation over MPLS networks using E-LSP, EXP > Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to > realize the treatment aggregates is provided. Note that the MPLS > E-LSP is just an example; this document does not exclude the =20 > use of > other methods. > > 1.1. Requirements Notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =20 > NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =20 > this > document are to be interpreted as described in RFC 2119 [3]. > > > 2. Terminology > > This document assumes the reader is familiar with the terms =20 > used in > differentiated services. This document provides the =20 > definitions for > new terms introduced by this document and referencing information > for > existing none differentiated services terms defined in existing > RFCs. > > For new terms introduced by this document, we provide the =20 > definition > here: > > o Treatment Aggregate. This term is used here to indicate the > aggregate of DiffServ service classes. This is different from > Behavior Aggregate and Traffic Aggregate because Treatment > Aggregate is only concerned with the treatment of the =20 > aggregated > traffic. It does not concern itself with how the aggregated > traffic is marked, and hence does not put a restriction on the > aggregated traffic having a single diffserv codepoint that =20 > have a > single PHB. > > For terms from existing RFCs, we provide the reference to the > appropriate section of the relevant RFC that contain the =20 > definition: > > o Real-Time and Elastic Applications and their traffic. Section > 3.1 > of RFC 1633 [6]. > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 4] > Internet-Draft Document October =20 > 2006 > > > o Diffserv Service Class. Section 1.3 of > draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. > > o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label > Switched > Path (LSP). Section 1.2 of RFC 3270 [8]. > > o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) =20 > Label > Switched Path (LSP). Section 1.3 of RFC 3270 [8]. > > > 3. Overview of Service Class Aggregation > > In diffserv domains where less granular traffic treatment > differentiation is provided, aggregation of the different service > classes [5] may be required. > > These aggregations have the following requirements: > > [BD] I don't understand where these requirements come from. > > 1. The end-to-end network performance characteristic required by > the > application must be supported. This performance =20 > characteristic > is represented by the use of Diffserv Service Classes [5]. > > 2. The treatment aggregate must exhibit the strictest requirement > of > its member service classes. > > 3. The treatment aggregate should only contain member service > classes with similar traffic characteristic and performance > requirements. > > [BD] Why? Isn't it OK to aggregate wildly different service classes =20 > and > give them all treatment that is a good as the most stringent > requirements of any class? > > 4. The notion of the individual end-to-end service classes =20 > must not > be destroyed when aggregation is performed. Each domain along > the end-to-end path may perform aggregation differently, based > on > the original end-to-end service classes. We recommend an easy > way to accomplish this by not altering the DSCP used to =20 > indicate > the end-to-end service class. But some administrative domains > may require the use of their own marking; when this is needed, > the original end-to-end service class indication must be > restored > upon exiting such administrative domains. > > [BD] You seem to have strayed away from stating requirements when you > start recommending how to mark the DSCP. I *think* that what you are > trying to say is that the information about which service class =20 > belongs > to should not be lost during aggregation; such information loss would > occur, for example, if several different classes were remarked to a > common DSCP value. > > 5. Each treatment aggregate has limited resources, hence traffic > conditioning and/or admission control must be performed for =20 > each > service class aggregated into the treatment aggregate. > > [BD] Where is this requirement from? Are you saying that it's not > possible to aggregate traffic with also performing admission =20 > control or > traffic conditioning? Many SPs would disagree. > > with the following suggestions: > > 1. The treatment aggregate and assigned resources may consider > historical traffic patterns and the variability of these > patterns. For example, a point-point service (e.g., =20 > pseudowire) > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 5] > Internet-Draft Document October =20 > 2006 > > > may have a very predictable pattern, while a multipoint =20 > service > (e.g., VPLS) may have a much less predictable pattern. =20 > Even the > traffic patterns within the Internet may vary widely. > > 2. In addition to Diffserv, other controls are available to > influence the traffic level offered to a particular traffic > aggregate. These include adjustment of routing metrics, usage > of > MPLS-based traffic engineering techniques. > > > 4. Service Classes to Treatment Aggregate Mapping > > The service class and DSCP selection in "Diffserv Service Classes" > [5] has been defined to allow, in many instances, mapping of =20 > two or > possibly more service classes into a single forwarding treatment > aggregate. Notice that there is a relationship/trade-off between > link speed, queue depth, delay, and jitter. > > [BD] The preceding sentence should also mention link utilization. > > The degree of > aggregation and hence the number of treatment aggregates will =20 > depend > on whether the speed of the links and scheduler behavior, being =20 > used > to implement the aggregation, can minimize the affects of mixing > traffic with different packet sizes and transmit rates on queue > depth. And their impacts on loss, delay, and jitter. A general > rule-of-thumb is that higher link speeds allow for more =20 > aggregation/ > smaller number of treatment aggregates. > > [BD] That rule of thumb seems to be incorrect if a link is run at 100% > utilization. A more useful rule of thumb might take utilization into > accoutn. > > > 4.1. Mapping Service Classes into Four Treatment Aggregates > > [BD] It is probably worth mentioning that this is just an example and > that more or fewer treatment aggregates may be required. > > This section explains one way of performing this aggregation by > using > four treatment aggregates. The use of four treatment aggregates > assumes that the resources allocated to each treatment =20 > aggregate is > sufficient to honor the required behavior of each service class =20 > [5] > in each of the four treatment aggregates. We use the performance > requirement (tolerance to loss, delay, and jitter) from the > application/end-user as a guide on how to map the service classes > into treatment aggregates. We have also used Section 3.1 of RFC > 1633 > [6] to provide us with guidance on the definition of Real-Time and > Elastic applications. An overview of the mapping between service > classes and the four treatment aggregates is provided by Figure 1, > with the mapping being based on performance requirements. In =20 > Figure > 1, the right side columns of "Service Class", "Tolerance to Loss/ > Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. > > It is recommended that certain service classes be mapped into > specific treatment aggregates. But this does not mean that all =20 > the > service classes recommended for that treatment aggregate need =20 > to be > supported. Hence, for a given domain, a treatment aggregate may > contain only a subset of the service classes recommended in this > document, they being the service classes supported by that domain. > A > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 6] > Internet-Draft Document October =20 > 2006 > > > domain's treatment of non-supported service classes should be =20 > based > on the domain's local policy. This local policy may be influenced > by > its agreement with its customers. Such treatment may use the > Elastic > Treatment Aggregate, dropping the packets, or some other > arrangements. > > =20 > --------------------------------------------------------------------- > |Treatment | Tolerance to ||Service Class | Tolerance =20 > to | > |Aggregate | Loss |Delay |Jitter|| | Loss |Delay |=20 > Jitter| > = |=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 > +=3D=3D=3D=3D=3D=3D| > | Network | Low | Low | Yes || Network | Low | Low | =20 > Yes | > | Control | | | || Control | | =20 > | | > = |=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 > +=3D=3D=3D=3D=3D=3D| > | Real | Very | Very | Very || Telephony | VLow | VLow | =20 > VLow | > | Time | Low | Low | Low ||---------------+------+------=20 > +------| > | | | | || Signaling | Low | Low | =20 > Yes | > | | | | ||---------------+------+------=20 > +------| > | | | | || Multimedia |Low - | Very | =20 > Low | > | | | | || Conferencing |Medium| Low =20 > | | > | | | | ||---------------+------+------=20 > +------| > | | | | || Real-time | Low | Very | =20 > Low | > | | | | || Interactive | | Low =20 > | | > | | | | ||---------------+------+------=20 > +------| > | | | | || Broadcast | Very |Medium| =20 > Low | > | | | | || Video | Low | =20 > | | > = |=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 > +=3D=3D=3D=3D=3D=3D| > | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| =20 > Yes | > | Elastic | |Medium| || Streaming |Medium| =20 > | | > | | | | ||---------------+------+------=20 > +------| > | | | | || Low Latency | Low |Low - | =20 > Yes | > | | | | || Data | |=20 > Medium| | > | | | | ||---------------+------+------=20 > +------| > | | | | || OAM | Low |Medium| =20 > Yes | > | | | | ||---------------+------+------=20 > +------| > | | | | ||High Throughput| Low |Medium| =20 > Yes | > | | | | || Data | |- =20 > High| | > = |=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 > +=3D=3D=3D=3D=3D=3D| > | Elastic | Not Specified || Standard | Not =20 > Specified | > | | | | ||---------------+------+------=20 > +------| > | | | | || Low Priority | High | High | =20 > Yes | > | | | | || Data | | =20 > | | > =20 > --------------------------------------------------------------------- > > Figure 1: Treatment Aggregate and Service Class Performance > Requirements > > As we are recommending to preserve the notion of the individual =20 > end- > to-end service classes, we also recommend that the original DSCP > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 7] > Internet-Draft Document October =20 > 2006 > > > field marking not be changed when treatment aggregates are used. > Instead, classifiers that select packets based on the contents of > the > DSCP field should be used to direct packets from the member =20 > DiffServ > Service Classes into the queue that handles each of the treatment > aggregates, without remarking the DSCP field of the packets. > This is > summarized in Figure 2, which shows the behavior each Treatment > Aggregate should have, and the DSCP field marking of the packets > that > should be classified into each of the treatment aggregates. > > ------------------------------------------------------------ > |Treatment |Treatment || DSCP | > |Aggregate |Aggregate || | > | |Behavior || | > = |=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| > | Network | CS || CS6 | > | Control |(RFC 2474)|| | > = |=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| > | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | > | Time |(RFC 3246)|| | > = |=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| > | Assured | AF || CS2, AF31, AF21, AF11 | > | Elastic |(RFC 2597)||-------------------------------------| > | | || AF32, AF22, AF12 | > | | ||-------------------------------------| > | | || AF33, AF23, AF13 | > = |=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| > | Elastic | Default || Default, (CS0) | > | |(RFC 2474)||-------------------------------------| > | | || CS1 | > ------------------------------------------------------------ > > Figure 2: Treatment Aggregate Behavior > > 4.1.1. Network Control Treatment Aggregate > > The Network Control Treatment Aggregate aggregates all service > classes that are functionally necessary for the survival of a > network > during a DOS attack or other high traffic load interval. The =20 > theory > is that whatever else is true, the network must protect itself. > This > includes the traffic that "Diffserv Service Classes" [5] > characterizes as being included in the Network Control Service > Class. > > The DSCPs of the original service class remain an important > consideration and should be preserved during aggregation. > Traffic in > the Network Control treatment aggregate should be carried in a > common > queue or class with a PHB as described in RFC 2474 [4] section > 4.2.2.2. This treatment aggregate should have a lower probability > of > packet loss, bearing a relatively deep target mean queue depth =20 > (min- > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 8] > Internet-Draft Document October =20 > 2006 > > > threshold if RED is being used). > > 4.1.2. Real Time Treatment Aggregate > > The Real Time Treatment Aggregate aggregates all real-time > (inelastic) service classes. The theory is that real-time traffic > is > admitted under some model and controlled by a SLA managed at the > edge > of the network prior to aggregation. As such, there is a > predictable > and enforceable upper bound on the traffic that can enter such a > queue, and to provide predictable variation in delay it must be > protected from bursts of elastic traffic. The predictability of > traffic level may be based upon admission control for a well known > community of interest (e.g., a point-point service) and/or based > upon > historical measurements. > > This treatment aggregate may include the following service classes > from the Diffserv Service Classes [5], in addition to other =20 > locally > defined classes: Telephony, Signaling, Multimedia Conferencing, > Real- > time Interactive, Broadcast Video. > > Traffic in each service class that is going to be aggregated into > the > treatment aggregate should be conditioned prior to =20 > aggregation. It > is recommended that per service class admission control procedures > be > used followed by per service class policing so that any individual > service class does not generate more than what it is allowed. > Furthermore, additional admission control and policing may be used > on > the sum of all service classes aggregated. > > The DSCPs of the original service classes remain an important > consideration and should be preserved during aggregation. Traffic > bearing these DSCPs is carried in a common queue or class with =20 > a PHB > as described in RFC 3246 [11] and RFC 3247 [12]. > > 4.1.3. Assured Elastic Treatment Aggregate > > The Assured Elastic Treatment Aggregate aggregates all elastic > traffic that uses the Assured Forwarding model as described in RFC > 2597 [10]. The premise of such a service is that a SLA is > negotiated > which includes a "committed rate" and the ability to exceed that > rate > (and perhaps a second "excess rate") in exchange for a higher > probability of loss using AQM [9] or ECN flagging [13] for the > portion of traffic deemed to be in excess. > > This treatment aggregate may include the following service classes > from the Diffserv Service Classes [5], in addition to other =20 > locally > defined classes: Multimedia Streaming, Low Latency Data, OAM, High > Throughput Data. > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 9] > Internet-Draft Document October =20 > 2006 > > > The DSCP values belonging to the AF PHB group of the original > service > classes remain an important consideration and should be preserved > during aggregation. This treatment aggregate should maintain =20 > the AF > PHB group marking of the original packet. For example, AF3x =20 > marked > packets should remain AF3x marked within this treatment aggregate. > Traffic bearing these DSCPs is carried in a common queue or class > with a PHB as described in RFC 2597 [10]. In effect, appropriate > target rate thresholds have been applied at the edge, dividing > traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 > (excess). The service should be engineered so that AFn1 marked > packet flows have sufficient bandwidth in the network to provide > high > assurance of delivery. Since the traffic is elastic and responds > dynamically to packet loss, Active Queue Management [9] should be > used primarily to reduce the forwarding rate to the minimum =20 > assured > rate at congestion points. The probability of loss of AFn1 =20 > traffic > must not exceed the probability of loss of AFn2 traffic, which in > turn must not exceed the probability of loss of AFn3 traffic. > > If RED [9] is used as an AQM algorithm, the min-threshold =20 > specifies > a > target queue depth for each of AFn1, AFn2, AFn3, and the max- > threshold specifies the queue depth above which all traffic with > such > a DSCP is dropped or ECN marked. Thus, in this Treatment =20 > Aggregate, > the following inequalities should hold in queue configurations: > > o min-threshold AFn3 < max-threshold AFn3 > > o max-threshold AFn3 <=3D min-threshold AFn2 > > o min-threshold AFn2 < max-threshold AFn2 > > o max-threshold AFn2 <=3D min-threshold AFn1 > > o min-threshold AFn1 < max-threshold AFn1 > > o max-threshold AFn1 <=3D memory assigned to the queue > > Note: This configuration tends to drop AFn3 traffic before AFn2 =20 > and > AFn2 before AFn1. Many other AQM algorithms exist and are used; > they > should be configured to achieve a similar result. > > [BD] This particular set of configuration rules seems reasonable but > many other reasonable possibilities also exist. The existence of > other valid options should be made clear. > > 4.1.4. Elastic Treatment Aggregate > > The Elastic Treatment Aggregate aggregates all remaining elastic > traffic. The premise of such a service is that there is no > intrinsic > SLA differentiation of traffic, but that AQM [9] or ECN flagging > [13] > is appropriate for such traffic. > > This treatment aggregate may include the following service classes > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 10] > Internet-Draft Document October =20 > 2006 > > > from the Diffserv Service Classes [5], in addition to other =20 > locally > defined classes: Standard, Low Priority Data. > > The DSCPs of the original service classes remain an important > consideration and should be preserved during aggregation. Traffic > bearing these DSCPs is carried in a common queue or class with =20 > a PHB > as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM > thresholds for Elastic traffic MAY be separately set, so that Low > Priority Data traffic is dropped before Standard traffic, but this > is > not a requirement. > > > 5. Using MPLS for Treatment Aggregates > > RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS =20 > Support of > DiffServ [8] provide a very good background on this topic. This > document provides an example of using the E-LSP, EXP Inferred PHB > Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS > Support of DiffServ [8] for realizing the Treatment Aggregates. > > When Treatment Aggregates are represented in MPLS using EXP =20 > Inferred > PSC LSP, we recommend the following usage of the MPLS EXP field =20 > for > Treatment Aggregates. > > [BD] I'm not sure the TSVWG wants to publish a document that > "recommends" a particular mapping of PHBs to MPLS EXP values. It seems > to be that, like many other parts of this document, it would be better > to say "here is one way of doing things; many other valid approaches > exist" > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 11] > Internet-Draft Document October =20 > 2006 > > > ------------------------------------------- > |Treatment || MPLS || DSCP | DSCP | > |Aggregate || EXP || name | value | > = |=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| > | Network || 110 || CS6 | 110000 | > | Control || || | | > = |=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| > | Real || 100 || EF | 101110 | > | Time || ||---------|-------------| > | || || CS5 | 101000 | > | || ||---------|-------------| > | || ||AF41,AF42|100010,100100| > | || || AF43 | 100110 | > | || ||---------|-------------| > | || || CS4 | 100000 | > | || ||---------|-------------| > | || || CS3 | 011000 | > = |=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| > | Assured || 010* || CS2 | 010000 | > | Elastic || || AF31 | 011010 | > | || || AF21 | 010010 | > | || || AF11 | 001010 | > | ||------||---------|-------------| > | || 011* || AF32 | 011100 | > | || || AF22 | 010100 | > | || || AF12 | 001100 | > | || || AF33 | 011110 | > | || || AF23 | 010110 | > | || || AF13 | 001110 | > = |=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| > | Elastic || 000* || Default | 000000 | > | || || (CS0) | | > | ||------||---------|-------------| > | || 001* || CS1 | 001000 | > ------------------------------------------- > > Figure 3: Treatment Aggregate and MPLS EXP Field Usage > > Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, =20 > the > usage of 010 or 011 (000 or 001) as EXP field value depends on the > drop probability. Packets in the LSP with EXP field of 011 (001) > have a higher probability of being dropped than packets with an =20 > EXP > field of 010 (000). > > The above table indicates the recommended usage of EXP fields for > Treatment Aggregates. Because many deployments of MPLS are on =20 > a per > domain basis, each domain has total control of its EXP usage and > each > domain may use a different EXP field allocation for the domain's > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 12] > Internet-Draft Document October =20 > 2006 > > > supported Treatment Aggregates. > > 5.1. Network Control Treatment Aggregate with E-LSP > > The usage of E-LSP for Network Control Treatment Aggregate =20 > needs to > adhere to the recommendations indicated in section 4.1.1 of this > document and section 3.2 of "Diffserv Service Classes" [5]. > Reinforcing these recommendations, there should be no drop > precedence > associated with the MPLS PSC used for Network Control Treatment > Aggregate because dropping of Network Control Treatment Aggregate > traffic should be prevented. > > 5.2. Real Time Treatment Aggregate with E-LSP > > In addition to the recommendations provided in section 4.1.2 of =20 > this > document and in member service classes' sections of "Diffserv > Service > Classes" [5], we want to indicate that Real Time Treatment =20 > Aggregate > traffic should not be dropped, as some of the applications whose > traffic is carried in the Real Time Treatment Aggregate do not =20 > react > well to dropped packets. As indicated in section 4.1.2 of this > document, admission control should be performed on each Service > Class > contributing to the Real Time Treatment Aggregate to prevent =20 > packet > loss due to insufficient resources allocated to Real Time =20 > Treatment > Aggregate. Further, admission control and policing may also be > applied on the sum of all traffic aggregated into this treatment > aggregate. > > 5.3. Assured Elastic Treatment Aggregate with E-LSP > > EXP field markings of 010 and 011 are used for the Assured Elastic > Treatment Aggregate. The two encodings are used to provide two > levels of drop precedence indications, with 010 encoded traffic > having a lower probability of being dropped than 011 encoded > traffic. > This provides for the mapping of CS2, AF31, AF21, and AF11 into =20 > EXP > 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. > > 5.4. Elastic Treatment Aggregate with E-LSP > > EXP field markings of 000 and 001 are used for the Elastic =20 > Treatment > Aggregate. The two encodings are used to provide two levels of =20 > drop > precedence indications, with 000 encoded traffic having a lower > probability of being dropped than 001 encoded traffic. This > provides > for the mapping of Default/CS0 into 000; and CS1 into 001. Notice > that with this mapping, during congestion, CS1 marked traffic =20 > may be > starved. > > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 13] > Internet-Draft Document October =20 > 2006 > > > 5.5. Treatment Aggregates and L-LSP > > Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC > per > LSP, the support of each Treatment Aggregate is on a per LSP =20 > basis. > This document does not further specify any additional =20 > recommendation > (beyond what has been indicated in section 4 of this document) for > Treatment Aggregate to L-LSP mapping, leaving this to each > individual > MPLS domain administrations. > > > 6. Treatment Aggregates and Inter-Provider Relationships > > When Treatment Aggregates are used at provider boundaries, we > recommend that the Inter-Provider Relationship be based on =20 > Diffserv > Service Classes [5]. This allows the admission control into each > Treatment Aggregate of a provider domain to be based on the > admission > control of traffic into the supported Service Classes, as =20 > indicated > by the discussion in section 4 of this document. > > If the Inter-Provider Relationship needs to be based on Treatment > Aggregates specified by this document, then the exact Treatment > Aggregate content and representation must be agreed to by the > peering > providers. > > > 7. Security Considerations > > This document discusses the policy of using Differentiated =20 > Services > and its service classes. If implemented as described, it should > require that the network do nothing that the network has not =20 > already > allowed. If that is the case, no new security issues should arise > from the use of such a policy. > > It is possible for the policy to be applied incorrectly, or for a > wrong policy to be applied in the network for the defined > aggregation. In that case, a policy issue exists that the network > must detect, assess, and deal with. This is a known security =20 > issue > in any network dependent on policy-directed behavior. > > A well known flaw appears when bandwidth is reserved or enabled =20 > for > a > service (for example, voice transport) and another service or an > attacking traffic stream uses it. This possibility is inherent in > DiffServ technology, which depends on appropriate packet markings. > When bandwidth reservation or a priority queuing system is used =20 > in a > vulnerable network, the use of authentication and flow =20 > admission is > recommended. To the best of the authors' knowledge, there is no > known technical way to respond to or act upon a data stream =20 > that has > been admitted for service but that it is not intended for > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 14] > Internet-Draft Document October =20 > 2006 > > > authenticated use. > > > 8. IANA Considerations > > This document does not request any IANA considerations. > > > 9. Acknowledgements > > This document has benefited from discussions with numerous people, > especially Shane Amante, Brian Carpenter, and Dave McDysan. It =20 > has > also benefited from detailed reviews by David Black and Marvin =20 > Krym. > > > 10. References > > 10.1. Normative References > > [1] Postel, J., "Internet Protocol", STD 5, RFC 791, > September 1981. > > [2] Bradner, S., "The Internet Standards Process -- Revision 3", > BCP 9, RFC 2026, October 1996. > > [3] Bradner, S., "Key words for use in RFCs to Indicate > Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [4] Nichols, K., Blake, S., Baker, F., and D. Black, > "Definition of > the Differentiated Services Field (DS Field) in the IPv4 and > IPv6 Headers", RFC 2474, December 1998. > > [5] Babiarz, J., Chan, K., and F. Baker, "Configuration =20 > Guidelines > for DiffServ Service Classes", RFC 4594, August 2006. > > [6] Braden, B., Clark, D., and S. Shenker, "Integrated =20 > Services in > the Internet Architecture: an Overview", RFC 1633, June =20 > 1994. > > [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, > October 2000. > > [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, =20 > P., > Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol > Label Switching (MPLS) Support of Differentiated Services", > RFC 3270, May 2002. > > [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, =20 > S., > Estrin, D., Floyd, S., Jacobson, V., Minshall, G., =20 > Partridge, > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 15] > Internet-Draft Document October =20 > 2006 > > > C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, > J., and L. Zhang, "Recommendations on Queue Management and > Congestion Avoidance in the Internet", RFC 2309, April 1998. > > [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, > "Assured > Forwarding PHB Group", RFC 2597, June 1999. > > [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, =20 > J., > Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An > Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, > March 2002. > > [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., > Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. > Ramakrishnan, "Supplemental Information for the New =20 > Definition > of the EF PHB (Expedited Forwarding Per-Hop Behavior)", > RFC 3247, March 2002. > > [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of > Explicit Congestion Notification (ECN) to IP", RFC 3168, > September 2001. > > 10.2. Informative References > > [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. =20 > Diot, > "Analysis of Point-To-Point Packet Delay in an Operational > Network", INFOCOMM 2004, March 2004, > . > > [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on > 9/11", > March 2002, renesys-030502-NRC-911.pdf>. > > > Authors' Addresses > > Kwok Ho Chan > Nortel Networks > 600 Technology Park Drive > Billerica, MA 01821 > US > > Phone: +1-978-288-8175 > Fax: +1-978-288-8700 > Email: khchan@nortel.com > > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 16] > Internet-Draft Document October =20 > 2006 > > > Jozef Z. Babiarz > Nortel Networks > 3500 Carling Avenue > Ottawa, Ont. K2H 8E9 > Canada > > Phone: +1-613-763-6098 > Fax: +1-613-768-2231 > Email: babiarz@nortel.com > > > Fred Baker > Cisco Systems > 1121 Via Del Rey > Santa Barbara, CA 93117 > US > > Phone: +1-408-526-4257 > Fax: +1-413-473-2403 > Email: fred@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 17] > Internet-Draft Document October =20 > 2006 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2006). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on > an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR =20 > IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to > pertain to the implementation or use of the technology =20 > described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention =20 > any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). > > > > > > Chan, et al. Expires April 23, 2007 =20 > [Page 18] From tsvwg-bounces@ietf.org Fri Jan 12 00:06:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ec9-0005Zz-QZ; Fri, 12 Jan 2007 00:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ec8-0005ZQ-K2 for tsvwg@ietf.org; Fri, 12 Jan 2007 00:06:04 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ec3-0003tn-H8 for tsvwg@ietf.org; Fri, 12 Jan 2007 00:06:04 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2007 21:05:59 -0800 X-IronPort-AV: i="4.13,176,1167638400"; d="scan'208"; a="355877761:sNHT131675244" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0C55w6f019194; Thu, 11 Jan 2007 21:05:58 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0C55wUw006980; Thu, 11 Jan 2007 21:05:58 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 21:05:56 -0800 Received: from [192.168.116.180] ([10.21.96.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 21:05:54 -0800 In-Reply-To: <651B5C0033306A45BC11E409451A60C502D5B89C@WSMSG2103V.srv.dir.telstra.com> References: <651B5C0033306A45BC11E409451A60C502D5B89C@WSMSG2103V.srv.dir.telstra.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr Date: Fri, 12 Jan 2007 00:05:51 -0500 To: "Dickinson, Fil" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jan 2007 05:05:54.0771 (UTC) FILETIME=[56870A30:01C73607] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=54295; t=1168578358; x=1169442358; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[Tsvwg]=20FW=3A=20Review=20of=20=20draft-ietf-tsvwg-d iffserv-class-aggr |Sender:=20; bh=B1M3RG1XUIHzw/Xx5IUNu2VWSiaEWQgqqBq1Y8/0DJo=; b=Ao0i/KvkVtpbhgeYJGgqOoV2dZM2QysMcjGjpuk9BAEDhUpFDASRkdMEy6zrt8Z+TRCb5zJO En7/evJzbbIcsse/qxA2cpEoMKOUk2mQztY5U/Zb871ejXCTarsLM2Os; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e2a224a4445e6ba88c508264e796c05d Cc: tsvwg , Magnus Westerlund X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org That is pretty much the position we all are in - none of us speak for our companies in a corporate sense, but we know what our companies need. I'm here to meet the needs, as no doubt you are as well. Thanks. On Jan 11, 2007, at 11:41 PM, Dickinson, Fil wrote: > Hi Fred, > Although I work at Telstra, I do not represent Telstra. My opinion is > that of an engineer in the ISP community. > > Yes, I am very supportive of the direction this draft is heading. I > think that it will provide much needed guidance, clarity and a > recognised standards reference from which to operate, whilst still > allowing the flexibility of each domain to implement what is > applicable > to its business. > > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, 12 January 2007 2:55 PM > To: Dickinson, Fil > Cc: Bruce Davie; tsvwg; Magnus Westerlund > Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class- > aggr > > I'll ask you the same question I just asked Dave. Given that we > update to reflect Bruce's comments, do you think this draft is going > in a direction that is beneficial to Telstra? It sounds like "yes", > but I'd like to hear the statement made. > > On Jan 12, 2007, at 12:31 AM, Dickinson, Fil wrote: > >> Hi Bruce. >> I may be misinterpeting your last point but I do not agree with it. >> I think we do need a "recommendation" on an approach to diffserv >> class >> aggregation. I agree that it should not be "to the effect that >> there is >> only one valid way to run a Diffserv network", but see a need for a >> defined recommended approach. >> I think this is necessary so that service providers can refer to a >> documented approach by a recognised standards body when designing >> their >> own networks, agreeing interprovider implementations with peers and >> dealing with inter-vendor interpretations of diffserv class >> aggregation. >> >> -----Original Message----- >> From: Bruce Davie [mailto:bdavie@cisco.com] >> Sent: Friday, 12 January 2007 9:33 AM >> To: tsvwg >> Cc: Magnus Westerlund >> Subject: Re: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class- >> aggr >> >> I too send comments that never made it to the archive. >> >> Here they are again. >> >> Bruce >> >> From: bdavie@cisco.com >> Subject: Review of draft-ietf-tsvwg-diffserv-class-aggr >> Date: December 21, 2006 11:20:33 AM EST >> To: magnus.westerlund@ericsson.com >> Cc: tsvwg@ietf.org >> >> As Magnus requested, I have reviewed draft-ietf-tsvwg-diffserv-class- >> aggr-01.txt >> >> My line by line comments are below, prefaced by [BD] >> >> My top level comments are as follows: >> >> 1. The main contribution of this draft can be summarized very >> briefly: you can aggregate different classes of traffic into bigger >> classes that get the same treatment as long as that treatment is good >> enough to meet the needs of the most stringent class. >> >> 2. A second contribution is to observe that if you do aggregate, it >> would be nice to preserve markings such that de-aggregation can be >> performed later. >> >> 3. Beyond that, the document makes a lot of specific recommendations >> about precisely how you should aggregate in both IP and MPLS >> networks. >> My concern with this aspect of the document is that there are >> essentially an infinite number of valid ways to aggregate traffic. >> For >> example, one of the most popular is to give all traffic in the >> core of >> an over-provisioned network the same treatment - so- called "best >> effort" treatment, but actually it is a treatment that is so good >> that >> even the most stringent class of traffic gets adequate service. This >> approach to aggregation goes unmentioned in the document, as does the >> fact that many other options are valid. >> >> At a minimum, this document should be revised to make it clear >> that it >> is describing ONE possible approach out of many more that are >> possible. >> Since it is being progressed by the TSVWG, statements that begin "we >> recommend..." should probably be rewritten to be of the form "A >> possible >> option is..." A great deal of effort went into writing the DiffServ >> standards in such a way that operators and vendors would not be >> overly >> constrained. A set of recommendations from the TSVWG, even in an >> informational RFC, to the effect that there is only one valid way >> to run >> a Diffserv network, does not seem like something we want to produce. >> >> Bruce >> -------- >> >> >> >> TSVWG K. >> Chan >> Internet-Draft J. >> Babiarz >> Intended status: Informational Nortel >> Networks >> Expires: April 23, 2007 F. >> Baker >> Cisco >> Systems >> October 20, >> 2006 >> >> >> Aggregation of DiffServ Service Classes >> draft-ietf-tsvwg-diffserv-class-aggr-01 >> >> Status of this Memo >> >> By submitting this Internet-Draft, each author represents that >> any >> applicable patent or other IPR claims of which he or she is aware >> have been or will be disclosed, and any of which he or she >> becomes >> aware will be disclosed, in accordance with Section 6 of BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months >> and may be updated, replaced, or obsoleted by other documents >> at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on April 23, 2007. >> >> Copyright Notice >> >> Copyright (C) The Internet Society (2006). >> >> Abstract >> >> In the core of a high capacity network, service >> differentiation is >> still needed to support applications' utilization of the network. >> Applications with similar traffic characteristics and performance >> requirements are mapped into diffserv service classes based on >> end- >> to-end behavior requirements of the applications as indicated by >> Diffserv Service Classes [5]. However, some network segments >> may be >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 1] >> Internet-Draft Document October >> 2006 >> >> >> configured in such a way that a single forwarding treatment may >> satisfy the traffic characteristics and performance >> requirements of >> two or more service classes. In these cases, it may be >> desirable to >> aggregate two or more Diffserv Service Classes [5] into a single >> forwarding treatment. This document provides guidelines for the >> aggregation of Diffserv Service Classes [5] into forwarding >> treatments. >> >> >> Table of Contents >> >> 1. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.1. Requirements >> Notation . . . . . . . . . . . . . . . . . . 4 >> 2. >> Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3. Overview of Service Class >> Aggregation . . . . . . . . . . . . 5 >> 4. Service Classes to Treatment Aggregate >> Mapping . . . . . . . . >> 6 >> 4.1. Mapping Service Classes into Four Treatment >> Aggregates . . >> 6 >> 4.1.1. Network Control Treatment >> Aggregate . . . . . . . . . >> 8 >> 4.1.2. Real Time Treatment >> Aggregate . . . . . . . . . . . . 9 >> 4.1.3. Assured Elastic Treatment >> Aggregate . . . . . . . . . >> 9 >> 4.1.4. Elastic Treatment >> Aggregate . . . . . . . . . . . . . 10 >> 5. Using MPLS for Treatment >> Aggregates . . . . . . . . . . . . . 11 >> 5.1. Network Control Treatment Aggregate with E- >> LSP . . . . . . >> 13 >> 5.2. Real Time Treatment Aggregate with E- >> LSP . . . . . . . . . >> 13 >> 5.3. Assured Elastic Treatment Aggregate with E- >> LSP . . . . . . >> 13 >> 5.4. Elastic Treatment Aggregate with E- >> LSP . . . . . . . . . . >> 13 >> 5.5. Treatment Aggregates and L- >> LSP . . . . . . . . . . . . . . >> 14 >> 6. Treatment Aggregates and Inter-Provider >> Relationships . . . . >> 14 >> 7. Security >> Considerations . . . . . . . . . . . . . . . . . . . 14 >> 8. IANA >> Considerations . . . . . . . . . . . . . . . . . . . . . 15 >> 9. >> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 >> 10. >> References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 >> 10.1. Normative >> References . . . . . . . . . . . . . . . . . . . 15 >> 10.2. Informative >> References . . . . . . . . . . . . . . . . . . 16 >> Authors' >> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >> Intellectual Property and Copyright >> Statements . . . . . . . . . . >> 18 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 2] >> Internet-Draft Document October >> 2006 >> >> >> 1. Introduction >> >> In the core of a high capacity network, it is common for the >> network >> to be engineered in such a way that a major link, switch, or >> router >> can fail and the result will be a routed network that still meets >> ambient SLAs. The implication of this is that there is >> sufficient >> capacity on any given link such that all SLAs sold can be >> simultaneously supported at their respective maximum rates, and >> that >> this remains true after re-routing (either IP re-routing or MPLS >> protection-mode switching) has occurred. >> >> Over-provisioning is generally considered to meet the >> requirements >> of >> all traffic without further QoS treatment, and in the general >> case >> that is true in high capacity backbones. However, as the >> process of >> network convergence continues, and with the increasing speed of >> the >> access networks, certain services still have issues. Delay, >> jitter, >> and occasional loss are perfectly acceptable for elastic >> applications. However, sub-second surges that occur in the best- >> designed of networks [14] affect real-time applications. >> Moreover, >> DOS loads, worms, and network disruptions such as that of 11 >> September 2001 affect routing [15]. Our objective is to prevent >> disruption to routing (which in turn affects all services), and >> jitter-sensitive services that may be revenue-bearing. >> >> [BD] It took me a long time to understand the above sentence. It >> could >> be read to mean that an objective of the draft is to prevent jitter >> sensitive services, which is probably not the intent. >> Also, I think the comment about preventing disruption to routing >> relates >> to the desire to protect network control traffic from loss, so >> perhaps >> you should say that (since there are lots of ways that routing may >> get >> disrupted that are outside the scope of this draft). >> >> >> The document "Diffserv Service Classes" [5] defines the basic >> diffserv classes from the points of view of the application >> requiring >> specific end-to-end behaviors from the network. The service >> classes >> are differentiated based on the traffic-payload's tolerance to >> packet >> loss, delay, and delay variation (jitter). Different degrees of >> these criterions form the foundation for supporting the needs of >> >> [BD] criterions -> criteria, or even better "Different values of >> these >> metrics form..." >> >> real-time and elastic traffic. The "Diffserv Service >> Classes" [5] >> document also provides recommendations for the treatment >> method of >> these service classes. But, at some network segments of the >> end-to- >> end path, the number of levels of network treatment >> differentiation >> may be less than the number of service classes that the network >> segment needs to support. In such a situation, that network >> segment >> may use the same treatment to support more than one service >> class. >> In this document we provide guidelines on how multiple service >> classes may be aggregated into a forwarding treatment aggregate. >> Note that in a given domain, we may recommend that the supported >> service classes be aggregated into forwarding treatment >> aggregates; >> however, this does not mean all service classes need to be >> supported >> and hence not all forwarding treatment aggregates need to be >> supported. Which service classes and which forwarding treatment >> aggregates are supported by a domain is up to the domain >> administration and may be influenced by business reasons. >> >> In this document, we've provided: >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 3] >> Internet-Draft Document October >> 2006 >> >> >> o definitions for terminology we use in this document, >> >> o requirements for performing this aggregation, >> >> o an example of performing this aggregation over MPLS using E- >> LSP. >> >> The treatment aggregate recommendations are designed to aggregate >> the >> service classes [5] in such a manner as to protect real-time >> traffic >> and routing, on the assumption that real-time sessions are >> protected >> from each other by admission at the edge. >> >> An example of aggregation over MPLS networks using E-LSP, EXP >> Inferred PHB Scheduling Class (PSC) Label Switched Path (LSP), to >> realize the treatment aggregates is provided. Note that the MPLS >> E-LSP is just an example; this document does not exclude the >> use of >> other methods. >> >> 1.1. Requirements Notation >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> document are to be interpreted as described in RFC 2119 [3]. >> >> >> 2. Terminology >> >> This document assumes the reader is familiar with the terms >> used in >> differentiated services. This document provides the >> definitions for >> new terms introduced by this document and referencing information >> for >> existing none differentiated services terms defined in existing >> RFCs. >> >> For new terms introduced by this document, we provide the >> definition >> here: >> >> o Treatment Aggregate. This term is used here to indicate the >> aggregate of DiffServ service classes. This is different from >> Behavior Aggregate and Traffic Aggregate because Treatment >> Aggregate is only concerned with the treatment of the >> aggregated >> traffic. It does not concern itself with how the aggregated >> traffic is marked, and hence does not put a restriction on the >> aggregated traffic having a single diffserv codepoint that >> have a >> single PHB. >> >> For terms from existing RFCs, we provide the reference to the >> appropriate section of the relevant RFC that contain the >> definition: >> >> o Real-Time and Elastic Applications and their traffic. Section >> 3.1 >> of RFC 1633 [6]. >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 4] >> Internet-Draft Document October >> 2006 >> >> >> o Diffserv Service Class. Section 1.3 of >> draft-ietf-tsvwg-diffserv-service-classes-02.txt [5]. >> >> o MPLS E-LSP, EXP Inferred PHB Scheduling Class (PSC) Label >> Switched >> Path (LSP). Section 1.2 of RFC 3270 [8]. >> >> o MPLS L-LSP, Label Only Inferred PHB Scheduling Class (PSC) >> Label >> Switched Path (LSP). Section 1.3 of RFC 3270 [8]. >> >> >> 3. Overview of Service Class Aggregation >> >> In diffserv domains where less granular traffic treatment >> differentiation is provided, aggregation of the different service >> classes [5] may be required. >> >> These aggregations have the following requirements: >> >> [BD] I don't understand where these requirements come from. >> >> 1. The end-to-end network performance characteristic required by >> the >> application must be supported. This performance >> characteristic >> is represented by the use of Diffserv Service Classes [5]. >> >> 2. The treatment aggregate must exhibit the strictest >> requirement >> of >> its member service classes. >> >> 3. The treatment aggregate should only contain member service >> classes with similar traffic characteristic and performance >> requirements. >> >> [BD] Why? Isn't it OK to aggregate wildly different service classes >> and >> give them all treatment that is a good as the most stringent >> requirements of any class? >> >> 4. The notion of the individual end-to-end service classes >> must not >> be destroyed when aggregation is performed. Each domain >> along >> the end-to-end path may perform aggregation differently, >> based >> on >> the original end-to-end service classes. We recommend an >> easy >> way to accomplish this by not altering the DSCP used to >> indicate >> the end-to-end service class. But some administrative >> domains >> may require the use of their own marking; when this is >> needed, >> the original end-to-end service class indication must be >> restored >> upon exiting such administrative domains. >> >> [BD] You seem to have strayed away from stating requirements when you >> start recommending how to mark the DSCP. I *think* that what you are >> trying to say is that the information about which service class >> belongs >> to should not be lost during aggregation; such information loss would >> occur, for example, if several different classes were remarked to a >> common DSCP value. >> >> 5. Each treatment aggregate has limited resources, hence traffic >> conditioning and/or admission control must be performed for >> each >> service class aggregated into the treatment aggregate. >> >> [BD] Where is this requirement from? Are you saying that it's not >> possible to aggregate traffic with also performing admission >> control or >> traffic conditioning? Many SPs would disagree. >> >> with the following suggestions: >> >> 1. The treatment aggregate and assigned resources may consider >> historical traffic patterns and the variability of these >> patterns. For example, a point-point service (e.g., >> pseudowire) >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 5] >> Internet-Draft Document October >> 2006 >> >> >> may have a very predictable pattern, while a multipoint >> service >> (e.g., VPLS) may have a much less predictable pattern. >> Even the >> traffic patterns within the Internet may vary widely. >> >> 2. In addition to Diffserv, other controls are available to >> influence the traffic level offered to a particular traffic >> aggregate. These include adjustment of routing metrics, >> usage >> of >> MPLS-based traffic engineering techniques. >> >> >> 4. Service Classes to Treatment Aggregate Mapping >> >> The service class and DSCP selection in "Diffserv Service >> Classes" >> [5] has been defined to allow, in many instances, mapping of >> two or >> possibly more service classes into a single forwarding treatment >> aggregate. Notice that there is a relationship/trade-off between >> link speed, queue depth, delay, and jitter. >> >> [BD] The preceding sentence should also mention link utilization. >> >> The degree of >> aggregation and hence the number of treatment aggregates will >> depend >> on whether the speed of the links and scheduler behavior, being >> used >> to implement the aggregation, can minimize the affects of mixing >> traffic with different packet sizes and transmit rates on queue >> depth. And their impacts on loss, delay, and jitter. A general >> rule-of-thumb is that higher link speeds allow for more >> aggregation/ >> smaller number of treatment aggregates. >> >> [BD] That rule of thumb seems to be incorrect if a link is run at >> 100% >> utilization. A more useful rule of thumb might take utilization into >> accoutn. >> >> >> 4.1. Mapping Service Classes into Four Treatment Aggregates >> >> [BD] It is probably worth mentioning that this is just an example and >> that more or fewer treatment aggregates may be required. >> >> This section explains one way of performing this aggregation by >> using >> four treatment aggregates. The use of four treatment aggregates >> assumes that the resources allocated to each treatment >> aggregate is >> sufficient to honor the required behavior of each service class >> [5] >> in each of the four treatment aggregates. We use the performance >> requirement (tolerance to loss, delay, and jitter) from the >> application/end-user as a guide on how to map the service classes >> into treatment aggregates. We have also used Section 3.1 of RFC >> 1633 >> [6] to provide us with guidance on the definition of Real-Time >> and >> Elastic applications. An overview of the mapping between service >> classes and the four treatment aggregates is provided by >> Figure 1, >> with the mapping being based on performance requirements. In >> Figure >> 1, the right side columns of "Service Class", "Tolerance to Loss/ >> Delay/Jitter" are from Figure 2 of Diffserv Service Classes [5]. >> >> It is recommended that certain service classes be mapped into >> specific treatment aggregates. But this does not mean that all >> the >> service classes recommended for that treatment aggregate need >> to be >> supported. Hence, for a given domain, a treatment aggregate may >> contain only a subset of the service classes recommended in this >> document, they being the service classes supported by that >> domain. >> A >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 6] >> Internet-Draft Document October >> 2006 >> >> >> domain's treatment of non-supported service classes should be >> based >> on the domain's local policy. This local policy may be >> influenced >> by >> its agreement with its customers. Such treatment may use the >> Elastic >> Treatment Aggregate, dropping the packets, or some other >> arrangements. >> >> >> --------------------------------------------------------------------- >> |Treatment | Tolerance to ||Service Class | Tolerance >> to | >> |Aggregate | Loss |Delay |Jitter|| | Loss |Delay | >> Jitter| >> |==========+======+======+======++===============+======+====== >> +======| >> | Network | Low | Low | Yes || Network | Low | Low | >> Yes | >> | Control | | | || Control | | >> | | >> |==========+======+======+======++===============+======+====== >> +======| >> | Real | Very | Very | Very || Telephony | VLow | VLow | >> VLow | >> | Time | Low | Low | Low ||---------------+------+------ >> +------| >> | | | | || Signaling | Low | Low | >> Yes | >> | | | | ||---------------+------+------ >> +------| >> | | | | || Multimedia |Low - | Very | >> Low | >> | | | | || Conferencing |Medium| Low >> | | >> | | | | ||---------------+------+------ >> +------| >> | | | | || Real-time | Low | Very | >> Low | >> | | | | || Interactive | | Low >> | | >> | | | | ||---------------+------+------ >> +------| >> | | | | || Broadcast | Very |Medium| >> Low | >> | | | | || Video | Low | >> | | >> |==========+======+======+======++===============+======+====== >> +======| >> | Assured | Low |Low - | Yes || Multimedia |Low - |Medium| >> Yes | >> | Elastic | |Medium| || Streaming |Medium| >> | | >> | | | | ||---------------+------+------ >> +------| >> | | | | || Low Latency | Low |Low - | >> Yes | >> | | | | || Data | | >> Medium| | >> | | | | ||---------------+------+------ >> +------| >> | | | | || OAM | Low |Medium| >> Yes | >> | | | | ||---------------+------+------ >> +------| >> | | | | ||High Throughput| Low |Medium| >> Yes | >> | | | | || Data | |- >> High| | >> |==========+======+======+======++===============+======+====== >> +======| >> | Elastic | Not Specified || Standard | Not >> Specified | >> | | | | ||---------------+------+------ >> +------| >> | | | | || Low Priority | High | High | >> Yes | >> | | | | || Data | | >> | | >> >> --------------------------------------------------------------------- >> >> Figure 1: Treatment Aggregate and Service Class Performance >> Requirements >> >> As we are recommending to preserve the notion of the individual >> end- >> to-end service classes, we also recommend that the original DSCP >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 7] >> Internet-Draft Document October >> 2006 >> >> >> field marking not be changed when treatment aggregates are used. >> Instead, classifiers that select packets based on the contents of >> the >> DSCP field should be used to direct packets from the member >> DiffServ >> Service Classes into the queue that handles each of the treatment >> aggregates, without remarking the DSCP field of the packets. >> This is >> summarized in Figure 2, which shows the behavior each Treatment >> Aggregate should have, and the DSCP field marking of the packets >> that >> should be classified into each of the treatment aggregates. >> >> ------------------------------------------------------------ >> |Treatment |Treatment || DSCP | >> |Aggregate |Aggregate || | >> | |Behavior || | >> |==========+==========++=====================================| >> | Network | CS || CS6 | >> | Control |(RFC 2474)|| | >> |==========+==========++=====================================| >> | Real | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | >> | Time |(RFC 3246)|| | >> |==========+==========++=====================================| >> | Assured | AF || CS2, AF31, AF21, AF11 | >> | Elastic |(RFC 2597)||-------------------------------------| >> | | || AF32, AF22, AF12 | >> | | ||-------------------------------------| >> | | || AF33, AF23, AF13 | >> |==========+==========++=====================================| >> | Elastic | Default || Default, (CS0) | >> | |(RFC 2474)||-------------------------------------| >> | | || CS1 | >> ------------------------------------------------------------ >> >> Figure 2: Treatment Aggregate Behavior >> >> 4.1.1. Network Control Treatment Aggregate >> >> The Network Control Treatment Aggregate aggregates all service >> classes that are functionally necessary for the survival of a >> network >> during a DOS attack or other high traffic load interval. The >> theory >> is that whatever else is true, the network must protect itself. >> This >> includes the traffic that "Diffserv Service Classes" [5] >> characterizes as being included in the Network Control Service >> Class. >> >> The DSCPs of the original service class remain an important >> consideration and should be preserved during aggregation. >> Traffic in >> the Network Control treatment aggregate should be carried in a >> common >> queue or class with a PHB as described in RFC 2474 [4] section >> 4.2.2.2. This treatment aggregate should have a lower >> probability >> of >> packet loss, bearing a relatively deep target mean queue depth >> (min- >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 8] >> Internet-Draft Document October >> 2006 >> >> >> threshold if RED is being used). >> >> 4.1.2. Real Time Treatment Aggregate >> >> The Real Time Treatment Aggregate aggregates all real-time >> (inelastic) service classes. The theory is that real-time >> traffic >> is >> admitted under some model and controlled by a SLA managed at the >> edge >> of the network prior to aggregation. As such, there is a >> predictable >> and enforceable upper bound on the traffic that can enter such a >> queue, and to provide predictable variation in delay it must be >> protected from bursts of elastic traffic. The predictability of >> traffic level may be based upon admission control for a well >> known >> community of interest (e.g., a point-point service) and/or based >> upon >> historical measurements. >> >> This treatment aggregate may include the following service >> classes >> from the Diffserv Service Classes [5], in addition to other >> locally >> defined classes: Telephony, Signaling, Multimedia Conferencing, >> Real- >> time Interactive, Broadcast Video. >> >> Traffic in each service class that is going to be aggregated into >> the >> treatment aggregate should be conditioned prior to >> aggregation. It >> is recommended that per service class admission control >> procedures >> be >> used followed by per service class policing so that any >> individual >> service class does not generate more than what it is allowed. >> Furthermore, additional admission control and policing may be >> used >> on >> the sum of all service classes aggregated. >> >> The DSCPs of the original service classes remain an important >> consideration and should be preserved during aggregation. >> Traffic >> bearing these DSCPs is carried in a common queue or class with >> a PHB >> as described in RFC 3246 [11] and RFC 3247 [12]. >> >> 4.1.3. Assured Elastic Treatment Aggregate >> >> The Assured Elastic Treatment Aggregate aggregates all elastic >> traffic that uses the Assured Forwarding model as described in >> RFC >> 2597 [10]. The premise of such a service is that a SLA is >> negotiated >> which includes a "committed rate" and the ability to exceed that >> rate >> (and perhaps a second "excess rate") in exchange for a higher >> probability of loss using AQM [9] or ECN flagging [13] for the >> portion of traffic deemed to be in excess. >> >> This treatment aggregate may include the following service >> classes >> from the Diffserv Service Classes [5], in addition to other >> locally >> defined classes: Multimedia Streaming, Low Latency Data, OAM, >> High >> Throughput Data. >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 9] >> Internet-Draft Document October >> 2006 >> >> >> The DSCP values belonging to the AF PHB group of the original >> service >> classes remain an important consideration and should be preserved >> during aggregation. This treatment aggregate should maintain >> the AF >> PHB group marking of the original packet. For example, AF3x >> marked >> packets should remain AF3x marked within this treatment >> aggregate. >> Traffic bearing these DSCPs is carried in a common queue or class >> with a PHB as described in RFC 2597 [10]. In effect, appropriate >> target rate thresholds have been applied at the edge, dividing >> traffic into AFn1 (committed, for any value of n), AFn2, and AFn3 >> (excess). The service should be engineered so that AFn1 marked >> packet flows have sufficient bandwidth in the network to provide >> high >> assurance of delivery. Since the traffic is elastic and responds >> dynamically to packet loss, Active Queue Management [9] should be >> used primarily to reduce the forwarding rate to the minimum >> assured >> rate at congestion points. The probability of loss of AFn1 >> traffic >> must not exceed the probability of loss of AFn2 traffic, which in >> turn must not exceed the probability of loss of AFn3 traffic. >> >> If RED [9] is used as an AQM algorithm, the min-threshold >> specifies >> a >> target queue depth for each of AFn1, AFn2, AFn3, and the max- >> threshold specifies the queue depth above which all traffic with >> such >> a DSCP is dropped or ECN marked. Thus, in this Treatment >> Aggregate, >> the following inequalities should hold in queue configurations: >> >> o min-threshold AFn3 < max-threshold AFn3 >> >> o max-threshold AFn3 <= min-threshold AFn2 >> >> o min-threshold AFn2 < max-threshold AFn2 >> >> o max-threshold AFn2 <= min-threshold AFn1 >> >> o min-threshold AFn1 < max-threshold AFn1 >> >> o max-threshold AFn1 <= memory assigned to the queue >> >> Note: This configuration tends to drop AFn3 traffic before AFn2 >> and >> AFn2 before AFn1. Many other AQM algorithms exist and are used; >> they >> should be configured to achieve a similar result. >> >> [BD] This particular set of configuration rules seems reasonable but >> many other reasonable possibilities also exist. The existence of >> other valid options should be made clear. >> >> 4.1.4. Elastic Treatment Aggregate >> >> The Elastic Treatment Aggregate aggregates all remaining elastic >> traffic. The premise of such a service is that there is no >> intrinsic >> SLA differentiation of traffic, but that AQM [9] or ECN flagging >> [13] >> is appropriate for such traffic. >> >> This treatment aggregate may include the following service >> classes >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 10] >> Internet-Draft Document October >> 2006 >> >> >> from the Diffserv Service Classes [5], in addition to other >> locally >> defined classes: Standard, Low Priority Data. >> >> The DSCPs of the original service classes remain an important >> consideration and should be preserved during aggregation. >> Traffic >> bearing these DSCPs is carried in a common queue or class with >> a PHB >> as described in RFC 2474 [4] section 4.1: A Default PHB. The AQM >> thresholds for Elastic traffic MAY be separately set, so that Low >> Priority Data traffic is dropped before Standard traffic, but >> this >> is >> not a requirement. >> >> >> 5. Using MPLS for Treatment Aggregates >> >> RFC 2983 on DiffServ and Tunnels [7] and RFC 3270 on MPLS >> Support of >> DiffServ [8] provide a very good background on this topic. This >> document provides an example of using the E-LSP, EXP Inferred PHB >> Scheduled Class (PSC) Label Switched Path (LSP), defined by MPLS >> Support of DiffServ [8] for realizing the Treatment Aggregates. >> >> When Treatment Aggregates are represented in MPLS using EXP >> Inferred >> PSC LSP, we recommend the following usage of the MPLS EXP field >> for >> Treatment Aggregates. >> >> [BD] I'm not sure the TSVWG wants to publish a document that >> "recommends" a particular mapping of PHBs to MPLS EXP values. It >> seems >> to be that, like many other parts of this document, it would be >> better >> to say "here is one way of doing things; many other valid approaches >> exist" >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 11] >> Internet-Draft Document October >> 2006 >> >> >> ------------------------------------------- >> |Treatment || MPLS || DSCP | DSCP | >> |Aggregate || EXP || name | value | >> |==========++======++=========|=============| >> | Network || 110 || CS6 | 110000 | >> | Control || || | | >> |==========++======++=========|=============| >> | Real || 100 || EF | 101110 | >> | Time || ||---------|-------------| >> | || || CS5 | 101000 | >> | || ||---------|-------------| >> | || ||AF41,AF42|100010,100100| >> | || || AF43 | 100110 | >> | || ||---------|-------------| >> | || || CS4 | 100000 | >> | || ||---------|-------------| >> | || || CS3 | 011000 | >> |==========++======++=========|=============| >> | Assured || 010* || CS2 | 010000 | >> | Elastic || || AF31 | 011010 | >> | || || AF21 | 010010 | >> | || || AF11 | 001010 | >> | ||------||---------|-------------| >> | || 011* || AF32 | 011100 | >> | || || AF22 | 010100 | >> | || || AF12 | 001100 | >> | || || AF33 | 011110 | >> | || || AF23 | 010110 | >> | || || AF13 | 001110 | >> |==========++======++=========|=============| >> | Elastic || 000* || Default | 000000 | >> | || || (CS0) | | >> | ||------||---------|-------------| >> | || 001* || CS1 | 001000 | >> ------------------------------------------- >> >> Figure 3: Treatment Aggregate and MPLS EXP Field Usage >> >> Notes *: For Assured Elastic (and Elastic) Treatment Aggregate, >> the >> usage of 010 or 011 (000 or 001) as EXP field value depends on >> the >> drop probability. Packets in the LSP with EXP field of 011 (001) >> have a higher probability of being dropped than packets with an >> EXP >> field of 010 (000). >> >> The above table indicates the recommended usage of EXP fields for >> Treatment Aggregates. Because many deployments of MPLS are on >> a per >> domain basis, each domain has total control of its EXP usage and >> each >> domain may use a different EXP field allocation for the domain's >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 12] >> Internet-Draft Document October >> 2006 >> >> >> supported Treatment Aggregates. >> >> 5.1. Network Control Treatment Aggregate with E-LSP >> >> The usage of E-LSP for Network Control Treatment Aggregate >> needs to >> adhere to the recommendations indicated in section 4.1.1 of this >> document and section 3.2 of "Diffserv Service Classes" [5]. >> Reinforcing these recommendations, there should be no drop >> precedence >> associated with the MPLS PSC used for Network Control Treatment >> Aggregate because dropping of Network Control Treatment Aggregate >> traffic should be prevented. >> >> 5.2. Real Time Treatment Aggregate with E-LSP >> >> In addition to the recommendations provided in section 4.1.2 of >> this >> document and in member service classes' sections of "Diffserv >> Service >> Classes" [5], we want to indicate that Real Time Treatment >> Aggregate >> traffic should not be dropped, as some of the applications whose >> traffic is carried in the Real Time Treatment Aggregate do not >> react >> well to dropped packets. As indicated in section 4.1.2 of this >> document, admission control should be performed on each Service >> Class >> contributing to the Real Time Treatment Aggregate to prevent >> packet >> loss due to insufficient resources allocated to Real Time >> Treatment >> Aggregate. Further, admission control and policing may also be >> applied on the sum of all traffic aggregated into this treatment >> aggregate. >> >> 5.3. Assured Elastic Treatment Aggregate with E-LSP >> >> EXP field markings of 010 and 011 are used for the Assured >> Elastic >> Treatment Aggregate. The two encodings are used to provide two >> levels of drop precedence indications, with 010 encoded traffic >> having a lower probability of being dropped than 011 encoded >> traffic. >> This provides for the mapping of CS2, AF31, AF21, and AF11 into >> EXP >> 010; and AF32, AF22, AF12 and AF33, AF23, AF13 into EXP 011. >> >> 5.4. Elastic Treatment Aggregate with E-LSP >> >> EXP field markings of 000 and 001 are used for the Elastic >> Treatment >> Aggregate. The two encodings are used to provide two levels of >> drop >> precedence indications, with 000 encoded traffic having a lower >> probability of being dropped than 001 encoded traffic. This >> provides >> for the mapping of Default/CS0 into 000; and CS1 into 001. >> Notice >> that with this mapping, during congestion, CS1 marked traffic >> may be >> starved. >> >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 13] >> Internet-Draft Document October >> 2006 >> >> >> 5.5. Treatment Aggregates and L-LSP >> >> Because L-LSP (Label Only Inferred PSC LSP) supports a single PSC >> per >> LSP, the support of each Treatment Aggregate is on a per LSP >> basis. >> This document does not further specify any additional >> recommendation >> (beyond what has been indicated in section 4 of this document) >> for >> Treatment Aggregate to L-LSP mapping, leaving this to each >> individual >> MPLS domain administrations. >> >> >> 6. Treatment Aggregates and Inter-Provider Relationships >> >> When Treatment Aggregates are used at provider boundaries, we >> recommend that the Inter-Provider Relationship be based on >> Diffserv >> Service Classes [5]. This allows the admission control into each >> Treatment Aggregate of a provider domain to be based on the >> admission >> control of traffic into the supported Service Classes, as >> indicated >> by the discussion in section 4 of this document. >> >> If the Inter-Provider Relationship needs to be based on Treatment >> Aggregates specified by this document, then the exact Treatment >> Aggregate content and representation must be agreed to by the >> peering >> providers. >> >> >> 7. Security Considerations >> >> This document discusses the policy of using Differentiated >> Services >> and its service classes. If implemented as described, it should >> require that the network do nothing that the network has not >> already >> allowed. If that is the case, no new security issues should >> arise >> from the use of such a policy. >> >> It is possible for the policy to be applied incorrectly, or for a >> wrong policy to be applied in the network for the defined >> aggregation. In that case, a policy issue exists that the >> network >> must detect, assess, and deal with. This is a known security >> issue >> in any network dependent on policy-directed behavior. >> >> A well known flaw appears when bandwidth is reserved or enabled >> for >> a >> service (for example, voice transport) and another service or an >> attacking traffic stream uses it. This possibility is >> inherent in >> DiffServ technology, which depends on appropriate packet >> markings. >> When bandwidth reservation or a priority queuing system is used >> in a >> vulnerable network, the use of authentication and flow >> admission is >> recommended. To the best of the authors' knowledge, there is no >> known technical way to respond to or act upon a data stream >> that has >> been admitted for service but that it is not intended for >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 14] >> Internet-Draft Document October >> 2006 >> >> >> authenticated use. >> >> >> 8. IANA Considerations >> >> This document does not request any IANA considerations. >> >> >> 9. Acknowledgements >> >> This document has benefited from discussions with numerous >> people, >> especially Shane Amante, Brian Carpenter, and Dave McDysan. It >> has >> also benefited from detailed reviews by David Black and Marvin >> Krym. >> >> >> 10. References >> >> 10.1. Normative References >> >> [1] Postel, J., "Internet Protocol", STD 5, RFC 791, >> September 1981. >> >> [2] Bradner, S., "The Internet Standards Process -- Revision >> 3", >> BCP 9, RFC 2026, October 1996. >> >> [3] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement >> Levels", BCP 14, RFC 2119, March 1997. >> >> [4] Nichols, K., Blake, S., Baker, F., and D. Black, >> "Definition of >> the Differentiated Services Field (DS Field) in the IPv4 >> and >> IPv6 Headers", RFC 2474, December 1998. >> >> [5] Babiarz, J., Chan, K., and F. Baker, "Configuration >> Guidelines >> for DiffServ Service Classes", RFC 4594, August 2006. >> >> [6] Braden, B., Clark, D., and S. Shenker, "Integrated >> Services in >> the Internet Architecture: an Overview", RFC 1633, June >> 1994. >> >> [7] Black, D., "Differentiated Services and Tunnels", RFC 2983, >> October 2000. >> >> [8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, >> P., >> Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol >> Label Switching (MPLS) Support of Differentiated Services", >> RFC 3270, May 2002. >> >> [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, >> S., >> Estrin, D., Floyd, S., Jacobson, V., Minshall, G., >> Partridge, >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 15] >> Internet-Draft Document October >> 2006 >> >> >> C., Peterson, L., Ramakrishnan, K., Shenker, S., >> Wroclawski, >> J., and L. Zhang, "Recommendations on Queue Management and >> Congestion Avoidance in the Internet", RFC 2309, April >> 1998. >> >> [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, >> "Assured >> Forwarding PHB Group", RFC 2597, June 1999. >> >> [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, >> J., >> Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An >> Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, >> March 2002. >> >> [12] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., >> Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. >> Ramakrishnan, "Supplemental Information for the New >> Definition >> of the EF PHB (Expedited Forwarding Per-Hop Behavior)", >> RFC 3247, March 2002. >> >> [13] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of >> Explicit Congestion Notification (ECN) to IP", RFC 3168, >> September 2001. >> >> 10.2. Informative References >> >> [14] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. >> Diot, >> "Analysis of Point-To-Point Packet Delay in an Operational >> Network", INFOCOMM 2004, March 2004, >> . >> >> [15] Ogielski, A. and J. Cowie, "Internet Routing Behavior on >> 9/11", >> March 2002, > renesys-030502-NRC-911.pdf>. >> >> >> Authors' Addresses >> >> Kwok Ho Chan >> Nortel Networks >> 600 Technology Park Drive >> Billerica, MA 01821 >> US >> >> Phone: +1-978-288-8175 >> Fax: +1-978-288-8700 >> Email: khchan@nortel.com >> >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 16] >> Internet-Draft Document October >> 2006 >> >> >> Jozef Z. Babiarz >> Nortel Networks >> 3500 Carling Avenue >> Ottawa, Ont. K2H 8E9 >> Canada >> >> Phone: +1-613-763-6098 >> Fax: +1-613-768-2231 >> Email: babiarz@nortel.com >> >> >> Fred Baker >> Cisco Systems >> 1121 Via Del Rey >> Santa Barbara, CA 93117 >> US >> >> Phone: +1-408-526-4257 >> Fax: +1-413-473-2403 >> Email: fred@cisco.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 17] >> Internet-Draft Document October >> 2006 >> >> >> Full Copyright Statement >> >> Copyright (C) The Internet Society (2006). >> >> This document is subject to the rights, licenses and restrictions >> contained in BCP 78, and except as set forth therein, the authors >> retain all their rights. >> >> This document and the information contained herein are >> provided on >> an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >> REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE >> INTERNET >> ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR >> IMPLIED, >> INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE >> INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR >> PURPOSE. >> >> >> Intellectual Property >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be >> claimed >> to >> pertain to the implementation or use of the technology >> described in >> this document or the extent to which any license under such >> rights >> might or might not be available; nor does it represent that it >> has >> made any independent effort to identify any such rights. >> Information >> on the procedures with respect to rights in RFC documents can be >> found in BCP 78 and BCP 79. >> >> Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission for the >> use >> of >> such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR >> repository >> at >> http://www.ietf.org/ipr. >> >> The IETF invites any interested party to bring to its attention >> any >> copyrights, patents or patent applications, or other proprietary >> rights that may cover technology that may be required to >> implement >> this standard. Please address the information to the IETF at >> ietf-ipr@ietf.org. >> >> >> Acknowledgment >> >> Funding for the RFC Editor function is provided by the IETF >> Administrative Support Activity (IASA). >> >> >> >> >> >> Chan, et al. Expires April 23, 2007 >> [Page 18] From tsvwg-bounces@ietf.org Fri Jan 12 02:29:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Gql-0003YE-38; Fri, 12 Jan 2007 02:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Gqj-0003Vj-6P for tsvwg@ietf.org; Fri, 12 Jan 2007 02:29:17 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Gqg-0000zw-Nt for tsvwg@ietf.org; Fri, 12 Jan 2007 02:29:17 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0C7RGjr000332 for ; Fri, 12 Jan 2007 09:27:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:28:56 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:28:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jan 2007 09:28:53 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0252_01C7362C.134776E0" Message-ID: <213394AB6954BE4682E8B2A491034683485593@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: test - ignore Thread-Index: Acc2G09g5B7hMxMHSfyLPO4USgt2RA== From: To: X-OriginalArrivalTime: 12 Jan 2007 07:28:56.0217 (UTC) FILETIME=[5177C890:01C7361B] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112092745-01317BB0-220658CA/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Tsvwg] test - ignore X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0252_01C7362C.134776E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_0252_01C7362C.134776E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEyMDcyODUzWjAjBgkqhkiG 9w0BCQQxFgQUKhMhVlbH3Y5vbbxDSoOXQNgVCNswZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAMXKsA7wroeRV5n3/iQy1jj/rVeHMGKv06Vs7omZ FoEvV3MillyYno1bG3VcnItJhAWGMRrL56FT6IUhI3jgm9OQSH0owp5aB5fCWwK2LVERLSplwB94 nfG+BlFNaXxw4u1qw/8KK0ZhTeBEnmpWbNgBHWNgXTjidMsBlxIrmxrTo+nj+I7KF4+rVv5Rpfdu tOLHJQ/8K5bFhGtWaRdmweWFCoyeKpEQ99ALhusCEzvzfw6IBWkWZwjV90esZlTiXdXSmRZUmaAx PLn838KLa3cfEx/df8vnqZDqYZM6nmf2B5d/Mc/Dn6e88Yb/5O5uN68X0YvJqjrH6vQbq46RmCEA AAAAAAA= ------=_NextPart_000_0252_01C7362C.134776E0-- From tsvwg-bounces@ietf.org Fri Jan 12 02:35:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Gwy-0005bv-My; Fri, 12 Jan 2007 02:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Gww-0005bq-Jz for tsvwg@ietf.org; Fri, 12 Jan 2007 02:35:42 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Gwt-0002gC-2C for tsvwg@ietf.org; Fri, 12 Jan 2007 02:35:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0C7XR9F027211 for ; Fri, 12 Jan 2007 09:33:40 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:35:22 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:35:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jan 2007 09:35:19 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0261_01C7362C.F8C9BCA0" Message-ID: <213394AB6954BE4682E8B2A4910346834855AE@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: mailing list problems Thread-Index: Acc2HDUgonO5K4n+QY+k8FS5homCJg== From: To: X-OriginalArrivalTime: 12 Jan 2007 07:35:22.0320 (UTC) FILETIME=[379A6D00:01C7361C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112093340-69CEEBB0-71500CAD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Tsvwg] mailing list problems X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0261_01C7362C.F8C9BCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, as you can tell, we've had some trouble with the mailing list over the holidays. The admin staff has looked into it and some messages have made it to the list now, but others have not yet appeared (I know, because some of mine are missing). If you've sent any email to the list since Dec 19, please re-send it, and sorry for the trouble. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_0261_01C7362C.F8C9BCA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEyMDczNTE4WjAjBgkqhkiG 9w0BCQQxFgQUpBEVXjdRatTTZ6bpHWoPMXbbrqowZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBALGgWTt8V7ryW1XY8IxlEhqdSrRtgi8xeaNRI66n a9sRx9jMQtEiuE/9rrS1YpUciINjQ+K+Ds5k84MU+i2Px0L65PI/0km1iHl5sZCYCjs04YtK1GAq qlVnTWfX7fFzy/EFpn70hNlRR8FrPMM0mwxiNWNoyi9d7+vI6qzFOLrrIcyeOHtWBy/xxvZzoWH0 kfydXJFH8yVa5YDC0Z2O/jVObhjWvn3DHqSzwchPxfmKoUQht88IrC+wleX55ipPpvcv+zC6KWyB IymbL/qEl7j0ZXZQHvRjv4gs9a3QvyxjRebXzLfHVzA4lDCgClrAcEIy/ya2RgndzxPwtggLSUkA AAAAAAA= ------=_NextPart_000_0261_01C7362C.F8C9BCA0-- From tsvwg-bounces@ietf.org Fri Jan 12 02:40:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5H1m-00013L-5G; Fri, 12 Jan 2007 02:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5H1l-00013G-B5 for tsvwg@ietf.org; Fri, 12 Jan 2007 02:40:41 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5H1j-0003c4-TN for tsvwg@ietf.org; Fri, 12 Jan 2007 02:40:41 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0C7d8BQ002848; Fri, 12 Jan 2007 09:39:09 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:40:03 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:40:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] TCP and UDP MIB issues Date: Fri, 12 Jan 2007 09:39:58 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_026B_01C7362D.9F651AA0" Message-ID: <213394AB6954BE4682E8B2A4910346834855CE@esebe108.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] TCP and UDP MIB issues Thread-Index: Acc1uJhZWZ38JRQGQhC3RJ7aPmj0RQAZBKEg From: To: , X-OriginalArrivalTime: 12 Jan 2007 07:40:02.0575 (UTC) FILETIME=[DEA5F1F0:01C7361C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112093910-0AC13BB0-5F1D4EF7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_026B_01C7362D.9F651AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Does this conflict with > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-e xtension-14.txt > (currently between states in IESG review). > > The TCP Extended Statistics MIB also AUGMENTS both the > tcpConnectionEntry and > tcpListenerEntry. I am not enough of a mib person to understand how > multiple AUGMENTS clauses might interact. I'm not enough of a MIB person either, but I really wish the existence of a related v6ops draft had been brought up during WG or at the latest IETF Last Call. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_026B_01C7362D.9F651AA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEyMDczOTU3WjAjBgkqhkiG 9w0BCQQxFgQUntPceecYZbSIo+9xOV4X4o3ThQkwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBACbVIHkFAqGg96baY3mkwQ3x6QsT6y6wONFBVrlq WVgLcQ6LHaCeXlz8g92BjIE4Vo5RJMlvRM0vpvBgWvHHEStQ7Ra7UquavCZ5KLfFuJuVJY29xsZT fgBOqpNQxAeqa8FOuEZUQdTgJB4xH9llhr6KuMMw5rOOYHhKDs2xjEvqCWOXRVGSbaOVxaTwJhDM AoWcpHScgh1BKeWWbDOtEGMxY6IzkRDpTX413E0yD3FW3w9I3fDZJ0BtPDYReQ8u4auLb/MsTm67 6fSbzdDhJmXGA9ai5uGfAyEVaSo89oTBpuy30+ZbRf07uHQ0OnIyVtXCa0nu4SVFRNoiwF8mjsQA AAAAAAA= ------=_NextPart_000_026B_01C7362D.9F651AA0-- From tsvwg-bounces@ietf.org Fri Jan 12 02:45:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5H5o-0003Qu-6j; Fri, 12 Jan 2007 02:44:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5H5l-0003Ps-VD for tsvwg@ietf.org; Fri, 12 Jan 2007 02:44:49 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5H5k-0004fi-H3 for tsvwg@ietf.org; Fri, 12 Jan 2007 02:44:49 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0C7hBUF003570 for ; Fri, 12 Jan 2007 09:43:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:44:45 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:44:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Jan 2007 09:44:41 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02CC_01C7362E.48787D80" Message-ID: <213394AB6954BE4682E8B2A4910346834855EC@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPR disclosure on draft-lefaucheur-tsvwg-rsvp-proxy Thread-Index: AcczyQzfyknyLTznRY6BbnC/SluNQQ== From: To: X-OriginalArrivalTime: 12 Jan 2007 07:44:45.0189 (UTC) FILETIME=[87196B50:01C7361D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112094318-0AC18BB0-4B96CAF4/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Tsvwg] IPR disclosure on draft-lefaucheur-tsvwg-rsvp-proxy X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02CC_01C7362E.48787D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, this is to inform the WG that the IETF has received an IPR disclosure on the Internet-Draft entitled "RSVP Proxy Approaches" (draft-lefaucheur-tsvwg-rsvp-proxy) on 2006-12-20 (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Cisco's Statement about IPR claimed in draft-lefaucheur-tsvwg-rsvp-proxy-00.txt." This draft is currently being discussed as a potential WG item, and the WG may wish to take this IPR disclosure under consideration when making this decision. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_02CC_01C7362E.48787D80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTEyMDc0NDQxWjAjBgkqhkiG 9w0BCQQxFgQUk2FEOCQBGy0w8aHkXp40Q0OqmzAwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBACnTUDXfNThlFqyhHzJd1MEV6Sz6f5fRlMAIaXXz NwM4JsKViuOmcHn9A863XVleAh4ydYNDiQ/ulmpf5HUJu2Ha93NKMTXpskTJMvFmeSeyXEGMmQ+G MF9W/U9oW+X7WTHFs8w2z1vbP+xTS2/ymTp2bNZRtqSdfSY/EUyz+2M8RgnKNp3rHzbYQh7RAoCR fR44Hf6r7KkxtxeEAKF4DonHBb5wy5uLtAd6ruP1pzF7Rq5i1dhn0hkDpgNlhPjWHsFZs1TQxIMa A6pJ1/SNpOYOjPHlY80uzvpqVpceIhcB/B17oEoC81e07HzGw1UIcFN9iM9wwlkBslYTu0pQRgQA AAAAAAA= ------=_NextPart_000_02CC_01C7362E.48787D80-- From tsvwg-bounces@ietf.org Fri Jan 12 03:15:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5HYa-0002vO-3h; Fri, 12 Jan 2007 03:14:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5HYZ-0002vG-09 for tsvwg@ietf.org; Fri, 12 Jan 2007 03:14:35 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5HYW-0003LX-I1 for tsvwg@ietf.org; Fri, 12 Jan 2007 03:14:34 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l0C8EPck011302 for ; Fri, 12 Jan 2007 09:14:25 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l0C8EPII003601 for ; Fri, 12 Jan 2007 09:14:25 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:14:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jan 2007 09:14:24 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC025C1F54@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question regarding draft-ietf-tsvwg-rsvp-ipsec Thread-Index: AccfYuOf3fO5wiOBRquFEkxCUY3cogE0QVBgBHtryFA= From: "Tschofenig, Hannes" To: "tsvwg tsvwg" X-OriginalArrivalTime: 12 Jan 2007 08:14:25.0696 (UTC) FILETIME=[AC5D3A00:01C73621] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Tsvwg] WG: Question regarding draft-ietf-tsvwg-rsvp-ipsec X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org =20 Resend -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Mittwoch, 20. Dezember 2006 13:51 An: tsvwg tsvwg Betreff: Question regarding draft-ietf-tsvwg-rsvp-ipsec Hi all,=20 My previous work in QoS told me that data packets need to relate somehow = to the information signaled in the QoS signaling messages. How does the = Virtual Destination Port and the=20 Extended Virtual Destination Port relate to the data traffic?=20 Ciao Hannes From tsvwg-bounces@ietf.org Fri Jan 12 03:16:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Hag-000491-9Q; Fri, 12 Jan 2007 03:16:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Haf-00048p-Gf for tsvwg@ietf.org; Fri, 12 Jan 2007 03:16:45 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Hae-0003zL-8x for tsvwg@ietf.org; Fri, 12 Jan 2007 03:16:45 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l0C8GhSe015200 for ; Fri, 12 Jan 2007 09:16:43 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l0C8GgqJ012035 for ; Fri, 12 Jan 2007 09:16:42 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 09:16:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: WG: [Tsvwg] Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec Date: Fri, 12 Jan 2007 09:16:41 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC025C1F5B@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec Thread-Index: AccfYuOf3fO5wiOBRquFEkxCUY3cogFokS4QBEcEx0A= From: "Tschofenig, Hannes" To: "tsvwg tsvwg" X-OriginalArrivalTime: 12 Jan 2007 08:16:42.0903 (UTC) FILETIME=[FE255A70:01C73621] X-Spam-Score: 0.0 (/) X-Scan-Signature: 56904003e9d74831849863e83b1962ec X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Resend=20 -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes=20 Gesendet: Donnerstag, 21. Dezember 2006 14:54 An: 'Francois Le Faucheur IMAP'; tsvwg tsvwg Cc: Magnus Westerlund; RJ Atkinson Betreff: AW: [Tsvwg] Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec Hi Francois,=20 A few minor comments inline: =20 > -----Urspr=FCngliche Nachricht----- > Von: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 > Gesendet: Donnerstag, 14. Dezember 2006 10:29 > An: tsvwg tsvwg > Cc: Magnus Westerlund; RJ Atkinson > Betreff: Re: [Tsvwg] Re: IETF LC comments on=20 > draft-ietf-tsvwg-rsvp-ipsec >=20 > All, >=20 > Below is a proposal for a considerably expanded Security Section for =20 > draft-ietf-tsvwg-rsvp-ipsec, based on our earlier discussions and =20 > input from Ran. > Please comment by X-mas as I'd like to post an updated version round =20 > then, and this is the only remaining open issue. >=20 > Thanks >=20 > Francois >=20 > = =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=3D=3D=3D=3D=3D > Security Considerations >=20 > In the environments addressed by this document, RSVP messages are =20 > used to control resource reservations for generic aggregate =20 > reservations and may be used to control resource reservations=20 > for E2E =20 > reservations being aggregated over the generic aggregate =20 > reservations. To ensure the integrity of the associated reservation =20 > and admission control mechanisms, the RSVP Authentication mechanisms =20 > defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These =20 > protect RSVP message integrity hop-by-hop and provide node =20 > authentication It is really the IP address that is authenticated since there is no = other identifier available (not node authentication). as well as replay protection, thereby protecting =20 > against corruption and spoofing of RSVP messages. These hop-by-hop =20 > integrity mechanisms can be naturally used to protect the RSVP =20 > messages used for generic aggregate reservations and to protect RSVP =20 > messages used for E2E reservations outside the aggregation region. =20 > These hop-by-hop RSVP integrity mechanisms can also be used to =20 > protect RSVP messages used for E2E reservations when those transit =20 > through the aggregation region. This is because the Aggregator and =20 > Deaggregator behave as RSVP neighbors from the viewpoint of the E2E =20 > flows (even if they are not necessarily IP neighbors). >=20 > [RSVP-CRYPTO1] discusses several approaches for key distribution. =20 > First, the RSVP Authentication shared keys can be distributed =20 > manually. This is the base option and its support is mandated=20 > for any =20 > implementation. However, in some environments, this approach may =20 > become a burden if keys frequently change over time.=20 > Alternatively, a =20 > standard key management protocol for secure key distribution can be =20 > used. However, existing key distribution protocols may not be =20 > appropriate in all environments because of the complexity or =20 > operational burden they involve. Finally, [RSVP-CRYPTO1] specifies =20 > how Kerberos [KERBEROS] may be used to generate the RSVP =20 > Authentication keys. Kerberos allows for the use of trusted third =20 > party keying relationships between security principals (RSVP sender =20 > and receivers) where the Kerberos key distribution center (KDC) =20 > establishes an ephemeral session key to be shared between=20 > RSVP sender =20 > and receivers. >=20 > The use of RSVP Authentication in parts of the network where there =20 > may be one or more IP hops in between two RSVP neighbors raises an =20 > additional challenge. This is because, with some RSVP messages such =20 > as a Path message, an RSVP router does not know the RSVP next=20 > hop for =20 > that message at the time of forwarding it. In fact, part of the role =20 > of a Path message is precisely to discover the RSVP next hop (and to =20 > dynamically re-discover it when it changes, say because of a routing =20 > change). Hence, the RSVP router may not know which security =20 > association to use when forwarding such a message. This applies in =20 > particular to the case where RSVP Authentication mechanisms=20 > are to be =20 > used for protection of RSVP E2E messages (e.g. E2E Path) while they =20 > transit through an aggregation region and where the dynamic =20 > Deaggregator determination procedure defined in [RSVP-AGG] is used. =20 > This is because the Aggregator and the Deaggregator behave as RSVP =20 > neighbors for the E2E reservation, while there may be one or more IP =20 > hops in between them, and the Aggregator does not know ahead of time =20 > which router is going to act as the Deaggregator. That's so nice about the RSVP PATH message: It helps you to discover the = next node along the path dynamically even in case of route changes but = at the same time it does not help you since you already need to know the = new node to make use of security.=20 If you always know what the next node is then why do you use a discovery = message. If the protected discovery message hits the wrong node then it = will be discarded =3D Not Good(tm). The simplest way to deal with these problems is to "invent" a discovery = mechanisms. You might get some inspiration in NSIS documents.=20 >=20 > In that situation, one approach is to share the same RSVP =20 > Authentication shared key across all the RSVP routers of a part of =20 > the network where there may be RSVP neighbors with IP hops in =20 > between. For example, all the Aggregators or Deaggregators of an =20 > aggregation region could share the same RSVP Authentication key, =20 > while different per-neighbor keys could be used between any RSVP =20 > router pair straddling the boundary between two administrative =20 > domains that have agreed to use RSVP signaling. >=20 > When the same RSVP Authentication shared key is to be shared among =20 > multiple RSVP neighbors, manual key distribution may be used. In the =20 > future, automated key distribution techniques suitable for this =20 > situation may become available. Possible examples include the =20 > adaptation of multicast key management techniques such as those =20 > developed by the IETF MSEC Working Group or those commonly used for =20 > Multicast key distribution in WiFi environments, to this scenario =20 > wherein the same key also needs to be dynamically distributed to =20 > multiple routers of a particular community (i.e. the RSVP routers =20 > here). Specification of such automated key distribution=20 > techniques or =20 > of their applicability to RSVP is out of the scope of this document. >=20 > The RSVP Authentication mechanisms do not provide=20 > confidentiality. If =20 > confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, =20 > although it imposes the burden of key distribution. Could you explain how the IPsec ESP usage would look like?=20 It also=20 > faces the =20 > additional issue discussed for key management above in case=20 > there can =20 > be IP hops in between RSVP hops. In the future, confidentiality =20 > solutions may be developed for the case where there can be IP=20 > hops in =20 > between RSVP hops, perhaps by adapting confidentiality solutions =20 > developed by the IETF MSEC Working Group. Such confidentiality =20 > solutions for RSVP are outside the scope of this document. >=20 > Protection against traffic analysis is also not provided by RSVP =20 > Authentication. Since generic aggregate reservations are intended to =20 > reserve resources collectively for a whole set of users or hosts, =20 > malicious snooping of the corresponding RSVP messages could provide =20 > more traffic analysis information than snooping of an E2E =20 > reservation. When RSVP neighbors are directly attached, mechanisms =20 > such as bulk link encryption might be used when protection against =20 > traffic analysis is required. I guess you are talking about "link layer encryption". Correct?=20 This approach could be used inside the =20 > aggregation region for protection of the generic aggregate =20 > reservations. It may also be used outside the aggregation region for =20 > protection of the E2E reservation. However, it is not applicable to =20 > the protection of E2E reservations while the corresponding E2E RSVP =20 > messages transit through the aggregation region. >=20 > When generic aggregate reservations are used for aggregation of E2E =20 > reservations, the security considerations discussed in [RSVP-AGG] =20 > apply and are revisited here. >=20 > First, the loss of an aggregate reservation to an aggressor causes =20 > E2E flows to operate unreserved, and the reservation of a great =20 > excess of bandwidth may result in a denial of service. These issues =20 > are not confined to the extensions defined in the present document: =20 > RSVP itself has them. However, they may be exacerbated here by the =20 > fact that each aggregate reservation typically facilitates =20 > communication for many sessions. Hence compromising one such =20 > aggregate reservation can result in more damage than compromising a =20 > typical E2E reservation. Use of the RSVP Authentication=20 > mechanisms to =20 > protect against such attacks has been discussed above. >=20 > An additional security consideration specific to RSVP aggregation =20 > involves the modification of the IP protocol number in RSVP Path =20 > messages that traverse an aggregation region. Malicious modification =20 > of the IP protocol number in a Path message would cause the message =20 > to be ignored by all subsequent RSVP devices on its path, preventing =20 > reservations from being made. It could even be possible to correct =20 > the value before it reached the receiver, making it difficult to =20 > detect the attack. Note that in theory, it might also be=20 > possible for =20 > a node to modify the IP protocol number for non-RSVP messages as =20 > well, thus interfering with the operation of other protocols.=20 > One way =20 > to mitigate the risks of malicious modification of the IP protocol =20 > number is to use an IPsec authentication header, which would ensure =20 > that malicious modification of the IP header is detected. This is a =20 > desirable approach but again imposes some administrative burden in =20 > the form of key management for authentication purposes and may again =20 > face the additional key management issue discussed above where there =20 > can be IP hops in between RSVP neighbors. Could you describe how IPsec would be used here? It is RECOMMENDED that =20 > implementations of this specification only support modification of =20 > the IP protocol number for RSVP Path, PathTear, and ResvConf =20 > messages. That is, a general facility for modification of the IP =20 > protocol number SHOULD NOT be made available. >=20 > Network operators deploying routers with RSVP aggregation capability =20 > should be aware of the risks of inappropriate modification of the IP =20 > protocol number and should take appropriate steps (physical=20 > security, =20 > password protection, etc.) to reduce the risk that a router could be =20 > configured by an attacker to perform malicious modification of the =20 > protocol number. >=20 > = =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 >=20 Ciao Hannes >=20 >=20 > On 17 Nov 2006, at 16:20, Magnus Westerlund wrote: >=20 > > Hi, > > > > Below is answers from Ran to Francois comments. You will need to =20 > > keep him on the CC to discuss these issues. > > > > ---- Text from Ran Atkinson ---------------- > > > > > On 13 Oct 2006, at 11:55, Magnus Westerlund wrote: > > > > > >> Hi, the IESG received the below comment during the ongoing IETF =20 > > LC. I would appreciate some response to it. > > >> > > >> "I think that the "Security Considerations" section of this > > >> document is significantly thin. There are significant security =20 > > risks > > >> associated with this sort of aggregation that I don't=20 > see discussed > > >> in much detail. > > > > > > "RSVP Aggregation over Generic Aggregate RSVP reservations" as =20 > > per this document is of course very very similar to "RSVP =20 > > Aggregation over Aggregate RSVP reservation" as per RFC3175. The =20 > > issues associated with "this sort of aggregation" were=20 > discussed in =20 > > RFC3175, so we elected to refer to the security considerations in =20 > > RFC3175. The current text says: > > > " > > > When generic aggregate reservations are used for=20 > aggregation of E2E > > > reservations, the security considerations discussed in [RSVP-AGG] > > > apply. > > > " > > > We could either keep it this way or replicate the relevant text. =20 > > I would personally prefer keeping it that way because some of the =20 > > security discussions relates to aggregation mechanisms (such as =20 > > RSVP-E2E-IGNORE) which are specified in details in RFC3175=20 > and only =20 > > brought into our document by reference to RFC3175. > > > But I can bring in the relevant text if you recommend we do so. > > > > The relevant text ought to be replicated, possibly editing it to > > reflect whatever differences might exist between this and RFC-3175 > > and whatever we know/realise now that might not have been clearly > > documented or understood then. > > > > >> There should also be at least some mention of traffic > > >> analysis issues and the potential DDOS attacks on the network > > >> operator arising from this usage. > > > > > > Regarding traffic analysis, I am not quite sure what is there to =20 > > say. > > > It seems that if an entity uses RSVP to signal its reservation =20 > > requirement from point A to point B, someone snooping RSVP =20 > > signaling would be able to know ... what are the reservation =20 > > requirement from point A to point B. That seems like a fundamental =20 > > aspect of signaling. > > > > It is a fundamental aspect of *clear-text* *in-band* signalling. > > > > It is not a fundamental aspect of in-band signalling. For example, > > one could provide confidentiality to the signalling traffic > > (if one could figure out how to distribute keys properly). > > > > It is not a fundamental aspect of signalling. For example, > > Signalling System 7 (used in the telephony world) is out-of-band, > > so snooping by ordinary users generally isn't practical. > > > > > Or is the point that using aggregation makes traffic analysis =20 > > easier because you get the full aggregate requirement by snooping =20 > > one message? > > > Is this worth mentioning this? > > > > This is also worth mentioning, and it is a difference in risk > > from ordinary RSVP usage. > > > > > Is there something smarter/more useful that should be said about =20 > > traffic analysis that is specific to this document? > > > > > >> > > >> Unlike RIPv2 Authentication, RSVP Authentication has never had > > >> any measurably large deployment, as near as I can tell. > > > > > > Actually, I believe there is significant use of RSVP =20 > > Authentication in MPLS Traffic Engineering deployments. > > > > I know of several ISPs that use RSVP for MPLS Traffic Engineering. > > I do not know of *one* that has enabled RSVP Authentication=20 > for MPLS. > > Several have said that RSVP Authentication is impractical to enable > > because of the absence of suitable key management. This has come > > up in hallway conversations with operators at RIPE and NANOG in the > > past. More recently, I've heard complaints about this aspect of > > RSVP informally from certain parts of the US Government. > > > > This issue is not unique to RSVP. For example, BGP Authentication > > (or RIPv2 Authentication) faces similar challenges where we have a > > suitable authentication mechanism, but the absence of suitable key > > management is one of several reasons that BGP Authentication has > > somewhat limited deployment. If one looks at the RIPv2=20 > Authentication > > document (either the original one or the latest one), then one will > > see that this key management issue for RIP is carefully described -- > > along with suggestions for how the IETF might be able to=20 > fill that gap > > in future. > > > > If the authors think that suitable key management exists for RSVP > > in this usage, it would be VERY helpful to document that in the > > SECURITY CONSIDERATIONS for this draft, so that operators who choose > > to deploy this mechanism know how to do it. > > > > Alternately, and more likely in my view, they should at=20 > least clearly > > document this key management issue/gap with RSVP for this usage > > in the SECURITY CONSIDERATIONS section. If they think a reasonable > > algorithm exists, by all means add a citation to REFERENCES and > > mention that in SECURITY CONSIDERATIONS as a possible=20 > future approach. > > > > In the case of RIPv2, RIP packets are typically sent via IP=20 > multicast > > to a special IP multicast group. So if/when IETF has a key=20 > management > > protocol for multicast applications (there is, I believe,=20 > the MSEC WG > > on this -- and both RFC-2094 and RFC-2095 give reasonable hope that > > it is a tractable problem), then RIP can use that approach. OSPF's > > situation is essentially the same as RIP, since both use IP =20 > > multicasting > > to reserved multicast groups. > > > > In the case of RSVP, packets are sent along a path, but the actual > > path members are dynamic. It is unclear to me that a key management > > strategy even exists for this sort of deployment. Maybe, and one > > would have to give it a lot more thought, one could use a public-key > > scheme along with a PKI (holding an incoming RSVP packet for the > > relatively long time a key management protocol transaction=20 > would take > > likely has adverse consequences for the flow being=20 > signalled). If the > > authors think such a strategy really exists, it would be helpful > > to mention it and perhaps add a citation or two in the REFERENCES > > section. > > > > >> A practical > > >> to deploy key management strategy is not apparent to me right now > > >> for RSVP Authentication. RSVP Auth keys need to be placed in all > > >> of the devices along a dynamic and *changing* flow path, so it is > > >> much harder to pre-position manual keys along the whole path. > > >> By contrast, OSPF and RIP have a well-defined and static set of > > >> legitimate participating routers, so one can=20 > pre-position manual =20 > > keys > > >> in all of those OSPF/RIP routers (and that has been commonly done > > >> in numerous enterprise networks using OSPFv2 Auth or RIPv2 Auth). > > > > > > Well, in environments where RSVP is deployed on all routers of a =20 > > convex cloud, using pre-positioned keys for RSVP seems very=20 > similar =20 > > to using pre-positioned keys for OSPF/RIP. I think pre-positioning =20 > > keys with RSVP only gets more tricky in environments where=20 > you have =20 > > non-RSVP routers in between RSVP routers. > > > > See above. This analysis is flawed in that both RIP and OSPF use > > special-purpose IP multicast groups, so they can use MSEC's=20 > multicast > > key management. RSVP does not use multicast, so it is not obvious > > that it can use multicast key management. > > > > > But in any case, most of this discussion about general =20 > > applicability of RSVP Authentication seems beyond the scope=20 > of this =20 > > particular document. > > > > Not at all. If we have an issue with a security mechanism and some > > protocol extension relies on that security mechanism, then the issue > > remains unresolved for the usage in the extension document and > > also should be clearly documented in the extension document's > > SECURITY CONSIDERATIONS. > > > > > The one point I can see which is specific to this document, is =20 > > that the aggregation mechanisms used here rely on the=20 > Aggregator to =20 > > send an E2E Path message into the Aggregation region without =20 > > knowing ahead of time which Deaggregator will be used. This aspect =20 > > is already discussed in the document, which also mentions that one =20 > > possible solution then is to use the same key across all =20 > > Aggregators/Deaggregators. > > > > Since we don't have a way to actually manage keys, it isn't clear > > that this is any more practical than the general case, though it is > > good that it is already mentioned. > > > > > BTW, Pratik Bose, Fred Baker and I, plan to submit a document =20 > > proposing a method for IPsec protection of RSVP which could=20 > be used =20 > > in many RSVP environments, including the ones of generic aggregate =20 > > RSVP. This may offer an alternative approach to the security =20 > > concern discussed in previous paragraph. But this is future work, =20 > > and need not be referenced from that document. > > > > At least the existence of the current real-world issues that make > > it hard for a deployment to be secured should be fully documented > > in the SECURITY CONSIDERATIONS. It might, depending on the IESG's =20 > > views, > > be reasonable to add a paragraph to SECURITY CONSIDERATIONS=20 > outlining > > the general concept that the 3 folks names above have in mind for > > key management and indicate that this is one possible future =20 > > direction. > > > > As Steve Bellovin would be very quick to point out, "just use IPsec" > > is not always a very credible answer. I am the original author of > > AH and ESP; I co-chaired the IPsec WG for a while. In this case, > > the issue is not so much how to use AH/ESP with RSVP, which might be > > what is meant by the quoted text above, but how would one manage the > > keys. It is not at all clear that a hybrid Diffie-Hellman scheme, > > such as ISAKMP/IKE, can be used in an RSVP deployment such as is > > described here. This is UNLIKE the case with RIP or OSPF, which > > use multicast for their messages, where there are published=20 > techniques > > for multicast key management (RFC-2093, RFC-2094, and a wider number > > in the open cryptographic literature) and there has been an=20 > IETF MSEC > > WG actually developing multicast key management for IETF use. > > > > It seems that if one looks through the above, at a bare minimum > > significant new text (on several different topics) is needed in > > this document's SECURITY CONSIDERATIONS section. > > > > Yours, > > > > Ran > > rja@extremenetworks.com > > > > > > > > > > --=20 > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVA/A > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >=20 > ---------------------------------------------------------------------- >=20 >=20 From tsvwg-bounces@ietf.org Fri Jan 12 08:06:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5M6o-0002lp-LG; Fri, 12 Jan 2007 08:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5M6n-0002ld-CM; Fri, 12 Jan 2007 08:06:13 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5M6l-0002Ud-Tw; Fri, 12 Jan 2007 08:06:13 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0CD6Btn007469; Fri, 12 Jan 2007 08:06:11 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0CD6ACP554638; Fri, 12 Jan 2007 06:06:11 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0CD6AYI003389; Fri, 12 Jan 2007 06:06:10 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0CD6A7F003344; Fri, 12 Jan 2007 06:06:10 -0700 In-Reply-To: <213394AB6954BE4682E8B2A4910346834855CE@esebe108.NOE.Nokia.com> To: tsvwg@ietf.org, ietfmibs@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Kristine Adamson Date: Fri, 12 Jan 2007 06:07:43 -0700 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 7.0 HF144|February 01, 2006) at 01/12/2007 08:06:09 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 7.0 HF144|February 01, 2006) at 01/12/2007 08:06:09 AM, Serialize complete at 01/12/2007 08:06:09 AM, S/MIME Sign failed at 01/12/2007 08:06:09 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/12/2007 06:07:44, Serialize complete at 01/12/2007 06:07:44 Content-Type: multipart/alternative; boundary="=_alternative 0047F96385257261_=" X-Spam-Score: 0.5 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [Tsvwg] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 0047F96385257261_= Content-Type: text/plain; charset="US-ASCII" I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended Statistics MIB because I work on an IBM product's SNMP support. As far as I am aware, you may have more than one "augmenting" table which augments a base table. But an augmenting table can not itself be a base table. I am copying the MIB mailing list for any additional feedback. So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the tcpConnectionTable in the TCP-MIB. That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's tcpConnectionInfoTable, could be moved to one of the tables in the TCP-ESTATS-MIB. We will be looking into implementing the TCP-ESTATS-MIB in the future in order to support additional information for TCP connections. Since the TCP-ESTATS-MIB is in the final approval stages, maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's table in the future, as an updated version of the MIB module. Or, maybe they should be added to the TCP-MIB's tcpConnectionTable? Unfortunately, I don't think any IETF group is working on an extended statistics MIB module for UDP endpoints. If we create a MIB table with a general name like, udpEndpointInfoTable, then you would expect that any other additional management data for UDP endpoints would be added to this table. Instead, maybe it would be better to either add the UDP Creation MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the udpEndpointInfoTable to something more specific, like udpEndpointCreationTable. Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Phone: (919) 254-7911 T/L 444-7911 Internet e-mail:adamson@us.ibm.com wrote on 01/12/2007 02:39:58 AM: > > Does this conflict with > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-e > xtension-14.txt > > (currently between states in IESG review). > > > > The TCP Extended Statistics MIB also AUGMENTS both the > > tcpConnectionEntry and > > tcpListenerEntry. I am not enough of a mib person to understand how > > multiple AUGMENTS clauses might interact. > > I'm not enough of a MIB person either, but I really wish the existence > of a related v6ops draft had been brought up during WG or at the latest > IETF Last Call. > > Lars > -- > NEW EMAIL: lars.eggert@nokia.com > NEW MOBILE: +358 50 48 24461 > NEW JABBER: lars.eggert@googlemail.com --=_alternative 0047F96385257261_= Content-Type: text/html; charset="US-ASCII"
I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended Statistics MIB because I work on an IBM product's SNMP support.  As far as I am aware, you may have more than one "augmenting" table which augments a base table.  But an augmenting table can not itself be a base table.  I am copying the MIB mailing list for any additional feedback.  

So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the tcpConnectionTable in the TCP-MIB.  

That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's tcpConnectionInfoTable, could be moved to one of the tables in the TCP-ESTATS-MIB.  We will be looking into implementing the TCP-ESTATS-MIB in the future in order to support additional information for TCP connections.  Since the TCP-ESTATS-MIB is in the final approval stages, maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's table in the future, as an updated version of the MIB module.   Or, maybe they should be added to the TCP-MIB's  tcpConnectionTable?

Unfortunately, I don't think any IETF group is working on an extended statistics MIB module for UDP endpoints.  If we create a MIB table with a general name like, udpEndpointInfoTable, then you would expect that any other additional management data for UDP endpoints would be added to this table.  Instead, maybe it would be better to either add the UDP Creation MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the udpEndpointInfoTable to something more specific, like udpEndpointCreationTable.
           
Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:adamson@us.ibm.com

<lars.eggert@nokia.com> wrote on 01/12/2007 02:39:58 AM:

> > Does this conflict with
> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-e
> xtension-14.txt
> > (currently between states in IESG review).
> >
> > The TCP Extended Statistics MIB also AUGMENTS both the
> > tcpConnectionEntry and
> > tcpListenerEntry.    I am not enough of a mib person to understand how
> > multiple AUGMENTS clauses might interact.
>
> I'm not enough of a MIB person either, but I really wish the existence
> of a related v6ops draft had been brought up during WG or at the latest
> IETF Last Call.
>
> Lars
> --
> NEW EMAIL: lars.eggert@nokia.com
> NEW MOBILE: +358 50 48 24461
> NEW JABBER: lars.eggert@googlemail.com  
--=_alternative 0047F96385257261_=-- From tsvwg-bounces@ietf.org Fri Jan 12 08:30:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5MUT-000064-Dt; Fri, 12 Jan 2007 08:30:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5MUR-00005o-M8; Fri, 12 Jan 2007 08:30:39 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5MUP-0007Z3-4U; Fri, 12 Jan 2007 08:30:39 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0CDUatS027218; Fri, 12 Jan 2007 08:30:36 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0CDUaVw549086; Fri, 12 Jan 2007 06:30:36 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0CDUaMg027659; Fri, 12 Jan 2007 06:30:36 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0CDUa0x027654; Fri, 12 Jan 2007 06:30:36 -0700 In-Reply-To: <20070112131350.GA24691@boskop.local> To: j.schoenwaelder@iu-bremen.de MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Kristine Adamson Date: Fri, 12 Jan 2007 06:32:10 -0700 X-MIMETrack: S/MIME Sign by Notes Client on Kristine Adamson/Raleigh/IBM(Release 7.0 HF144|February 01, 2006) at 01/12/2007 08:30:35 AM, Serialize by Notes Client on Kristine Adamson/Raleigh/IBM(Release 7.0 HF144|February 01, 2006) at 01/12/2007 08:30:35 AM, Serialize complete at 01/12/2007 08:30:35 AM, S/MIME Sign failed at 01/12/2007 08:30:35 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/12/2007 06:32:11, Serialize complete at 01/12/2007 06:32:11 Content-Type: multipart/alternative; boundary="=_alternative 004A365685257261_=" X-Spam-Score: 0.5 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ietfmibs@ietf.org, tsvwg@ietf.org Subject: [Tsvwg] Re: [IETFMIBS] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multipart message in MIME format. --=_alternative 004A365685257261_= Content-Type: text/plain; charset="US-ASCII" Juergen, Sorry for the confusion. The current draft of the TCP-ESTATS-MIB is at: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt The TCP/UDP Process MIB draft is at: http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt Kristine Adamson IBM z/OS Communications Server: TCP/IP Development Phone: (919) 254-7911 T/L 444-7911 Internet e-mail:adamson@us.ibm.com Juergen Schoenwaelder wrote on 01/12/2007 08:13:50 AM: > On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote: > > I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended > > Statistics MIB because I work on an IBM product's SNMP support. As far as > > I am aware, you may have more than one "augmenting" table which augments a > > base table. But an augmenting table can not itself be a base table. I am > > copying the MIB mailing list for any additional feedback. > > > > So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and > > the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the > > tcpConnectionTable in the TCP-MIB. > > > > That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's > > tcpConnectionInfoTable, could be moved to one of the tables in the > > TCP-ESTATS-MIB. We will be looking into implementing the TCP-ESTATS-MIB > > in the future in order to support additional information for TCP > > connections. Since the TCP-ESTATS-MIB is in the final approval stages, > > maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's > > table in the future, as an updated version of the MIB module. Or, maybe > > they should be added to the TCP-MIB's tcpConnectionTable? > > > > Unfortunately, I don't think any IETF group is working on an extended > > statistics MIB module for UDP endpoints. If we create a MIB table with a > > general name like, udpEndpointInfoTable, then you would expect that any > > other additional management data for UDP endpoints would be added to this > > table. Instead, maybe it would be better to either add the UDP Creation > > MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the > > udpEndpointInfoTable to something more specific, like > > udpEndpointCreationTable. > > It would help people like me who did not follow any of this work if > you can provide us the names of the documents in question. > > /js > > -- > Juergen Schoenwaelder {International|Jacobs} University Bremen > P.O. Box 750 561, 28725 Bremen, Germany --=_alternative 004A365685257261_= Content-Type: text/html; charset="US-ASCII"
Juergen,
   Sorry for the confusion.  The current draft of the TCP-ESTATS-MIB is at:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt

The TCP/UDP Process MIB draft is at:
http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt  

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:adamson@us.ibm.com

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> wrote on 01/12/2007 08:13:50 AM:

> On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote:
> > I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended
> > Statistics MIB because I work on an IBM product's SNMP support.  As far as
> > I am aware, you may have more than one "augmenting" table which augments a
> > base table.  But an augmenting table can not itself be a base table.  I am
> > copying the MIB mailing list for any additional feedback.
> >
> > So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and
> > the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the
> > tcpConnectionTable in the TCP-MIB.
> >
> > That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's
> > tcpConnectionInfoTable, could be moved to one of the tables in the
> > TCP-ESTATS-MIB.  We will be looking into implementing the TCP-ESTATS-MIB
> > in the future in order to support additional information for TCP
> > connections.  Since the TCP-ESTATS-MIB is in the final approval stages,
> > maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's
> > table in the future, as an updated version of the MIB module.   Or, maybe
> > they should be added to the TCP-MIB's  tcpConnectionTable?
> >
> > Unfortunately, I don't think any IETF group is working on an extended
> > statistics MIB module for UDP endpoints.  If we create a MIB table with a
> > general name like, udpEndpointInfoTable, then you would expect that any
> > other additional management data for UDP endpoints would be added to this
> > table.  Instead, maybe it would be better to either add the UDP Creation
> > MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the
> > udpEndpointInfoTable to something more specific, like
> > udpEndpointCreationTable.
>
> It would help people like me who did not follow any of this work if
> you can provide us the names of the documents in question.
>
> /js
>
> --
> Juergen Schoenwaelder       {International|Jacobs} University Bremen
> <http://www.eecs.iu-bremen.de/>    P.O. Box 750 561, 28725 Bremen, Germany
 --=_alternative 004A365685257261_=-- From tsvwg-bounces@ietf.org Fri Jan 12 08:42:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mfk-00086Q-SQ; Fri, 12 Jan 2007 08:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mfj-000847-88 for tsvwg@ietf.org; Fri, 12 Jan 2007 08:42:19 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mfh-0002gq-U7 for tsvwg@ietf.org; Fri, 12 Jan 2007 08:42:19 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBR0003QCPOML@firewall.mci.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:55 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBR00K48CPRP6@dgismtp06.mcilink.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:51 +0000 (GMT) Received: from XS344V8061891 ([153.39.146.250]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBR00K4FCPJGS@dgismtp06.mcilink.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:51 +0000 (GMT) Date: Fri, 12 Jan 2007 08:41:38 -0500 From: Dave McDysan Subject: RE: [Tsvwg] FW: Review of draft-ietf-tsvwg-diffserv-class-aggr (UNCLASSIFIED) In-reply-to: <9B4320CC9BC1D847AFFA97F25A422A59A973E7@vanualevu.disanet.disa-u.mil> To: "'Nguyen, An P CIV NCS NC2'" , 'Dave McDysan' Message-id: <0JBR00K4WCPQGS@dgismtp06.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AccaFPGygUS34kv4QbSVoRtjToe+TgUZdSWQAc/2uGAAAN8mIAAjmOFA X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: 'tsvwg' X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org An, Here is the description from Y.1221 6.1.1 Description The Dedicated Bandwidth (DBW) transfer capability is intended to support applications with stringent delay requirements. It aims to support the guaranteed and timely delivery of IP packets along the end-to-end path of the network. The DBW transfer capability strives for compatibility with the Guaranteed Service [RFC 2212] and the end-to-end services based on the Expedited Forwarding per-hop behaviour [RFC 2598]. BTW, according to an IUT-T attendee in my company "Free public online access to in-force ITU-T Recommendations is being provided by the ITU on a trial basis from January 2007 until September 2007 to promote dissemination and usage of ITU-T Recommendations. PDF versions of ITU-T Recommendations are available via the ITU web site (http://www.itu.int/ITU-T/publications/recs.html). " More details are in the recommendation, and it is now free for the next 8 months. Dave > -----Original Message----- > From: Nguyen, An P CIV NCS NC2 [mailto:an.p.nguyen@dhs.gov] > Sent: Thursday, January 11, 2007 3:53 PM > To: Dave McDysan > Cc: tsvwg; Nguyen, An P CIV NCS NC2 > Subject: RE: [Tsvwg] FW: Review of > draft-ietf-tsvwg-diffserv-class-aggr (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: NONE > > Dave, > > Just a question for verification: Does dedicated bandwidth in > the Y.1221 column below mean fixed connectivity? > > Thanks, > > An > > ----------------------------------------------- > > 6. Treatment Aggregates and Inter-Provider Relationships > > Suggest addition of a reference to the MIT QoS Interprovider > white paper mentioned above. After much discussion, the > service providers involved in this effort were only able to > agree on a minimum set of two treatment aggregates. > > Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. > Appendix VI defines a minimum set of three QoS classes and a > mapping to (sets of) IETF DSCP values as follows: > > Y.1221 Associated Y.1541 > Transfer Diffserv QoS > Capability PHBs Class(es) > ------------ ---------- -------- > Best Effort Default 5 > > Delay-Sensitive AF 2,3,4 > Statistical BW > > Dedicated EF 0,1 > Bandwidth > > > > Dave > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, December 07, 2006 10:32 AM > > To: tsvwg > > Subject: [Tsvwg] Need for volunteers for reviewing > > draft-ietf-tsvwg-diffserv-class-aggr > > > > Hi, > > > > To make progress we need some reviewers to read and comment on > > "Aggregation of DiffServ Service Classes": > > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-ag > > gr-01.txt > > > > We chairs don't think we can proceed with this draft until we seen > > some confirming reviews from the WG participants. So please > volunteer. > > > > If you are willing to do this review please indicate so to > us chairs. > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > ---------------------------------------------------------------------- > > > > > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > > From tsvwg-bounces@ietf.org Fri Jan 12 08:42:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mfj-00085R-Iv; Fri, 12 Jan 2007 08:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Mfh-00083o-UE for tsvwg@ietf.org; Fri, 12 Jan 2007 08:42:17 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Mfe-0002gq-BB for tsvwg@ietf.org; Fri, 12 Jan 2007 08:42:17 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBR0003QCPOML@firewall.mci.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:54 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBR00K3HCPOP6@dgismtp06.mcilink.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:48 +0000 (GMT) Received: from XS344V8061891 ([153.39.146.250]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBR00K4FCPJGS@dgismtp06.mcilink.com> for tsvwg@ietf.org; Fri, 12 Jan 2007 13:41:48 +0000 (GMT) Date: Fri, 12 Jan 2007 08:41:38 -0500 From: Dave McDysan In-reply-to: To: 'Fred Baker' Message-id: <0JBR00K4LCPOGS@dgismtp06.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: Acc1/R6dwCYcNCUTQi+kLtpuoeLbgwAUTcLA X-Spam-Score: 0.1 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: 'Magnus Westerlund' , babiarz@nortel.com, 'tsvwg' , 'Kwok-Ho Chan' Subject: [Tsvwg] RE: Review of draft-ietf-tsvwg-diffserv-class-aggr X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Fred, I would like to see the document be of broader use than a single company. This is why I referenced the MFA work, which references this draft. It uses the '101' codepoint for real-time and does not state that support for the network control treatment aggregate is mandatory. With the changes that I suggested, I think this document is going in a direction that is useful to the MFA, of which several service providers (including Verizon) believe this work is important. As mentioned in the comments, I am proposing that this document be focused on how to best support aggregation of treatements for IP and that the issues of how to support pseudowires, VPLS and pt-mpt be handled in a separate document so that something useful for IP is delivered first. Dave > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, January 11, 2007 10:52 PM > To: Dave McDysan > Cc: 'Magnus Westerlund'; 'tsvwg'; 'Kwok-Ho Chan'; babiarz@nortel.com > Subject: Re: Review of draft-ietf-tsvwg-diffserv-class-aggr > > Thanks for your review, Dave. > > Given that we update per your comments, do you feel that the > document serves Verizon? Do you feel this is going in a > direction that is useful to you? > > On Jan 2, 2007, at 5:03 PM, Dave McDysan wrote: > > > As requested, here is my review of the subject draft. > > > > Within Verizon and draft work in the MPLS FR ATM Alliance > (MFA) we are > > using RFC 4594 and ITU-T Y.1541 in our definitions of > Diffserv, PW and > > native MPLS deployments. An RFC that gave some guidance and > a baseline > > for how to map these various services to treatment aggregates as > > defined by MPLS EXP bits would be extremely useful for > internal use as > > well as use in specifying network interconnections. These > comments are > > based upon a review of the various deployed and proposed > uses of EXP > > bits within Verizon, experience on negogiating interconnects with > > other service providers, work within the MFA and the results of MIT > > Interprovider QoS workshops, as summarized in the > > following: > > http://cfp.mit.edu/resources/papers/Interprovider%20QoS% > > 20MIT_CFP_WP_9_14_06 > > .pdf > > > > Suggest that in section 1, Introduction that the draft explicitly > > state the assumption that all traffic is IP and marked with a > > particular set of DSCP values, as described in RFC 4594. > > > > In some cases cited below bullet 5 in section 3, overview > of service > > class aggregation, the traffic carried may not be IP > (e.g., TDM, FR, > > ATM or Ethernet over pseudowire, VPLS). Section 2, Terminology, > > references RFC 3270 definitions of E-LSP and L-LSP, which > include the > > concept of a Forwarding Equivalency Class (FEC). I suggest > that either > > the scope of this draft should be constrained to only IP and these > > other applications be mentioned as out of scope, or else more text > > regarding handling of non-IP applications needs to be added. For > > example, there could be an IP FEC and a non- IP FEC for use > with E-LSP > > or L-LSP from RFC 3270. > > > > Suggest that the authors add some text to section 4.1., Mapping > > Service Classes into Four Treatment Aggregates, explaining > why those > > chose > > 4 instead > > of 3 or 5 treatment aggregates. From section 1, " Note that > in a given > > domain, we may recommend that the supported service classes be > > aggregated > > into forwarding treatment aggregates; however, this does > not mean > > all > > service classes need to be supported and hence not all forwarding > > treatment aggregates need to be supported." This text implies > > specification of a maximum set of treatment aggregates, and > a means to > > map these to a minimum set. Is the intent of this draft to > specify the > > minimum or maximum set? > > > > In Figure 1, Treatment Aggregate and Service Class Performance > > Requirements, I think that broadcast video is not > Real-Time. Also, in > > enterprise VPNs, we have distinguished Telephony/Signaling from > > Mulitmedia conferencing in treatment aggregates in deployed > networks. > > > > Section 4.1.1. Network Control Treatment Aggregate. We > view network > > control as an IP-only service class, not subject to (MPLS) > treatment > > aggregation. > > Although some VPN service providers have proposed extending this > > service class across an interconnect to their networks, we have > > convinced them that they should map customer network > control traffic > > (e.g., BGP, or IGP information for an RFC 4364 VPN) or their own > > network control class to some other behavior or treatment aggregate. > > > > Suggest that the draft add some text indicating that > network control > > traffic is for internal use to a network. For example, > Section 4.2.1 > > of RFC > > 4274 > > could be cited: "The Network Control precedence designation is > > intended to be used within a network only. The actual use > and control > > of that designation is up to each network. [RFC791]" > > > > 4.1.2. Real Time Treatment Aggregate. As mentioned above, > current and > > planned deployments break out telephony/signaling from multimedia > > conferencing and broadcast video. If the draft is proposing > that the > > real-time treatment aggregate (as defined in 1994 from RFC 1633) is > > part of a minimum treatment aggregate set, then it should > state this. > > I would like to see mention of a larger treatment aggregate > set that > > at least splits out telephony/signaling from multimedia > conferencing > > and broadcast video. > > > > 4.1.3. Assured Elastic Treatment Aggregate. Personally, I > think that > > the indication of loss probability in a treatment aggregate > is a good > > idea. > > However, some deployments and plans do not use this. Also, > this means > > using up to an additional bit in the limited 3-bit MPLS EXP field. > > Suggest that > > the draft state that indicating the loss probability is highly > > desirable, but may not be part of the minimum set of treatment > > aggregates that a network segment may implement (see section 1). > > > > 4.1.4. Elastic Treatment Aggregate. Personally, I think that the > > indication of loss probability in a treatment aggregate is a good > > idea. > > However, some > > deployments and plans do not use this. Also, this means > using up to an > > additional bit in the limited 3-bit MPLS EXP field. Suggest > that the > > draft state that indicating the loss probability is highly > desirable, > > but may not be part of the minimum set of treatment > aggregates that a > > network segment may implement (see section 1). > > > > 5. Using MPLS for Treatment Aggregates, first paragraph. > As mentioned > > above, suggest that the authors clarify whether this is the > maximum or > > minimum set of treatment aggregates as described in section > 1 that are > > recommended. > > > > This section is where the most significant issues exist. > > > > 5.1. Network Control Treatment Aggregate with E-LSP > > > > In discussions with internal users as well as discussions > in the MFA, > > there is not much support for using a set of MPLS EXP bits > for network > > control. > > Looking at the description for network control from RFC 4594, it > > appears that most of these uses would be IP only and not be > subject to > > MPLS encapsulation. The one exception we discussed is how to handle > > network control DSCP marked packets from BGP IP MPLS VPN customers. > > This could be done using the proposed "110" codepoint in > Figure 3, but > > another method would be for the service provider to map customer > > network control traffic to some other treatment aggregate (e.g., > > assured elastic). Suggest that the network control > treatment aggregate > > usage with MPLS EXP bit marking be more clearly stated in > the draft. > > Also, suggest that the network control treatment aggregate > be part of > > the maximum treatment aggregate set. > > > > 5.2. Real Time Treatment Aggregate with E-LSP > > > > As mentioned above, this differs from uses within Verizon, > the MIT QoS > > Interprovider workshop and discussions in the MFA. The MPLS EXP bit > > values of "101" are used in at least these contexts to > indicate only > > telephony/signaling for EF/CS5. This is the most significant > > difference between the draft and other publications and > industry work. > > Also we have assigned the AF4x DSCP for multimedia conferencing as > > MPLS EXP "100," and also treat broadcast video as another RFC 3270 > > FEC. > > > > In order to resolve this comment, suggest that the draft define a > > minimum subset of the "real-time" treatment aggregate and > mention that > > some network segments (see section 1) may define a larger set along > > the lines of what I mention above. > > > > Sections 5.3 (5.4) Assured Elastic (Elastic) Treatment > Aggregate with > > E-LSP > > > > These MPLS EXP code points (without the loss probability bit > > encoding) are > > what is used in several VPN and public IP networks. > > > > Section 5 - Additional comments > > > > If the scope decision of this document is to expand to non-IP > > applications, then additional text on handling Pseudowires > with client > > services having their own QoS definitions, VPLS and other potential > > uses of MPLS would need to be added. My recommendation would be to > > keep this document focused on the IP applications, and if anyone is > > interested then another document that covered non-IP applications > > could be drafted. > > > > 6. Treatment Aggregates and Inter-Provider Relationships > > > > Suggest addition of a reference to the MIT QoS Interprovider white > > paper mentioned above. After much discussion, the service providers > > involved in this effort were only able to agree on a minimum set of > > two treatment aggregates. > > > > Also suggest addition of a reference to the Feb 2006 ITU-T Y.1541. > > Appendix > > VI defines a minimum set of three QoS classes and a mapping > to (sets > > of) IETF DSCP values as follows: > > > > Y.1221 Associated Y.1541 > > Transfer Diffserv QoS > > Capability PHBs Class(es) > > ------------ ---------- -------- > > Best Effort Default 5 > > > > Delay-Sensitive AF 2,3,4 > > Statistical BW > > > > Dedicated EF 0,1 > > Bandwidth > > > > (If you don't have ITU access, you can get up to three free ITU-T > > documents per Email address by going to www.itu.int and > going to the > > purchase page and entering your email address.) > > > > Many international providers look to the ITU-T for > guidance, and that > > would be the focus on many of our network provider interconnection > > uses of treatment aggregates and MPLS EXP bit markings. > Therefore, at > > least some mention of a similar minimum subset of aggregations > > proposed by the ITU-T in this document would be valuable. > Finally, I > > note that if network control is removed from the minimum subset in > > this draft, then the above set from ITU-T > > Y.1541 Appendix VI is equivalent in terms of number of treatment > > aggregates and a high-level mapping of service capabilities. > > > > Regards, > > > > Dave > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Thursday, December 07, 2006 10:32 AM > >> To: tsvwg > >> Subject: [Tsvwg] Need for volunteers for reviewing > >> draft-ietf-tsvwg-diffserv-class-aggr > >> > >> Hi, > >> > >> To make progress we need some reviewers to read and comment on > >> "Aggregation of DiffServ Service Classes": > >> > > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class- > > aggr-01. > > txt > >> > >> We chairs don't think we can proceed with this draft until we seen > >> some confirming reviews from the WG participants. So please > >> volunteer. > >> > >> If you are willing to do this review please indicate so to > us chairs. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> IETF Transport Area Director & TSVWG Chair > >> > --------------------------------------------------------------------- > >> - > >> Multimedia Technologies, Ericsson Research EAB/TVA/A > >> > --------------------------------------------------------------------- > >> - > >> Ericsson AB | Phone +46 8 4048287 > >> Torshamsgatan 23 | Fax +46 8 7575550 > >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> > --------------------------------------------------------------------- > >> - > >> > >> > >> > > From tsvwg-bounces@ietf.org Fri Jan 12 10:58:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5On4-0000T7-NZ; Fri, 12 Jan 2007 10:58:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5On1-0000Sl-K6; Fri, 12 Jan 2007 10:58:00 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5Omw-0008Ao-60; Fri, 12 Jan 2007 10:57:59 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l0CFvo0r012056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jan 2007 10:57:51 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id l0CFvm5x007863; Fri, 12 Jan 2007 10:57:48 -0500 Date: Fri, 12 Jan 2007 10:57:48 -0500 (EST) From: Matt Mathis To: Kristine Adamson Subject: Re: [Tsvwg] Re: [IETFMIBS] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: j.schoenwaelder@iu-bremen.de, ietfmibs@ietf.org, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org If there is not a technical problem with two tables that AUGMENT the same base table, I strongly advocate advancing the documents separately. ESTATS mib is almost ready for the RFC editor queue. -mib-issue- is not even a WG item yet, and may or may not converge quickly. I really don't want to reopen ESTATS mib for lots of new revisions at this time. That said, the issues raised in -mib-issue- are real. We were aware of them but (mistakenly?) believed that there did not exist a standardizable OS independent solution. I would like to see this work proceed, but not at the cost of stalling ESTATS. Thanks, --MM-- On Fri, 12 Jan 2007, Kristine Adamson wrote: > Juergen, > Sorry for the confusion. The current draft of the TCP-ESTATS-MIB is > at: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt > > The TCP/UDP Process MIB draft is at: > http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt > > Kristine Adamson > IBM z/OS Communications Server: TCP/IP Development > Phone: (919) 254-7911 T/L 444-7911 > Internet e-mail:adamson@us.ibm.com > > > Juergen Schoenwaelder wrote on 01/12/2007 > 08:13:50 AM: > > > On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote: > > > I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended > > > Statistics MIB because I work on an IBM product's SNMP support. As > far as > > > I am aware, you may have more than one "augmenting" table which > augments a > > > base table. But an augmenting table can not itself be a base table. I > am > > > copying the MIB mailing list for any additional feedback. > > > > > > So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) > and > > > the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment > the > > > tcpConnectionTable in the TCP-MIB. > > > > > > That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's > > > tcpConnectionInfoTable, could be moved to one of the tables in the > > > TCP-ESTATS-MIB. We will be looking into implementing the > TCP-ESTATS-MIB > > > in the future in order to support additional information for TCP > > > connections. Since the TCP-ESTATS-MIB is in the final approval > stages, > > > maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's > > > table in the future, as an updated version of the MIB module. Or, > maybe > > > they should be added to the TCP-MIB's tcpConnectionTable? > > > > > > Unfortunately, I don't think any IETF group is working on an extended > > > statistics MIB module for UDP endpoints. If we create a MIB table > with a > > > general name like, udpEndpointInfoTable, then you would expect that > any > > > other additional management data for UDP endpoints would be added to > this > > > table. Instead, maybe it would be better to either add the UDP > Creation > > > MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename > the > > > udpEndpointInfoTable to something more specific, like > > > udpEndpointCreationTable. > > > > It would help people like me who did not follow any of this work if > > you can provide us the names of the documents in question. > > > > /js > > > > -- > > Juergen Schoenwaelder {International|Jacobs} University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > From tsvwg-bounces@ietf.org Fri Jan 12 13:27:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5R72-00027h-BU; Fri, 12 Jan 2007 13:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5R70-00026j-6V; Fri, 12 Jan 2007 13:26:46 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5R6w-0005Ay-OW; Fri, 12 Jan 2007 13:26:46 -0500 Received: from jurassic.eng.sun.com ([129.146.68.36]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CIQciR009960; Fri, 12 Jan 2007 11:26:38 -0700 (MST) Received: from [192.9.61.43] (punchin-client-192-9-61-43.SFBay.Sun.COM [192.9.61.43]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0CIQbh6720079; Fri, 12 Jan 2007 10:26:37 -0800 (PST) Message-ID: <45A7D1DA.3020302@sun.com> Date: Fri, 12 Jan 2007 10:22:18 -0800 From: Anders Persson User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: Matt Mathis Subject: Re: [Tsvwg] Re: [IETFMIBS] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: j.schoenwaelder@iu-bremen.de, tsvwg@ietf.org, dthaler@windows.microsoft.com, Alain_Durand@cable.comcast.com, Kristine Adamson , ietfmibs@ietf.org, Paul_Schauer@cable.comcast.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Matt Mathis wrote: > If there is not a technical problem with two tables that AUGMENT the same base > table, I strongly advocate advancing the documents separately. ESTATS mib is > almost ready for the RFC editor queue. -mib-issue- is not even a WG item yet, > and may or may not converge quickly. I really don't want to reopen ESTATS > mib for lots of new revisions at this time. > > That said, the issues raised in -mib-issue- are real. We were aware of them > but (mistakenly?) believed that there did not exist a standardizable OS > independent solution. I would like to see this work proceed, but not at the > cost of stalling ESTATS. > I agree that advancing the documents separately is best way moving forward. However, maintaining two separate documents might also lead to some objects being duplicated (i.e., creation time). Anders > Thanks, > --MM-- > > On Fri, 12 Jan 2007, Kristine Adamson wrote: > > >> Juergen, >> Sorry for the confusion. The current draft of the TCP-ESTATS-MIB is >> at: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-14.txt >> >> The TCP/UDP Process MIB draft is at: >> http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt >> >> Kristine Adamson >> IBM z/OS Communications Server: TCP/IP Development >> Phone: (919) 254-7911 T/L 444-7911 >> Internet e-mail:adamson@us.ibm.com >> >> >> Juergen Schoenwaelder wrote on 01/12/2007 >> 08:13:50 AM: >> >> >>> On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote: >>> >>>> I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended >>>> Statistics MIB because I work on an IBM product's SNMP support. As >>>> >> far as >> >>>> I am aware, you may have more than one "augmenting" table which >>>> >> augments a >> >>>> base table. But an augmenting table can not itself be a base table. I >>>> >> am >> >>>> copying the MIB mailing list for any additional feedback. >>>> >>>> So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) >>>> >> and >> >>>> the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment >>>> >> the >> >>>> tcpConnectionTable in the TCP-MIB. >>>> >>>> That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's >>>> tcpConnectionInfoTable, could be moved to one of the tables in the >>>> TCP-ESTATS-MIB. We will be looking into implementing the >>>> >> TCP-ESTATS-MIB >> >>>> in the future in order to support additional information for TCP >>>> connections. Since the TCP-ESTATS-MIB is in the final approval >>>> >> stages, >> >>>> maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's >>>> table in the future, as an updated version of the MIB module. Or, >>>> >> maybe >> >>>> they should be added to the TCP-MIB's tcpConnectionTable? >>>> >>>> Unfortunately, I don't think any IETF group is working on an extended >>>> statistics MIB module for UDP endpoints. If we create a MIB table >>>> >> with a >> >>>> general name like, udpEndpointInfoTable, then you would expect that >>>> >> any >> >>>> other additional management data for UDP endpoints would be added to >>>> >> this >> >>>> table. Instead, maybe it would be better to either add the UDP >>>> >> Creation >> >>>> MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename >>>> >> the >> >>>> udpEndpointInfoTable to something more specific, like >>>> udpEndpointCreationTable. >>>> >>> It would help people like me who did not follow any of this work if >>> you can provide us the names of the documents in question. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder {International|Jacobs} University Bremen >>> P.O. Box 750 561, 28725 Bremen, >>> >> Germany >> >> > > From tsvwg-bounces@ietf.org Fri Jan 12 15:51:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TMB-0004E6-KO; Fri, 12 Jan 2007 15:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5TM9-0004CA-A3; Fri, 12 Jan 2007 15:50:33 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5TM6-0004u2-Tj; Fri, 12 Jan 2007 15:50:33 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OGwJYA89z234FGJILInH1k/MqVahTJ77HthnZoqLMxUiWqhWLDCHxWjYWD8AMF7Q; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.174.169] (helo=earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H5TM4-0003Ha-OR; Fri, 12 Jan 2007 15:50:29 -0500 Message-ID: <45A7F36A.56353316@earthlink.net> Date: Fri, 12 Jan 2007 12:45:30 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: weddy@grc.nasa.gov Subject: Re: [Tsvwg] review solicitation for ICCRG congestion control survey References: <20070111155541.GA25291@grc.nasa.gov> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec795da1b9a247d4490227bd326f48142608350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.174.169 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, tsvwg@ietf.org, iccrg@cs.ucl.ac.uk, dccp@ietf.org, tsv-area@ietf.org, rmt@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Authors, Layout/per RFC question, Can I suggest a different per RFC layout. In my opinion, each RFC listing item should include the type of RFC, the date, the first author, and then the abstract. To give a different summary than the abstract is inconsistent to what was initially published for the RFC and may change the meaning of the abstract than what the authors intended. If the abstract is missing, then I could agree that a substitute description be given in this doc. If the abstract is "too long" or missing, I would think that a shortened version in this document with a preword that this doc may contain a shortened abstract, new, or different of the mentioned of the RFC and that has been approved by the RFC authors. Mitchell Erblich --------------- Wesley Eddy wrote: > > In the ICCRG's goal to foster a long-term congestion control > architecture for the Internet, its initial step is to understand all of > the current mechanisms in use. As an aid to this, the ICCRG is working > on a document that summarizes all of the congestion control mechanisms > and other guidance that the IETF has produced and published in the RFC > series. The initial version of this document is online: > http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt > > We think this is a fairly complete listing of the RFCs that relate to > congestion control, but if you know of others that should be included, > we would like to hear about it. > > Also, comments on what can be done to make this more useful or readable > are welcome. Comments on and improvements to the text summarizing each > RFC are also welcome. > > The goal is to gather these inputs before the ICCRG meeting in > mid-February. After the ICCRG meeting, the document will be updated > based on these comments and discussion from the meeting. > > Please send all comments to the ICCRG list (iccrg@cs.ucl.ak.uk). Although > this request is being sent to multiple lists, this is only to notify > people not on the ICCRG list; we do not want to burden the other mailing > lists with replies, so please trim the "to" and "cc" fields of replies. > > Thanks in advance. > > -- > Wesley M. Eddy > Verizon Federal Network Systems From tsvwg-bounces@ietf.org Sat Jan 13 09:50:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kCl-0001tk-5s; Sat, 13 Jan 2007 09:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5MEL-0006dz-C0; Fri, 12 Jan 2007 08:14:01 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5MEI-0003sA-SB; Fri, 12 Jan 2007 08:14:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1E9055AD5B; Fri, 12 Jan 2007 14:13:58 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05109-02; Fri, 12 Jan 2007 14:13:54 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5356D5AD69; Fri, 12 Jan 2007 14:13:52 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 5C0B0997F19; Fri, 12 Jan 2007 14:13:51 +0100 (CET) Date: Fri, 12 Jan 2007 14:13:50 +0100 From: Juergen Schoenwaelder To: Kristine Adamson Message-ID: <20070112131350.GA24691@boskop.local> References: <213394AB6954BE4682E8B2A4910346834855CE@esebe108.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Sat, 13 Jan 2007 09:49:58 -0500 Cc: ietfmibs@ietf.org, tsvwg@ietf.org Subject: [Tsvwg] Re: [IETFMIBS] TCP Extended Statistics MIB, and v6ops TCP/UDP Process MIB X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Fri, Jan 12, 2007 at 06:07:43AM -0700, Kristine Adamson wrote: > I've worked with Matt Mathis a bit on the tsvwg group's TCP Extended > Statistics MIB because I work on an IBM product's SNMP support. As far as > I am aware, you may have more than one "augmenting" table which augments a > base table. But an augmenting table can not itself be a base table. I am > copying the MIB mailing list for any additional feedback. > > So, both the tcpEStatsConnectIdTable (from the tsvwg's TCP-ESTATS-MIB) and > the tcpConnectionInfoTable (from the v6ops' TCP-PROC-MIB) can augment the > tcpConnectionTable in the TCP-MIB. > > That said, maybe the TCP Creation MIB objects in the TCP-PROC-MIB's > tcpConnectionInfoTable, could be moved to one of the tables in the > TCP-ESTATS-MIB. We will be looking into implementing the TCP-ESTATS-MIB > in the future in order to support additional information for TCP > connections. Since the TCP-ESTATS-MIB is in the final approval stages, > maybe these MIB objects could be added to one of the TCP-ESTATS-MIB's > table in the future, as an updated version of the MIB module. Or, maybe > they should be added to the TCP-MIB's tcpConnectionTable? > > Unfortunately, I don't think any IETF group is working on an extended > statistics MIB module for UDP endpoints. If we create a MIB table with a > general name like, udpEndpointInfoTable, then you would expect that any > other additional management data for UDP endpoints would be added to this > table. Instead, maybe it would be better to either add the UDP Creation > MIB objects to the existing udpEndpointTable in the UDP-MIB, or rename the > udpEndpointInfoTable to something more specific, like > udpEndpointCreationTable. It would help people like me who did not follow any of this work if you can provide us the names of the documents in question. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany From tsvwg-bounces@ietf.org Mon Jan 15 02:24:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6MCC-0001Yv-9D; Mon, 15 Jan 2007 02:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6MCB-0001Yp-27 for tsvwg@ietf.org; Mon, 15 Jan 2007 02:23:55 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6MC9-0002LR-Fk for tsvwg@ietf.org; Mon, 15 Jan 2007 02:23:55 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0F7LVQc007626 for ; Mon, 15 Jan 2007 09:21:47 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 09:23:31 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 09:23:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Jan 2007 09:23:30 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0022_01C73886.D2120D40" Message-ID: <213394AB6954BE4682E8B2A4910346834B1856@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: mini-WGLC on draft-ietf-tsvwg-tcp-mib-extension-14 changes Thread-Index: Acc4dg6A4/X9LBQmSe6uGWqXsAtEFA== From: To: X-OriginalArrivalTime: 15 Jan 2007 07:23:31.0100 (UTC) FILETIME=[0EEC1DC0:01C73876] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Tsvwg] mini-WGLC on draft-ietf-tsvwg-tcp-mib-extension-14 changes X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C73886.D2120D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, in response to the DOWNREFs identified during IESG processing, the authors have posted draft-ietf-tsvwg-tcp-mib-extension-14. The main changes are: Downgrade references to RFCs 2861, 3260, 3522 and 3742 to informative. Removed tcpEStatsPathECNNonceRcvd, which instruments the algorithm described in RFC 3540, an experimental RFC that has recently come into question. There are no known, widely deployed implementations, and RFC 3540 conflicts with a recent proposal for a better use of the remaining IP header bits. The full diff is at http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-tcp-mib-extension/draft- ietf-tsvwg-tcp-mib-extension-14-from-13.diff.html We'd like to confirm that there is consensus in the WG to deal with the DOWNREFs in this way. Please send comments until Friday, Jan 19, 2007. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_0022_01C73886.D2120D40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE1MDcyMzMwWjAjBgkqhkiG 9w0BCQQxFgQU0812s97LaabZZTGeGV38ALVhk/8wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBACQiIWsE/xQHq7FHQhjNi5o+vkxrrvQlwpBY/yjm WPgVz9WzzWugO20P7724RWNTCCuJvRK2lcFav4EC+TC3LbwQC/y4CQO1tGcONfFZfCBZo2IIGYce EDAFyeOoFDAaN7kjhA/AyOYier/28pis6gsU7lecO2vlkrnJATZVopDgsygjG7ei6ExfLD0VmlfF 0mIzozjurhgE96xwPpY2SIjnfBJQKcBWJ2YWFh/oonAdeFybL9T36y/FldGCxH+9r2AYJ476BTC+ +KL4zdc6OxZTkGWW5iq7IVe8DinzzVS3hetq79MOUlaOOsHisN62ZrIme6OXnkRd8BTpkoj6TL0A AAAAAAA= ------=_NextPart_000_0022_01C73886.D2120D40-- From tsvwg-bounces@ietf.org Mon Jan 15 03:37:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NKO-0000GP-Aw; Mon, 15 Jan 2007 03:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NKN-0000G5-Ur for tsvwg@ietf.org; Mon, 15 Jan 2007 03:36:27 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6NKM-00054m-BU for tsvwg@ietf.org; Mon, 15 Jan 2007 03:36:27 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1869EF0C432 for ; Mon, 15 Jan 2007 05:36:16 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l0F8Zv2H027585 for ; Mon, 15 Jan 2007 05:36:14 -0300 Message-Id: <7.0.1.0.0.20070115051015.024519f0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 15 Jan 2007 05:14:14 -0300 To: tsvwg@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 15 Jan 2007 05:36:15 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Tsvwg] A couple of questions on ECN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Folks, I have a couple of questions on RFC 3168, on which maybe you can shed some light. On page 18 of RFC 3168 says: "After the source TCP reduces its congestion window in response to a CE packet, incoming acknowledgments that continue to arrive can "clock out" outgoing packets as allowed by the reduced congestion window. If the congestion window consists of only one MSS (maximum segment size), and the sending TCP receives an ECN-Echo ACK packet, then the sending TCP should in principle still reduce its congestion window in half. However, the value of the congestion window is bounded below by a value of one MSS. If the sending TCP were to continue to send, using a congestion window of 1 MSS, this results in the transmission of one packet per round-trip time. It is necessary to still reduce the sending rate of the TCP sender even further, on receipt of an ECN-Echo packet when the congestion window is one. We use the retransmit timer as a means of reducing the rate further in this circumstance. Therefore, the sending TCP MUST reset the retransmit timer on receiving the ECN-Echo packet when the congestion window is one. The sending TCP will then be able to send a new packet only when the retransmit timer expires." Question: What if, when cwnd=1, more than one ACK bit with the ECE bit set is received? Should there be a RTO backoff, or should the RTO be simply repeateadly reset? On page 36 RFC3168 says: If we assume that the first action taken at any "penalty box" for an ECN capable flow will be to drop packets instead of marking them, then there is no way that an adversary that subverts ECN-based end-to-end congestion control can cause a flow to be characterized as being non-cooperative and placed into a more severe action within the "penalty box". Comment: I'm probably misunderstanding this paragraph. But how about this. An attacker forges a number of TCP segments which transit the "penalty box". The penalty box first switches from marking to dropping, but the attacker continues sending forged segments, at a steady rate. If there's a more severe policy at the "penalty box" for flows that still do not respond to end-to-end congestion control after switching from marking to dropping, then the attacker could probably trigger that "more severe policy" this way. I guess the penalty box will never implement a policy such as "reset non-responding connections", though (?). Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tsvwg-bounces@ietf.org Mon Jan 15 11:01:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UGH-0000Dc-ET; Mon, 15 Jan 2007 11:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6UGE-0000CE-Ua for tsvwg@ietf.org; Mon, 15 Jan 2007 11:00:39 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6UGD-0000kO-Jl for tsvwg@ietf.org; Mon, 15 Jan 2007 11:00:38 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0FG0Zu15954 for ; Mon, 15 Jan 2007 11:00:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C738BE.3288103F" Date: Mon, 15 Jan 2007 10:59:53 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D50B668E34@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-tsvwg-diffserv-class-aggr-01 Thread-Index: Acc4vjHyDeEATOhFS7qE51GfXtdLgQ== From: "Marvin Krym" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Tsvwg] Comments on draft-ietf-tsvwg-diffserv-class-aggr-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C738BE.3288103F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following are my comments on "Aggregation of DiffServ Service Classes"; draft-ietf-tsvwg-diffserv-class-aggr-01. This is a resend of a message from December 20, 2006. In general the need for an aggregation rule for the DiffSer Service Classes (rfc4594) is clear especially in core networks. I agree with the specific aggregation recommendation and the methodology. The following are some specific comments. 1. Figure 2 recommends CS for the treatment aggregate behavior. Because the class selector code points have a notion of relative importance, then a specific CS should be chosen, namely, CS6. 2. Section 4.1.3 contains the recommendation for the assured elastic aggregate which aggregates CS2 and other AF code points. From Figure 2, it appears that CS2 should be treated as AFn1 in the aggregate and if so this should be made clear in the text. The treatment for only AFnx traffic is covered in the text. 3. The EXP markings include 2 codes for the Elastic aggregate behavior to account for CS0 and CS1. It seems inconsistent that we would have one treatment aggregate with one treatment behavior (i.e. Default) yet define two EXP code points. Regards Marvin ------_=_NextPart_001_01C738BE.3288103F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-tsvwg-diffserv-class-aggr-01

The following are my comments on = "Aggregation of DiffServ Service Classes"; = draft-ietf-tsvwg-diffserv-class-aggr-01.  This is a resend of a = message from December 20, 2006.

In general the need for an aggregation = rule for the DiffSer Service Classes (rfc4594) is clear especially in = core networks.  I agree with the specific aggregation = recommendation and the methodology.  The following are some = specific comments.

1. Figure 2 recommends CS for the = treatment aggregate behavior.  Because the class selector code = points have a notion of relative importance, then a specific CS should = be chosen, namely, CS6.

2. Section 4.1.3 contains the = recommendation for the assured elastic aggregate which aggregates CS2 = and other AF code points.  From Figure 2, it appears that CS2 = should be treated as AFn1 in the aggregate and if so this should be made = clear in the text.  The treatment for only AFnx traffic is covered = in the text.

3. The EXP markings include 2 codes for = the Elastic aggregate behavior to account for CS0 and CS1.  It = seems inconsistent that we would have one treatment aggregate with one = treatment behavior (i.e. Default) yet define two EXP code = points.

Regards
  Marvin

------_=_NextPart_001_01C738BE.3288103F-- From tsvwg-bounces@ietf.org Tue Jan 16 02:24:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ifa-0000Rs-EO; Tue, 16 Jan 2007 02:23:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ifZ-0000RW-3S for tsvwg@ietf.org; Tue, 16 Jan 2007 02:23:45 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ifX-0001CU-Ip for tsvwg@ietf.org; Tue, 16 Jan 2007 02:23:45 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0G7LLrt016685 for ; Tue, 16 Jan 2007 09:21:34 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 09:23:16 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 09:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Date: Tue, 16 Jan 2007 09:22:59 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_023F_01C7394F.E9D70150" Message-ID: <213394AB6954BE4682E8B2A4910346834DCD24@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Thread-Index: Acc5PyZB9jH4VsiFQ+anwhmNVUqdJQ== From: To: X-OriginalArrivalTime: 16 Jan 2007 07:23:16.0608 (UTC) FILETIME=[30B29000:01C7393F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_023F_01C7394F.E9D70150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Nov 14, 2006, at 5:48 AM, Magnus Westerlund wrote: > > Based on feedback from the TSVWG session in San Diego we think there > is consensus on adopting draft-davie-ecn-mpls as a TSVWG work item. We > are hereby confirming this consensus on the list. If you have an > opinion please state it. We haven't seen any responses arguing differently. To ensure no such responses where lost due to the recent mailing list problems: Please speak up now if you disagree with the call above. Otherwise we'll go ahead shortly and adopt this. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_023F_01C7394F.E9D70150 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE2MDcyMjU5WjAjBgkqhkiG 9w0BCQQxFgQUT4mxlLYGm97/QUiG1ezQY7TaZYEwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAIqMZ1YIMz6YKQ9JiySaQ1qdlAYEgElxpfpcktD9 RDNJ8828mJN+GyVaRak8uRrXiM/STdHAPWnbj5buuuwPGeXnoX8K9HZfpQvGOoNQ0gfWIEPyttTo ZvcgMf+Xz/Ww8lpxQsPHKejRjzxkYeueCjBQ8Zp2UlOpDElL9+Hto4j+bZ0ppgY4NwW7nEz+81Xa 3BpTrnDCicODDq4PUv7XaFA5YBrFuzDMkmEHw943SfC0ramURSzsRNq4o1TdgAlrXyzmoqsKRVdA E/PKq3m2N4Se5uldGT+O4IeKI0WmkHYflFGLT5Lm5K+W6RWGAjADo+6E86Y1srdcaZd6uyaedfMA AAAAAAA= ------=_NextPart_000_023F_01C7394F.E9D70150-- From tsvwg-bounces@ietf.org Tue Jan 16 08:19:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6oDs-0006N4-57; Tue, 16 Jan 2007 08:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6oDr-0006Mx-4V for tsvwg@ietf.org; Tue, 16 Jan 2007 08:19:31 -0500 Received: from adsl-070-155-160-098.sip.cae.bellsouth.net ([70.155.160.98] helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6oDn-0006Dh-Rq for tsvwg@ietf.org; Tue, 16 Jan 2007 08:19:29 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lakerest.net (8.13.6/8.13.6) with ESMTP id l0GDJO0K071523 for ; Tue, 16 Jan 2007 08:19:25 -0500 (EST) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1168953565; h=Message-ID:Date:From:User-Agent:MIME-Version:To: Subject:Content-Type:Content-Transfer-Encoding; b=FnxKpPnIHf9/kKdQ6 xv7Pm7AbLBerc8Avc+bw6xPYLQYRneevS+hBRe7Gn8cpD3GW7yJgKPFwBGI00FpzZzE Mw== Message-ID: <45ACD0A3.8040103@lakerest.net> Date: Tue, 16 Jan 2007 08:18:27 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: TSWG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Tsvwg] source port of 0 in TCP or UDP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi all: In looking at the IANA site you will find that port 0 for TCP or UDP is "reserved". Which implies that no application should be using it... But, what happens to an app that does? Should a stack be capable of dealing with port 0... aka allowing someone to bind it and then source/receive packet to/from it? This came up on a FreeBSD list.. and it makes me curious... Thoughts would be appreciated :-) R -- Randall Stewart 803-345-0369 815-342-5222(cell) From tsvwg-bounces@ietf.org Tue Jan 16 14:06:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tdQ-0005QJ-SU; Tue, 16 Jan 2007 14:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tdP-0005PQ-Ky for tsvwg@ietf.org; Tue, 16 Jan 2007 14:06:15 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tdO-0004M8-D4 for tsvwg@ietf.org; Tue, 16 Jan 2007 14:06:15 -0500 Received: from smtp2.fc.hp.com (smtp.fc.hp.com [15.11.136.114]) by atlrel7.hp.com (Postfix) with ESMTP id C278A34C0D; Tue, 16 Jan 2007 14:06:13 -0500 (EST) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp2.fc.hp.com (Postfix) with ESMTP id 27D8316315D; Tue, 16 Jan 2007 19:06:13 +0000 (UTC) Message-ID: <45AD2224.7000002@hp.com> Date: Tue, 16 Jan 2007 14:06:12 -0500 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: Randall Stewart Subject: Re: [Tsvwg] source port of 0 in TCP or UDP References: <45ACD0A3.8040103@lakerest.net> In-Reply-To: <45ACD0A3.8040103@lakerest.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Randall Stewart wrote: > Hi all: > > In looking at the IANA site you will find that > port 0 for TCP or UDP is "reserved". > > Which implies that no application should be > using it... > > But, what happens to an app that does? > > Should a stack be capable of dealing with port 0... aka > allowing someone to bind it and then source/receive packet > to/from it? > Randall All implementation I know treat port 0 as ephemeral and pick a random port. So how would one go about binding to it? Is that a problem that came up? -vlad > This came up on a FreeBSD list.. and it makes me curious... > > Thoughts would be appreciated :-) > > R From tsvwg-bounces@ietf.org Tue Jan 16 15:26:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6usP-00089g-VK; Tue, 16 Jan 2007 15:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6usO-00089T-SK for tsvwg@ietf.org; Tue, 16 Jan 2007 15:25:48 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6usM-0000NX-AY for tsvwg@ietf.org; Tue, 16 Jan 2007 15:25:48 -0500 Received: from [192.168.1.3] (p508FFFCB.dip.t-dialin.net [80.143.255.203]) by mail-n.franken.de (Postfix) with ESMTP id 668EC80000B7; Tue, 16 Jan 2007 21:25:37 +0100 (CET) (KNF-authenticated sender: macmic) In-Reply-To: <45AD2224.7000002@hp.com> References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] source port of 0 in TCP or UDP Date: Tue, 16 Jan 2007 21:25:32 +0100 To: Vlad Yasevich X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Vlad, it is important to distinguish between the port number in the sockaddr_in and sockaddr_in6 structures and the port numbers being used in the transport protocol headers. The IANA list is about the port numbers used in the transport protocol headers. In the API 0 has a special meaning when, for example, calling bind(): It tells the operating system to choose an ephemeral port. This does not mean that 0 is considered ephemeral by the operating system. Best regards Michael On Jan 16, 2007, at 8:06 PM, Vlad Yasevich wrote: > Randall Stewart wrote: >> Hi all: >> >> In looking at the IANA site you will find that >> port 0 for TCP or UDP is "reserved". >> >> Which implies that no application should be >> using it... >> >> But, what happens to an app that does? >> >> Should a stack be capable of dealing with port 0... aka >> allowing someone to bind it and then source/receive packet >> to/from it? >> > > Randall > > All implementation I know treat port 0 as ephemeral and pick a > random port. So how would one go about binding to it? Is that a > problem > that came up? > > -vlad > >> This came up on a FreeBSD list.. and it makes me curious... >> >> Thoughts would be appreciated :-) >> >> R > > > From tsvwg-bounces@ietf.org Tue Jan 16 15:48:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vEX-0003FU-Oo; Tue, 16 Jan 2007 15:48:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vEW-0003FN-QF for tsvwg@ietf.org; Tue, 16 Jan 2007 15:48:40 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vEV-00041T-H3 for tsvwg@ietf.org; Tue, 16 Jan 2007 15:48:40 -0500 Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id D43DA353E4; Tue, 16 Jan 2007 15:48:38 -0500 (EST) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp1.fc.hp.com (Postfix) with ESMTP id EC1EF12C80B; Tue, 16 Jan 2007 20:48:37 +0000 (UTC) Message-ID: <45AD3A25.3090804@hp.com> Date: Tue, 16 Jan 2007 15:48:37 -0500 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] source port of 0 in TCP or UDP References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> In-Reply-To: <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Michael Michael Tuexen wrote: > Hi Vlad, > > it is important to distinguish between the port number in the > sockaddr_in and sockaddr_in6 structures and the port numbers > being used in the transport protocol headers. > > The IANA list is about the port numbers used in the transport > protocol headers. > > In the API 0 has a special meaning when, for example, calling bind(): > It tells the operating system to choose an ephemeral port. > This does not mean that 0 is considered ephemeral by the operating > system. Understood, but if there is no API to specify port 0 to the operating systems then how would an application go about (ab)using it? I don't see anything awful happening if port 0 is used. In fact, I have seen this happen inadvertently (was a bug that was fixed), but it didn't result in any problems. -vlad > > Best regards > Michael > > On Jan 16, 2007, at 8:06 PM, Vlad Yasevich wrote: > >> Randall Stewart wrote: >>> Hi all: >>> >>> In looking at the IANA site you will find that >>> port 0 for TCP or UDP is "reserved". >>> >>> Which implies that no application should be >>> using it... >>> >>> But, what happens to an app that does? >>> >>> Should a stack be capable of dealing with port 0... aka >>> allowing someone to bind it and then source/receive packet >>> to/from it? >>> >> >> Randall >> >> All implementation I know treat port 0 as ephemeral and pick a >> random port. So how would one go about binding to it? Is that a problem >> that came up? >> >> -vlad >> >>> This came up on a FreeBSD list.. and it makes me curious... >>> >>> Thoughts would be appreciated :-) >>> >>> R >> >> >> > From tsvwg-bounces@ietf.org Tue Jan 16 16:12:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vbB-0003FI-3v; Tue, 16 Jan 2007 16:12:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vb9-0003FA-Ts for tsvwg@ietf.org; Tue, 16 Jan 2007 16:12:03 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vb7-0007Q5-BN for tsvwg@ietf.org; Tue, 16 Jan 2007 16:12:03 -0500 Received: from [192.168.1.3] (p508FF947.dip.t-dialin.net [80.143.249.71]) by mail-n.franken.de (Postfix) with ESMTP id E5F5480000AC; Tue, 16 Jan 2007 22:11:59 +0100 (CET) (KNF-authenticated sender: macmic) In-Reply-To: <45AD3A25.3090804@hp.com> References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> <45AD3A25.3090804@hp.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] source port of 0 in TCP or UDP Date: Tue, 16 Jan 2007 22:11:59 +0100 To: Vlad Yasevich X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Jan 16, 2007, at 9:48 PM, Vlad Yasevich wrote: > Michael > > Michael Tuexen wrote: >> Hi Vlad, >> >> it is important to distinguish between the port number in the >> sockaddr_in and sockaddr_in6 structures and the port numbers >> being used in the transport protocol headers. >> >> The IANA list is about the port numbers used in the transport >> protocol headers. >> >> In the API 0 has a special meaning when, for example, calling bind(): >> It tells the operating system to choose an ephemeral port. >> This does not mean that 0 is considered ephemeral by the operating >> system. > > Understood, but if there is no API to specify port 0 to the > operating systems > then how would an application go about (ab)using it? > > I don't see anything awful happening if port 0 is used. In fact, I > have > seen this happen inadvertently (was a bug that was fixed), but it > didn't > result in any problems. Since you can not bind to port zero, how can you accept connections on an end-point with port 0 or how can you send a packet from port 0? > > -vlad > >> >> Best regards >> Michael >> >> On Jan 16, 2007, at 8:06 PM, Vlad Yasevich wrote: >> >>> Randall Stewart wrote: >>>> Hi all: >>>> >>>> In looking at the IANA site you will find that >>>> port 0 for TCP or UDP is "reserved". >>>> >>>> Which implies that no application should be >>>> using it... >>>> >>>> But, what happens to an app that does? >>>> >>>> Should a stack be capable of dealing with port 0... aka >>>> allowing someone to bind it and then source/receive packet >>>> to/from it? >>>> >>> >>> Randall >>> >>> All implementation I know treat port 0 as ephemeral and pick a >>> random port. So how would one go about binding to it? Is that a >>> problem >>> that came up? >>> >>> -vlad >>> >>>> This came up on a FreeBSD list.. and it makes me curious... >>>> >>>> Thoughts would be appreciated :-) >>>> >>>> R >>> >>> >>> >> > > From tsvwg-bounces@ietf.org Tue Jan 16 16:25:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vno-0005dR-U0; Tue, 16 Jan 2007 16:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vnn-0005dL-Ca for tsvwg@ietf.org; Tue, 16 Jan 2007 16:25:07 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vnm-0000Ys-3f for tsvwg@ietf.org; Tue, 16 Jan 2007 16:25:07 -0500 Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel7.hp.com (Postfix) with ESMTP id 3F544359F1; Tue, 16 Jan 2007 16:25:03 -0500 (EST) Received: from [16.116.113.226] (galen.zko.hp.com [16.116.113.226]) by smtp2.fc.hp.com (Postfix) with ESMTP id 95B621626F8; Tue, 16 Jan 2007 21:24:57 +0000 (UTC) Message-ID: <45AD42A8.80301@hp.com> Date: Tue, 16 Jan 2007 16:24:56 -0500 From: Vlad Yasevich User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] source port of 0 in TCP or UDP References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> <45AD3A25.3090804@hp.com> <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> In-Reply-To: <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Michael Tuexen wrote: > On Jan 16, 2007, at 9:48 PM, Vlad Yasevich wrote: > >> Michael >> >> Michael Tuexen wrote: >>> Hi Vlad, >>> >>> it is important to distinguish between the port number in the >>> sockaddr_in and sockaddr_in6 structures and the port numbers >>> being used in the transport protocol headers. >>> >>> The IANA list is about the port numbers used in the transport >>> protocol headers. >>> >>> In the API 0 has a special meaning when, for example, calling bind(): >>> It tells the operating system to choose an ephemeral port. >>> This does not mean that 0 is considered ephemeral by the operating >>> system. >> >> Understood, but if there is no API to specify port 0 to the operating >> systems >> then how would an application go about (ab)using it? >> >> I don't see anything awful happening if port 0 is used. In fact, I have >> seen this happen inadvertently (was a bug that was fixed), but it didn't >> result in any problems. > Since you can not bind to port zero, how can you accept connections on > an end-point with port 0 or how can you send a packet from port 0? In that specific case, it was a bug in that port 0 ended up being actually used to establish the connection. As a result, everything worked, but packet captures showed port 0. -vlad From tsvwg-bounces@ietf.org Tue Jan 16 16:26:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vp2-0006D8-Ey; Tue, 16 Jan 2007 16:26:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vp1-0006D2-PW for tsvwg@ietf.org; Tue, 16 Jan 2007 16:26:23 -0500 Received: from tosh.netlab.uky.edu ([128.163.140.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6voz-0000kv-E3 for tsvwg@ietf.org; Tue, 16 Jan 2007 16:26:23 -0500 Received: from ozark.netlab.uky.edu (ozark.netlab.uky.edu [128.163.140.219]) by tosh.netlab.uky.edu (Postfix) with ESMTP id 8EA3F66819C for ; Tue, 16 Jan 2007 16:26:20 -0500 (EST) Date: Tue, 16 Jan 2007 16:26:20 -0500 (EST) From: Ken Calvert To: TSWG Subject: Re: [Tsvwg] source port of 0 in TCP or UDP In-Reply-To: <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> Message-ID: References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org > it is important to distinguish between the port number in the > sockaddr_in and sockaddr_in6 structures and the port numbers > being used in the transport protocol headers. > > The IANA list is about the port numbers used in the transport > protocol headers. > > In the API 0 has a special meaning when, for example, calling bind(): > It tells the operating system to choose an ephemeral port. > This does not mean that 0 is considered ephemeral by the operating > system. Probably everybody here knows this, but... I believe the value 0 was used in some well-known implementations as the "wildcard" value in socket data structures. The packet-demux routine match a 0 in a socket's "remote port" field with any incoming port number. If 0 became a legitimate port number, the demux algorithm would need to be modified to distinguish between "wildcard" and the actual value "0". KC -- Ken Calvert, Associate Professor Lab for Advanced Networking calvert@netlab.uky.edu University of Kentucky Tel: +1.859.257.6745 Hardymon Building, 2nd Floor Fax: +1.859.323.1971 301 Rose Street http://www.cs.uky.edu/~calvert/ Lexington, KY 40506-0495 From tsvwg-bounces@ietf.org Tue Jan 16 17:00:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wLa-0000Re-Cd; Tue, 16 Jan 2007 17:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wLZ-0000M6-06 for tsvwg@ietf.org; Tue, 16 Jan 2007 17:00:01 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wLX-0006OZ-Ou for tsvwg@ietf.org; Tue, 16 Jan 2007 17:00:00 -0500 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.244.56.217]) by palrel13.hp.com (Postfix) with ESMTP id 2EE423523C; Tue, 16 Jan 2007 13:59:57 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id NAA02848; Tue, 16 Jan 2007 13:59:56 -0800 (PST) Message-ID: <45AD4ADC.8070402@hp.com> Date: Tue, 16 Jan 2007 13:59:56 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.7.13) Gecko/20060601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] source port of 0 in TCP or UDP References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> <45AD3A25.3090804@hp.com> <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> In-Reply-To: <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Vlad Yasevich , TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org while existing/known api's provide no way to bind to port zero, i suspect one shouldn't ass-u-me that means one will never have an API or other mechanism which makes it possible? rick jones apologies if this missive from the peanut gallery has already been noted From tsvwg-bounces@ietf.org Tue Jan 16 17:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wVT-0006QF-IT; Tue, 16 Jan 2007 17:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wVS-0006LK-2i for tsvwg@ietf.org; Tue, 16 Jan 2007 17:10:14 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wVQ-0000GN-Le for tsvwg@ietf.org; Tue, 16 Jan 2007 17:10:14 -0500 Received: from ns.pigworks.openss7.net (IDENT:UwwfQFD71qquhQ+dGhQx1BIadhETZAJA@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l0GMA9Z24001; Tue, 16 Jan 2007 15:10:09 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l0GMA9v09845; Tue, 16 Jan 2007 15:10:09 -0700 Date: Tue, 16 Jan 2007 15:10:08 -0700 From: "Brian F. G. Bidulock" To: Rick Jones Subject: Re: [Tsvwg] source port of 0 in TCP or UDP Message-ID: <20070116151008.A9457@openss7.org> Mail-Followup-To: Rick Jones , Michael Tuexen , Vlad Yasevich , TSWG , Randall Stewart References: <45ACD0A3.8040103@lakerest.net> <45AD2224.7000002@hp.com> <6763EB1A-FDCD-4E67-938C-70391BF74214@lurchi.franken.de> <45AD3A25.3090804@hp.com> <47955826-1000-4E85-8E08-C4129CB2A738@lurchi.franken.de> <45AD4ADC.8070402@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45AD4ADC.8070402@hp.com>; from rick.jones2@hp.com on Tue, Jan 16, 2007 at 01:59:56PM -0800 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Vlad Yasevich , Michael Tuexen , TSWG , Randall Stewart X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Rick, That's what I do: both the OpenSS7 sockets and STREAMS implementations will accept a connection _from_ port 0, even though binding to port 0 will dynamically allocate a port number, and attempting to connect _to_ port 0 will yield EBADADDR or EADDRNOTAVAIL (depending on the interface). --brian Rick Jones wrote: (Tue, 16 Jan 2007 13:59:56) > while existing/known api's provide no way to bind to port zero, i > suspect one shouldn't ass-u-me that means one will never have an API or > other mechanism which makes it possible? > > rick jones > apologies if this missive from the peanut gallery has already been noted -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From tsvwg-bounces@ietf.org Wed Jan 17 05:24:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77xu-0002DN-8g; Wed, 17 Jan 2007 05:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77xt-0002Cn-33 for tsvwg@ietf.org; Wed, 17 Jan 2007 05:24:21 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77xq-0003Li-D0 for tsvwg@ietf.org; Wed, 17 Jan 2007 05:24:21 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0HAOLwh003158; Wed, 17 Jan 2007 11:24:21 +0100 To: Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Wed, 17 Jan 2007 11:24:13 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/17/2007 11:24:14 Content-Type: multipart/mixed; boundary="=_mixed 003926BBC1257266_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --=_mixed 003926BBC1257266_= Content-Type: text/plain; charset="US-ASCII" discussion was led on the list mid november - no real conclusion or action where derived from the concerns expressed at that time - note that the first point is not at all an issue about process (discussion slides during MPLS WG meetings without feedback and certainly no conclusion simply does not ensure a safe path) - another question is around value/functionality vs the overhead in putting such fct at MPLS level (being by definition a fwd'ing paradigm, bind to the end-to-end networking paradigm of IP) - see below for the details - Bruce Davie 15/11/2006 13:55 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Magnus Westerlund , tsvwg Subject: Re: [Tsvwg] Re: [mpls] Making draft-davie-ecn-mpls a TSVWG item On Nov 14, 2006, at 6:07 PM, Dimitri.Papadimitriou@alcatel.be wrote: > hi - > > 1. CN marking in the EXP bits of the MPLS header falls imho under the > MPLS change process that states for an optional problem statement and > a mandatory prior requirements statement I-D to commit for any > specific > change or extension to MPLS > > see section 2.1.1 and 4.2 of > > change-06.txt> > I'll let the ADs and WG chairs argue about the process issue you've raised, but I do have a comment on the following: > 2. on one side there is a PCN BoF during previous meeting on the other > the document uses PCN as motivation for copying the CE state into > outer > header at ingress - if found this rather circular as reasoning > where is > the real "problem statement" outside PCN scope for such operation ? I wonder if perhaps you have not read the latest (-01) version of draft-davie-ecn-mpls [dp] i read that version - my remark refers to section 7. in that section it seems that the inner->outer CE is driven by PCN needs (also part of the discussion slides) You will notice that the abstract does not mention PCN, and that the list of changes from the last draft includes this statement: o Pre-congestion notification (PCN) marking is now described in a way that does not require normative references to PCN specifications. PCN discussion now serves only to illustrate how the ECN marking concepts can be extended to cover more complex scenarios, with PCN being an example. The motivation for this work is to prevent ECN from being broken when traversing an MPLS network. That seems sufficient motivation for the draft whether or not PCN becomes a problem that the IETF wants to work on. [dp] the same section 7 mentions "[RFC3168] does not give any reasons against conveying CE information from the inner header to the outer in the "full functionality" mode." nor the other way around - which leaves the point open for ECN itself -> the issue i am raising is that in absence of evidence current the processing should be left per RFC3168 and not inline with the expected PCN needs (even if it does not affect the former) -d. > > thanks, > - d. > > > > > > Magnus Westerlund > 14/11/2006 11:48 > > To: tsvwg > cc: > Subject: [mpls] Making draft-davie-ecn-mpls a TSVWG > item > > > Hi, > (BCC MPLS for information) > > Based on feedback from the TSVWG session in San Diego we think > there is > consensus on adopting draft-davie-ecn-mpls as a TSVWG work item. We > are > hereby confirming this consensus on the list. If you have an opinion > please state it. > > Cheers > > Magnus Westerlund > TSVWG chair > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > 16/01/2007 08:22 To: cc: Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item < Attachment smime.p7s removed > On Nov 14, 2006, at 5:48 AM, Magnus Westerlund wrote: > > Based on feedback from the TSVWG session in San Diego we think there > is consensus on adopting draft-davie-ecn-mpls as a TSVWG work item. We > are hereby confirming this consensus on the list. If you have an > opinion please state it. We haven't seen any responses arguing differently. To ensure no such responses where lost due to the recent mailing list problems: Please speak up now if you disagree with the call above. Otherwise we'll go ahead shortly and adopt this. Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com --=_mixed 003926BBC1257266_= Content-Type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE2MDcyMjU5WjAjBgkqhkiG 9w0BCQQxFgQUT4mxlLYGm97/QUiG1ezQY7TaZYEwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAIqMZ1YIMz6YKQ9JiySaQ1qdlAYEgElxpfpcktD9 RDNJ8828mJN+GyVaRak8uRrXiM/STdHAPWnbj5buuuwPGeXnoX8K9HZfpQvGOoNQ0gfWIEPyttTo ZvcgMf+Xz/Ww8lpxQsPHKejRjzxkYeueCjBQ8Zp2UlOpDElL9+Hto4j+bZ0ppgY4NwW7nEz+81Xa 3BpTrnDCicODDq4PUv7XaFA5YBrFuzDMkmEHw943SfC0ramURSzsRNq4o1TdgAlrXyzmoqsKRVdA E/PKq3m2N4Se5uldGT+O4IeKI0WmkHYflFGLT5Lm5K+W6RWGAjADo+6E86Y1srdcaZd6uyaedfMA AAAAAAA= --=_mixed 003926BBC1257266_=-- From tsvwg-bounces@ietf.org Thu Jan 18 04:30:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7TaB-00085T-NO; Thu, 18 Jan 2007 04:29:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KVU-0003q1-IH for tsvwg@ietf.org; Wed, 17 Jan 2007 18:47:52 -0500 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7KVT-0008BU-CZ for tsvwg@ietf.org; Wed, 17 Jan 2007 18:47:52 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 3CD561667; Wed, 17 Jan 2007 18:47:49 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on louie.udel.edu X-Spam-Level: X-Spam-Status: No, score=-14.4 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00, LOCAL_AUTH_RCVD autolearn=ham version=3.1.7 Received: from [128.175.192.158] (roaming-192-158.nss.udel.edu [128.175.192.158]) (Authenticated sender: nataraja@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id CB8CF1660 for ; Wed, 17 Jan 2007 18:47:48 -0500 (EST) Message-ID: <45AEB59F.2010909@cis.udel.edu> Date: Wed, 17 Jan 2007 18:47:43 -0500 From: Preethi Natarajan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) To: TSWG X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Thu, 18 Jan 2007 04:29:18 -0500 Subject: [Tsvwg] SCTP stream information X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hello all, Is it possible to get advance information on the SCTP stream in which the next sctp_recvmsg() will return data from? I.e., the application gets to know the SCTP stream on which data will be received before doing the sctp_recvmsg(). -- Regards, Preethi From tsvwg-bounces@ietf.org Thu Jan 18 05:39:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ufc-0003LV-OD; Thu, 18 Jan 2007 05:39:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ufb-0003LJ-6l for tsvwg@ietf.org; Thu, 18 Jan 2007 05:38:59 -0500 Received: from gw.openss7.com ([142.179.199.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7UfY-0002AC-Q0 for tsvwg@ietf.org; Thu, 18 Jan 2007 05:38:59 -0500 Received: from ns.pigworks.openss7.net (IDENT:ZynkRSoqSrwHuKsX5LKaYXreq2g7W1ew@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l0IActZ29488; Thu, 18 Jan 2007 03:38:55 -0700 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l0IActn04994; Thu, 18 Jan 2007 03:38:55 -0700 Date: Thu, 18 Jan 2007 03:38:55 -0700 From: "Brian F. G. Bidulock" To: Preethi Natarajan Subject: Re: [Tsvwg] SCTP stream information Message-ID: <20070118033855.A4856@openss7.org> Mail-Followup-To: Preethi Natarajan , TSWG References: <45AEB59F.2010909@cis.udel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45AEB59F.2010909@cis.udel.edu>; from nataraja@cis.udel.edu on Wed, Jan 17, 2007 at 06:47:43PM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Preethi, MSG_PEEK ? (Albeit costly.) --brian Preethi Natarajan wrote: (Wed, 17 Jan 2007 18:47:43) > Hello all, > > Is it possible to get advance information on the SCTP stream in which > the next sctp_recvmsg() will return data from? I.e., the application > gets to know the SCTP stream on which data will be received before doing > the sctp_recvmsg(). > > -- > > Regards, > Preethi > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From tsvwg-bounces@ietf.org Thu Jan 18 05:44:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ukp-0006FQ-PF; Thu, 18 Jan 2007 05:44:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Uko-0006FL-MP for tsvwg@ietf.org; Thu, 18 Jan 2007 05:44:22 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Ukn-00033D-0A for tsvwg@ietf.org; Thu, 18 Jan 2007 05:44:22 -0500 Received: from [192.168.1.3] (p508FD03C.dip.t-dialin.net [80.143.208.60]) by mail-n.franken.de (Postfix) with ESMTP id 859A0800008B; Thu, 18 Jan 2007 11:44:10 +0100 (CET) (KNF-authenticated sender: macmic) In-Reply-To: <45AEB59F.2010909@cis.udel.edu> References: <45AEB59F.2010909@cis.udel.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] SCTP stream information Date: Thu, 18 Jan 2007 11:44:08 +0100 To: Preethi Natarajan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi, it looks like you are looking for 5.2.3. Extended SCTP Header Information Structure (SCTP_EXTRCV) This cmsghdr structure specifies SCTP options for SCTP header information about a received message via recvmsg(). Note that this structure is an extended version of SCTP_SNDRCV and will only be received if the user has set the socket option SCTP_USE_EXT_RCVINFO to true in addition to any event subscription needed to receive ancillary data.. cmsg_level cmsg_type cmsg_data[] ------------ ------------ ---------------------- IPPROTO_SCTP SCTP_SNDRCV struct sctp_sndrcvinfo Here is the definition of sctp_sndrcvinfo: struct sctp_extrcvinfo { uint16_t sinfo_stream; uint16_t sinfo_ssn; uint16_t sinfo_flags; uint32_t sinfo_ppid; uint32_t sinfo_context; uint32_t sinfo_timetolive; uint32_t sinfo_tsn; uint32_t sinfo_cumtsn; sctp_assoc_t sinfo_assoc_id; uint16_t next_flags; uint16_t next_stream; uint32_t next_asocid; uint32_t next_length; uint32_t next_ppid; }; from http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- sctpsocket-14.txt Best regards Michael On Jan 18, 2007, at 12:47 AM, Preethi Natarajan wrote: > Hello all, > > Is it possible to get advance information on the SCTP stream in > which the next sctp_recvmsg() will return data from? I.e., the > application gets to know the SCTP stream on which data will be > received before doing the sctp_recvmsg(). > > -- > > Regards, > Preethi > > > From tsvwg-bounces@ietf.org Thu Jan 18 05:56:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Uvz-0004QA-4t; Thu, 18 Jan 2007 05:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Uv9-0003Fi-Cr for tsvwg@ietf.org; Thu, 18 Jan 2007 05:55:03 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Uq5-0003xq-Uy for tsvwg@ietf.org; Thu, 18 Jan 2007 05:49:51 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0IAltGB014945; Thu, 18 Jan 2007 12:48:04 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 12:49:32 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 12:49:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Date: Thu, 18 Jan 2007 12:49:31 +0200 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_02C4_01C73AFF.18A0A080" Message-ID: <213394AB6954BE4682E8B2A4910346835295D7@esebe108.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Thread-Index: Acc6Iapicuh+cyrfSBm5oUWfuMlaiQAy64yg From: To: X-OriginalArrivalTime: 18 Jan 2007 10:49:31.0721 (UTC) FILETIME=[55AA7390:01C73AEE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02C4_01C73AFF.18A0A080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dimitri, > discussion was led on the list mid november - no real > conclusion or action where derived from the concerns > expressed at that time thanks for pointing out that this draft was also discussed elsewhere! As for your specific points: > > 1. CN marking in the EXP bits of the MPLS header falls imho under the > > MPLS change process that states for an optional problem statement and > > a mandatory prior requirements statement I-D to commit for any > > specific change or extension to MPLS > > > > see section 2.1.1 and 4.2 of > > The process described in that document isn't official procedure yet, and has raised significant concern in parts of the IESG. IMO it is unlikely to proceed without major changes. Hence, it's questionable that we should apply it here and now. > [dp] the same section 7 mentions > > "[RFC3168] does not give any reasons against conveying CE information > from the inner header to the outer in the "full functionality" mode." > > nor the other way around - which leaves the point open for ECN itself > -> the issue i am raising is that in absence of evidence current the > processing should be left per RFC3168 and not inline with the expected > PCN needs (even if it does not affect the former) I'm not quite sure I understand your point - are you saying that the benefits of ECN for MPLS are unclear? Thanks, Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_02C4_01C73AFF.18A0A080 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE4MTA0OTMwWjAjBgkqhkiG 9w0BCQQxFgQUe6x0QlkFoKGNtaoaOOIYmNR/FxEwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAKciKq8x6JlGuvAKrdd5RVoCesYKJfVlYlm61NXp sokmLwBffirpXBqZ7XuxXyLq2tExJDH0NyLOy4pniHBqrD3dx1e2mwxaW5q91qVuqo9GLNgH+JXI kouTWfOiXXSuBoSQ/jQvlngWoI1tw3RU3SYNUO3I4HBOUw6aNmfKc9dPslV2G2VsXm9+5KChlfqb OWue3KDiN2y/UUOhnpsp/HP95AymRRX4z6631PYRrCEz5cEWqaM8Zk5WeqWM2eyMJJje7HMm6Ryk L6pDKMjJaZzsEdvqaJ47gfWA7S4A3+ijf8J4+UcGLI46rOd+jHoYgSq8VWl1YUr0yLIYT/yjadwA AAAAAAA= ------=_NextPart_000_02C4_01C73AFF.18A0A080-- From tsvwg-bounces@ietf.org Thu Jan 18 07:38:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WWv-0001pX-2K; Thu, 18 Jan 2007 07:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WWu-0001ov-0u for tsvwg@ietf.org; Thu, 18 Jan 2007 07:38:08 -0500 Received: from adsl-070-155-160-098.sip.cae.bellsouth.net ([70.155.160.98] helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7WWs-0004Qu-JC for tsvwg@ietf.org; Thu, 18 Jan 2007 07:38:08 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lakerest.net (8.13.6/8.13.6) with ESMTP id l0ICc3PI099950; Thu, 18 Jan 2007 07:38:04 -0500 (EST) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1169123884; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=VCX0/SPdTZ0ju/I6ohqNQFKyv8PsFTiH46lI8J pQAPHQETepVlQiwCIYJmXfxRjVcClPmT6a06wPw7PcN4NrqQ== Message-ID: <45AF6A0D.8030902@lakerest.net> Date: Thu, 18 Jan 2007 07:37:33 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] SCTP stream information References: <45AEB59F.2010909@cis.udel.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: TSWG , Preethi Natarajan X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hmm... that works only for the next message after the one you are currently reading. Thats great once you get past the first sctp_recvmsg() with the SCTP_EXTRCV option set... Brian points out an expensive alternative.. i.e. read 1 byte with MSG_PEEK. Seems to me we could probably do a socket option pretty easily that would return the next sinfo to be read.. Something like getsockopt(sd, IPPROT_SCTP, SCTP_NEXT_SINFO, &sinfo, &sinfo_len); It should be pretty easy to implement.. but is it really something we want to do to get beyond the first message problem (instead of a MSG_PEEK)... R Michael Tuexen wrote: > Hi, > > it looks like you are looking for > > 5.2.3. Extended SCTP Header Information Structure (SCTP_EXTRCV) > > This cmsghdr structure specifies SCTP options for SCTP header > information about a received message via recvmsg(). Note that this > structure is an extended version of SCTP_SNDRCV and will only be > received if the user has set the socket option SCTP_USE_EXT_RCVINFO > to true in addition to any event subscription needed to receive > ancillary data.. > > cmsg_level cmsg_type cmsg_data[] > ------------ ------------ ---------------------- > IPPROTO_SCTP SCTP_SNDRCV struct sctp_sndrcvinfo > > Here is the definition of sctp_sndrcvinfo: > > struct sctp_extrcvinfo { > uint16_t sinfo_stream; > uint16_t sinfo_ssn; > uint16_t sinfo_flags; > uint32_t sinfo_ppid; > uint32_t sinfo_context; > uint32_t sinfo_timetolive; > uint32_t sinfo_tsn; > uint32_t sinfo_cumtsn; > sctp_assoc_t sinfo_assoc_id; > uint16_t next_flags; > uint16_t next_stream; > uint32_t next_asocid; > uint32_t next_length; > uint32_t next_ppid; > }; > > from http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-14.txt > > Best regards > Michael > > On Jan 18, 2007, at 12:47 AM, Preethi Natarajan wrote: > >> Hello all, >> >> Is it possible to get advance information on the SCTP stream in which >> the next sctp_recvmsg() will return data from? I.e., the application >> gets to know the SCTP stream on which data will be received before >> doing the sctp_recvmsg(). >> >> -- >> Regards, >> Preethi >> >> >> > > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From tsvwg-bounces@ietf.org Thu Jan 18 08:41:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XVS-0001l2-Pt; Thu, 18 Jan 2007 08:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XVR-0001jY-Um for tsvwg@ietf.org; Thu, 18 Jan 2007 08:40:41 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7XVN-0005qQ-BW for tsvwg@ietf.org; Thu, 18 Jan 2007 08:40:41 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 13:40:32 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Jan 2007 13:26:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1169126763693; Thu, 18 Jan 2007 13:26:03 +0000 Received: from mut.jungle.bt.co.uk ([10.86.16.7]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l0IDPsv7002393; Thu, 18 Jan 2007 13:26:00 GMT Message-Id: <5.2.1.1.2.20070118123607.00c634d0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 18 Jan 2007 13:25:57 +0000 To: Dimitri.Papadimitriou@alcatel-lucent.be From: Bob Briscoe Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 18 Jan 2007 13:26:06.0092 (UTC) FILETIME=[3525B4C0:01C73B04] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: David BLACK , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dimitri, At 10:24 17/01/2007, Dimitri.Papadimitriou@alcatel-lucent.be wrote: >On Nov 14, 2006, at 6:07 PM, Dimitri.Papadimitriou@alcatel.be wrote: > >[dp] the same section 7 mentions > >"[RFC3168] does not give any reasons against conveying CE information > from the inner header to the outer in the "full functionality" mode." > >nor the other way around - which leaves the point open for ECN itself >-> the issue i am raising is that in absence of evidence current the >processing should be left per RFC3168 and not inline with the expected >PCN needs (even if it does not affect the former) You are right to be concerned about the motivation for copying ECN CE information from the inner header to the outer at ingress of an MPLS region when this conflicts with RFC3168, which says CE should be reset to zero in the outer header for IP in IP tunneling. But I think your concern can be alleviated by updating you on information given by David Black in the IETF-66 TSVWG mtg, but not repeated (yet) on the list (AFAI recall). There's only a brief mention in the minutes: "David Black comment: copying 3168 header to outer header is fine" But below, I'll try to reconstruct what he said (David, pls correct if nec): David (one of the original authors of RFC3168 on ECN) said that the text in RFC3168 about re-setting ECN CE can and should now be updated to mandate copying instead. The recent update to IPSec tunneling RFC now mandates copying the ECN field from inner to outer, not resetting it. David said the original text in RFC3168 was solely designed to satisfy the security community who thought there /might/ be concerns about information leakage. Now they have thought about it thoroughly, they are happy that copying CE is safe. According to David all implementations of IP in IP tunneling copy the ECN field anyway, though I don't recall how authoratative his survey was. So what you see in this ECN-MPLS draft is compatible with what RFC3168 /should/ now say. I'll leave the ADs & WG chairs to advise on whether this draft would have to wait for an update to RFC3168 before it can go to RFC, but I assume not, given we should be able to repeat whatever process trick must have been used to get IPsec to contradict RFC3168. Alternatively, there should be no problem doing a focused update to RFC3168 in parallel, as long as we are strict about not opening other cans of worms at the same time, given 3168 is a long and complicated RFC. We should explain this new situation in the next version of the draft. With this rider, are you now OK for this I-D to go to WG status? Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Thu Jan 18 15:28:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7drh-0005kK-57; Thu, 18 Jan 2007 15:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7drf-0005kF-WA for tsvwg@ietf.org; Thu, 18 Jan 2007 15:28:03 -0500 Received: from webmail2.speakeasy.net ([69.17.117.49] helo=webmail2.sea5.speakeasy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7drc-0001cB-Kd for tsvwg@ietf.org; Thu, 18 Jan 2007 15:28:03 -0500 Received: (qmail 16368 invoked from network); 18 Jan 2007 20:27:57 -0000 Received: from localhost (HELO webmail2) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 18 Jan 2007 20:27:57 -0000 Received: from 216.31.211.11 (unverified [216.31.211.11]) by webmail2 (VisualMail 4.0) with WEBMAIL id 25940; Thu, 18 Jan 2007 20:27:57 +0000 From: "Caitlin Bestler" To: "Randall Stewart" , "Michael Tuexen" Importance: Normal Sensitivity: Normal Message-ID: X-Mailer: Mintersoft VisualMail, Build 4.0.111601 X-Originating-IP: [216.31.211.11] Date: Thu, 18 Jan 2007 20:27:57 +0000 Subject: Re: [Tsvwg] SCTP stream information MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: TSWG , Preethi Natarajan X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org > -----Original Message----- > From: Randall Stewart [mailto:randall@lakerest.net] > Sent: Thursday, January 18, 2007 12:37 PM > To: 'Michael Tuexen' > Cc: 'TSWG', 'Preethi Natarajan' > Subject: Re: [Tsvwg] SCTP stream information > > > Hmm... that works only for the next message > after the one you are currently reading. > > Thats great once you get past the first sctp_recvmsg() with > the SCTP_EXTRCV option set... > > Brian points out an expensive alternative.. i.e. read 1 byte > with MSG_PEEK. > > Seems to me we could probably do a socket option pretty easily > that would return the next sinfo to be read.. > > Something like > > getsockopt(sd, IPPROT_SCTP, SCTP_NEXT_SINFO, &sinfo, &sinfo_len); > > It should be pretty easy to implement.. but is it really something > we want to do to get beyond the first message problem (instead > of a MSG_PEEK)... > I'm assuming that the purpose is to peek ahead so that the stream can be identified and a buffer appropriate for that stream can be used to receive the message. Peeking is a rather clumbsy method to achieve that goal. It would be far more natural to simply have an asynchronous post of a stream specific buffer, and then a method of getting the next completed message. That completion would identify what buffer had been used. From tsvwg-bounces@ietf.org Thu Jan 18 23:39:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lWr-0002xh-8l; Thu, 18 Jan 2007 23:39:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lWp-0002wH-Q2 for tsvwg@ietf.org; Thu, 18 Jan 2007 23:39:03 -0500 Received: from bgerelbas02.asiapac.hp.net ([15.219.201.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7lWk-00042R-BB for tsvwg@ietf.org; Thu, 18 Jan 2007 23:39:03 -0500 Received: from bgeexg12.asiapacific.cpqcorp.net (bgeexg12.asiapacific.cpqcorp.net [16.150.33.62]) by bgerelbas02.asiapac.hp.net (Postfix) with ESMTP id 14C6F32EB2 for ; Fri, 19 Jan 2007 10:08:52 +0530 (IST) Received: from bgeexc01.asiapacific.cpqcorp.net ([16.150.33.37]) by bgeexg12.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 10:08:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jan 2007 10:08:50 +0530 Message-ID: <6A309B742BCC424CA59BB645C437C0E8075D0CA2@bgeexc01.asiapacific.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSG_NOTIFICATION flag Thread-Index: Acc7g7cbx/yeL3pvSHeZ6TQyUCPXUg== From: "Ramaiah, Chaitra M (STSD)" To: X-OriginalArrivalTime: 19 Jan 2007 04:38:51.0648 (UTC) FILETIME=[B7F66000:01C73B83] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Tsvwg] MSG_NOTIFICATION flag X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi All, There is this quote in the SCTP socket API draft. A recvmsg() call will return only one notification at a time. Just as when reading normal data, it may return part of a notification if the msg_iov buffer is not large enough. If a single read is not sufficient, msg_flags will have MSG_EOR clear. The user MUST finish reading the notification before subsequent data can arrive. My question is if the app has passed a buffer which is not enough to read the complete notification in one recvmsg() operation, I understand that successive recvmsg()s will complete reading the full notification and the last recvmsg() will have MSG_EOR set in msg_flags. This is true for both data and notification. My doubt is should we return MSG_NOTIFICATION to the app for each partial read of the notification or should this flag be returned only in the last recvmsg() along with MSG_EOR? Thanks, Chaitra From tsvwg-bounces@ietf.org Fri Jan 19 03:56:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pXK-0000a8-Bv; Fri, 19 Jan 2007 03:55:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pXK-0000a3-27 for tsvwg@ietf.org; Fri, 19 Jan 2007 03:55:50 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7pXI-0002PM-GT for tsvwg@ietf.org; Fri, 19 Jan 2007 03:55:50 -0500 Received: from [192.168.1.3] (p508FCF6B.dip.t-dialin.net [80.143.207.107]) by mail-n.franken.de (Postfix) with ESMTP id 183B280000AF; Fri, 19 Jan 2007 09:55:33 +0100 (CET) (KNF-authenticated sender: macmic) In-Reply-To: <6A309B742BCC424CA59BB645C437C0E8075D0CA2@bgeexc01.asiapacific.cpqcorp.net> References: <6A309B742BCC424CA59BB645C437C0E8075D0CA2@bgeexc01.asiapacific.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [Tsvwg] MSG_NOTIFICATION flag Date: Fri, 19 Jan 2007 09:55:31 +0100 To: "Ramaiah, Chaitra M (STSD)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Comment in-line. Best regards Michael On Jan 19, 2007, at 5:38 AM, Ramaiah, Chaitra M (STSD) wrote: > Hi All, > > There is this quote in the SCTP socket API draft. > > A recvmsg() call will return only one notification at a time. Just > as when reading normal data, it may return part of a > notification if > the msg_iov buffer is not large enough. If a single read is not > sufficient, msg_flags will have MSG_EOR clear. The user MUST > finish > reading the notification before subsequent data can arrive. > > My question is if the app has passed a buffer which is not enough to > read the > complete notification in one recvmsg() operation, I understand that > successive > recvmsg()s will complete reading the full notification and the last > recvmsg() will have MSG_EOR > set in msg_flags. This is true for both data and notification. > > My doubt is should we return MSG_NOTIFICATION to the app for each > partial read of the notification > or should this flag be returned only in the last recvmsg() along with > MSG_EOR? I think MSG_NOTIFICATION must be given for each partial read. > > Thanks, > Chaitra > > > From tsvwg-bounces@ietf.org Sun Jan 21 05:45:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8aBt-0005wO-6J; Sun, 21 Jan 2007 05:44:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8aBr-0005wI-U5 for tsvwg@ietf.org; Sun, 21 Jan 2007 05:44:47 -0500 Received: from adsl-070-155-160-098.sip.cae.bellsouth.net ([70.155.160.98] helo=lakerest.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8aBq-0002sV-KJ for tsvwg@ietf.org; Sun, 21 Jan 2007 05:44:47 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lakerest.net (8.13.6/8.13.6) with ESMTP id l0LAiWhF030472; Sun, 21 Jan 2007 05:44:32 -0500 (EST) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=lakerest; t=1169376277; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=FEVwMXvQReeMeeh57adHBIWhUtUxc+YlVQAjgU YdRs4xtPS0qFpgNC0l5hwbdKbz8VL2D8DSzlKdgLSnFoXnXA== Message-ID: <45B343EC.9050601@lakerest.net> Date: Sun, 21 Jan 2007 05:43:56 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: [Tsvwg] MSG_NOTIFICATION flag References: <6A309B742BCC424CA59BB645C437C0E8075D0CA2@bgeexc01.asiapacific.cpqcorp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Michael Tuexen wrote: > Comment in-line. > > Best regards > Michael > > On Jan 19, 2007, at 5:38 AM, Ramaiah, Chaitra M (STSD) wrote: > >> Hi All, >> >> There is this quote in the SCTP socket API draft. >> >> A recvmsg() call will return only one notification at a time. Just >> as when reading normal data, it may return part of a notification if >> the msg_iov buffer is not large enough. If a single read is not >> sufficient, msg_flags will have MSG_EOR clear. The user MUST finish >> reading the notification before subsequent data can arrive. >> >> My question is if the app has passed a buffer which is not enough to >> read the >> complete notification in one recvmsg() operation, I understand that >> successive >> recvmsg()s will complete reading the full notification and the last >> recvmsg() will have MSG_EOR >> set in msg_flags. This is true for both data and notification. >> >> My doubt is should we return MSG_NOTIFICATION to the app for each >> partial read of the notification >> or should this flag be returned only in the last recvmsg() along with >> MSG_EOR? > I think MSG_NOTIFICATION must be given for each partial read. I agree :-) R -- Randall Stewart 803-345-0369 815-342-5222(cell) From tsvwg-bounces@ietf.org Sun Jan 21 15:44:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8jXh-0005pn-HW; Sun, 21 Jan 2007 15:43:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8jXg-0005pi-OM for tsvwg@ietf.org; Sun, 21 Jan 2007 15:43:56 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8jXe-0002xC-C0 for tsvwg@ietf.org; Sun, 21 Jan 2007 15:43:56 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0LKhtZZ005544; Sun, 21 Jan 2007 21:43:55 +0100 In-Reply-To: <89FB19D5-4F09-4AA8-A947-DA01462CCF3F@cisco.com> To: Fred Baker Subject: Re: [Tsvwg] Admitted Real Time Services MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Sun, 21 Jan 2007 21:43:46 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/21/2007 21:43:48, Serialize complete at 01/21/2007 21:43:48 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Lars Eggert , "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org > Can you please state why you think this is as you see it? reasoning is rather simple i don't see in this document the real value to assume capacitive admission control (rather than assuming it would bring any real value) henceforth, i don't see the reasoning for recommending any specific user-control driven (signaling) admission control would it be possible that the reasoning behind such specific recommendation is spelled out before comparing the different protocol implementations that would fit any specific need take an example of an exceptional calamity situation would this approach provide any benefit ? more fundamentally i tempted to say that all the techniques that are spelled out in this document are reminiscences of PSTN traffic control instead of considering the techniques that are inline with packet-based networks thanks, - d. Fred Baker 12/01/2007 04:50 To: Dimitri.Papadimitriou@alcatel-lucent.be cc: "James M. Polk" , Lars Eggert , tsvwg@ietf.org Subject: Re: [Tsvwg] Admitted Real Time Services On Dec 18, 2006, at 9:22 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > i should have been more specific - the whole discussion about > signaling is beyond the scope this document whether performed at at > the network (RSVP) or the session layer (SIP) or any other > signaling technique being currently under discussion at IETF - this > doc. should not discuss about the call-level but stick to packet- > level processing and related operations (that should translated in > a DS configuration profile) Given that we already have a class for voice in RFC 4594, and this is is creating one with the specific characteristic that it requires (as opposed to the existing-and-deployed one that merely recommends and in many cases doesn't use) capacity admission, I'm at a loss to figure out why you would want to remove capacity admission from the document. Can you please state why you think this is as you see it? From tsvwg-bounces@ietf.org Tue Jan 23 05:52:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JFt-0005np-Vk; Tue, 23 Jan 2007 05:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9JFt-0005nk-7e for tsvwg@ietf.org; Tue, 23 Jan 2007 05:51:57 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9JFr-000090-R0 for tsvwg@ietf.org; Tue, 23 Jan 2007 05:51:57 -0500 Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id l0NApf3c011592; Tue, 23 Jan 2007 10:51:42 GMT Message-ID: <45B5E8BD.1080504@erg.abdn.ac.uk> Date: Tue, 23 Jan 2007 10:51:41 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Persson Subject: Re: [Tsvwg] TCP and UDP MIB issues References: <45A68ABA.9070501@sun.com> In-Reply-To: <45A68ABA.9070501@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-ERG-MailScanner-To: anders.persson@sun.com, gerrit@erg.abdn.ac.uk, tsvwg@ietf.org X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Gerrit Renker , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Generally, the proposed UDP-Lite MIB follows that for UDP (supporting both multicast and unicast). It does differ in the udpliteEndpointTable: http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt If there are implications on the UDP-Lite MIB, we'd be pleased to try to understand what these are, and any ideas of what we should do. Best wishes, Gorry Anders Persson wrote: > Hi Everyone, > > During the v6ops meeting at IETF 66 we presented some issues with the > current TCP and UDP MIBs, however, it was quickly pointed out that the > TSVWG would be a more appropriate venue. The main issue that we are > trying to address is how to present associations between system > processes and TCP/UDP endpoints when there are multiple processes > associated with one endpoint. > > A draft[1] is available that describes the issue and which also contains > a first attempt at a TCP/UDP extension MIB. It would be highly > appreciated if members of the TSVWG could help out reviewing this draft. > > Thanks, > Anders > > [1] http://tools.ietf.org/wg/v6ops/draft-persson-v6ops-mib-issue-01.txt > > > From tsvwg-bounces@ietf.org Tue Jan 23 15:29:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SFm-00046O-Cn; Tue, 23 Jan 2007 15:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SFl-00046J-K8 for tsvwg@ietf.org; Tue, 23 Jan 2007 15:28:25 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9SFk-0002Wd-9W for tsvwg@ietf.org; Tue, 23 Jan 2007 15:28:25 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jan 2007 21:28:24 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0NKSN0D015500 for ; Tue, 23 Jan 2007 21:28:23 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0NKSFCM003241 for ; Tue, 23 Jan 2007 21:28:23 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 21:27:33 +0100 Received: from [10.0.0.2] ([10.61.81.196]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 21:27:33 +0100 In-Reply-To: <7FAA5D64-A8CD-4F5F-B028-ECD54D9C7247@cisco.com> References: <7FAA5D64-A8CD-4F5F-B028-ECD54D9C7247@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <369F0AC2-7BF9-4E14-9305-817049934570@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Tue, 23 Jan 2007 21:25:40 +0100 To: tsvwg tsvwg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Jan 2007 20:27:33.0510 (UTC) FILETIME=[E9B03A60:01C73F2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1698; t=1169584103; x=1170448103; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Moving=20ahead=20on=20RSVP=20Proxy=20WG=20Document(s) |Sender:=20; bh=K8UA04zaH4FZr7gYeOoX0EWYI2Ewn6ERomkIj+51Hmo=; b=C8B/icVK853QYqSYHniBVG7wbPIYZVsWgvccHc9wYyOh/uS8s8KPxMEQThsl77hzLGSN5zaf Cbt2i/8utNdRHU7T6J9pT+SJi4/slYkKk9UFhfB2JXh7CEOi+k8zfB3a; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Tsvwg] Re: Moving ahead on RSVP Proxy WG Document(s) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hi Again, Since no-one raised any particular concerns withe the proposal below, we will move ahead accordingly and start corresponding editing soon. Thanks Francois On 8 Dec 2006, at 12:18, Francois Le Faucheur wrote: > Hello, > > On 7 Dec 2006, at 15:31, Lars Eggert wrote: > > >> Hi, >> >> based on the poll in San Diego and the recent mailing list >> confirmation, we're ready to take this on as a WG item in TSVWG >> going for PS. >> > > So, just to recap and request for feed-back: > > * we had agreed to take draft-lefaucheur-tsvwg-rsvp-proxy as a WG doc > > * However, that document currently mixes informational stuff (most > of the doc) and a bit of protocol stuff > > * Hence, as discussed in San Diego, the authors are proposing to > split its content into two documents: > 1) one containing the informational stuff. This would go under > Informational Track and could presumably progress fairly fast. > 2) one containing the protocol stuff for the "simpler" Proxy > scenarios. This would go under Standards Track. This would NOT > incorporate the relatively more significant protocol extensions > discussed in draft-manner-tsvwg-rsvp-proxy-sig-00.txt. > > * and we are proposing that these two resulting documents be taken > as Working Group documents. > > Does anyone have concerns/comments on splitting draft-lefaucheur- > tsvwg-rsvp-proxy into two documents? > Does anyone has concerns/comments on issuing the two resulting > documents as WG documents? > > Please respond within a couple of weeks, as we'd like to start the > corresponding editing work after that. > > Thanks > > Francois > From tsvwg-bounces@ietf.org Tue Jan 23 15:50:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Sb3-0006Og-SX; Tue, 23 Jan 2007 15:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Sai-0006Ix-BM; Tue, 23 Jan 2007 15:50:04 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Sah-00064P-MP; Tue, 23 Jan 2007 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B29DB26F12; Tue, 23 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9Sag-00044G-4s; Tue, 23 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 23 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctp-auth-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Author(s) : M. Tuexen, et al. Filename : draft-ietf-tsvwg-sctp-auth-07.txt Pages : 18 Date : 2007-1-23 This document describes a new chunk type, several parameters and procedures for SCTP. This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-tsvwg-sctp-auth-07.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-ietf-tsvwg-sctp-auth-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-23125009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-sctp-auth-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctp-auth-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-23125009.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Jan 24 10:11:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jlo-0006QA-M1; Wed, 24 Jan 2007 10:10:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9jll-0006NS-KU; Wed, 24 Jan 2007 10:10:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9jll-0005AI-CN; Wed, 24 Jan 2007 10:10:37 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 530C42ACAC; Wed, 24 Jan 2007 15:10:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9jlH-0003pZ-3U; Wed, 24 Jan 2007 10:10:07 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 24 Jan 2007 10:10:07 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tsvwg@ietf.org Subject: [Tsvwg] Last Call: draft-ietf-tsvwg-sctp-auth (Authenticated Chunks for Stream Control Transmission Protocol (SCTP)) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Authenticated Chunks for Stream Control Transmission Protocol (SCTP) ' 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 substantive comments to the ietf@ietf.org mailing lists by 2007-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13224&rfc_flag=0 From tsvwg-bounces@ietf.org Wed Jan 24 15:51:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p59-0008Is-IL; Wed, 24 Jan 2007 15:50:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p4j-0007b0-OH; Wed, 24 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9p4j-0008I4-6X; Wed, 24 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D5B7D17635; Wed, 24 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9p4E-0008VM-7n; Wed, 24 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 24 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-ipsec-04.txt Pages : 30 Date : 2007-1-24 [RSVP-AGG] defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. [RSVP-AGG] also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in [RSVP-AGG]. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end- to-end directly by end-systems attached to a Diffserv network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-tsvwg-rsvp-ipsec-04.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-ietf-tsvwg-rsvp-ipsec-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-24124608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-rsvp-ipsec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-24124608.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Wed Jan 24 16:08:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9pM3-0002OS-9J; Wed, 24 Jan 2007 16:08:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9pCp-0004qA-QC for tsvwg@ietf.org; Wed, 24 Jan 2007 15:58:56 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9pCT-0005ce-8g for tsvwg@ietf.org; Wed, 24 Jan 2007 15:58:55 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l0OKwWU2028493 for ; Wed, 24 Jan 2007 21:58:32 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l0OKwUgp016334 for ; Wed, 24 Jan 2007 21:58:32 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 21:58:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73FFA.02CCF527" Subject: WG: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt Date: Wed, 24 Jan 2007 21:55:41 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7017083A8@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt Thread-Index: Acc/+YO07b7Kp5zTQoWuhsmjExKgkQAADmiw From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 24 Jan 2007 20:58:31.0312 (UTC) FILETIME=[67701100:01C73FFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C73FFA.02CCF527 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-ipsec/draft-ietf-tsv= wg-rsvp-ipsec-03.nits.txt idnits 1.110=20 tsvwg/draft-ietf-tsvwg-rsvp-ipsec/draft-ietf-tsvwg-rsvp-ipsec-03.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3979 Section 5, para 2 IPR = Disclosure Acknowledgement -- however, there's a paragraph with a matching = beginning. Boilerplate error? * There are 6 instances of too long lines in the document, the longest = one being 1 character in excess of 72. Checking nits according to = http://www.ietf.org/ietf/1id-guidelines.txt: - It seems as if not all pages are separated by form feeds - found 0 = form feeds but 26 pages Miscellaneous warnings: - Line 32 has weird spacing: '... and may be...' - Line 272 has weird spacing: '...rations are...' Experimental warnings: None. Summary: 2 nits, 3 warnings Run idnits with the --verbose option for more detailed information. -----Urspr=FCngliche Nachricht----- Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Gesendet: Mittwoch, 24. Januar 2007 21:50 An: i-d-announce@ietf.org Cc: tsvwg@ietf.org Betreff: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Generic Aggregate Resource ReSerVation Protocol (RSVP) = Reservations Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-rsvp-ipsec-04.txt Pages : 30 Date : 2007-1-24 =09 [RSVP-AGG] defines aggregate Resource ReSerVation Protocol (RSVP)=20 reservations allowing resources to be reserved in a Diffserv network=20 for a given Per Hop Behavior (PHB), or given set of PHBs, from a=20 given source to a given destination. [RSVP-AGG] also defines how end- = to-end RSVP reservations can be aggregated onto such aggregate=20 reservations when transiting through a Diffserv cloud. There are=20 situations where multiple such aggregate reservations are needed for=20 the same source IP address, destination IP address and PHB (or set of = PHBs). However, this is not supported by the aggregate reservations=20 defined in [RSVP-AGG]. In order to support this, the present document = defines a more flexible type of aggregate RSVP reservations, referred = to as generic aggregate reservation. Multiple such generic aggregate=20 reservations can be established for a given PHB (or set of PHBs) from = a given source IP address to a given destination IP address. The=20 generic aggregate reservations may be used to aggregate end-to-end=20 RSVP reservations. This document also defines the procedures for such = aggregation. The generic aggregate reservations may also be used end- to-end directly by end-systems attached to a Diffserv network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-04.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-tsvwg-rsvp-ipsec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-ietf-tsvwg-rsvp-ipsec-04.txt". =09 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. ------_=_NextPart_001_01C73FFA.02CCF527 Content-Type: application/octet-stream; name="draft-ietf-tsvwg-rsvp-ipsec-04.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-tsvwg-rsvp-ipsec-04.URL Content-Disposition: attachment; filename="draft-ietf-tsvwg-rsvp-ipsec-04.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXRzdndnLXJzdnAtaXBzZWMtMDQudHh0DQo= ------_=_NextPart_001_01C73FFA.02CCF527-- From tsvwg-bounces@ietf.org Wed Jan 24 19:25:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sQY-0002TH-2y; Wed, 24 Jan 2007 19:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sQW-0002Sf-P7 for tsvwg@ietf.org; Wed, 24 Jan 2007 19:25:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sQV-0007vw-C7 for tsvwg@ietf.org; Wed, 24 Jan 2007 19:25:16 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2007 16:25:15 -0800 X-IronPort-AV: i="4.13,234,1167638400"; d="scan'208"; a="459550580:sNHT121518272" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0P0PEPN000741; Wed, 24 Jan 2007 16:25:14 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0P0P8Uw021276; Wed, 24 Jan 2007 16:25:08 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 16:25:07 -0800 Received: from [10.32.244.218] ([10.32.244.218]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 16:25:07 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Tsvwg] Admitted Real Time Services Date: Wed, 24 Jan 2007 16:25:05 -0800 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 00:25:07.0585 (UTC) FILETIME=[44313710:01C74017] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2451; t=1169684714; x=1170548714; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[Tsvwg]=20Admitted=20Real=20Time=20Services |Sender:=20; bh=gGhafb5m+vBKCAkb8bqQ5Ih0Z6IitFo2dEmWxnOLgc4=; b=U0l6FsCisQzOgDPiMQCxT0PNc9c9uFd241cD7TTXJLvoLT3pjc2T72BZ5PQeO6KnZuuQkeih 9O0OxQDKoIbr9Q15G03UhVX8DM1cJa0c98UeN6BH+XzUIFzspr4TUzuH; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Lars Eggert , "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Jan 21, 2007, at 12:43 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > take an example of an exceptional calamity situation would this > approach provide any benefit ? > > more fundamentally i tempted to say that all the techniques that > are spelled out in this document are reminiscences of PSTN traffic > control instead of considering the techniques that are inline with > packet-based networks well, yes, they are. In the PSTN, you have some number of circuits to hand out, and using the control plane to hand them out handles all conditions that happen - pretty well. In the Internet, we have some amount of bandwidth to hand out. I haven't heard any argument that doing so in a similar control plane would be ineffective. Field operational experience says that it in fact works. Now, we can have a religious debate if you like. If your argument is "I don't wanna", you're right in there with a whole lot of people. But it's not a rational argument, it is digging heels in. In the past couple of years, the working group has been over and over the ECN proposal, which is characteristic of a number of measurement- based algorithms. It has looked at Morita's document (http:// www3.ietf.org/proceedings/03jul/slides/tsvwg-2.pdf, http:// tools.ietf.org/html/draft-morita-tsvwg-pps, http://tools.ietf.org/ html/draft-morita-tsvwg-mfverify), and a variety of others. I won't repeat the various arguments, but I will note that Morita-san pulled his proposal when he worked out that it operationally wasn't adequate to handle MPEG-4 video even without thinking about differential policy, and I will note that while folks will generally agree that a guard band model (which is statistical and therefore depends on the law of large numbers) works when there are large numbers of flows and large bandwidths to carry them, this isn't necessarily true in access paths. Hence, ECN may be sufficient for optical backbones, but there is no guarantee that it does anything in access paths. Says the guy who buys "business broadband" from Cox Cable, an AT&T subsidiary, at $94/month and gets 256 KBPS upstream capacity... What you're arguing is in essence that RFC 4594's telephony class is sufficient for preferential call management. My co-author and ATIS working group chair says that ATIS and the companies that do their work there disagree... From tsvwg-bounces@ietf.org Thu Jan 25 09:46:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5rL-0003tl-NO; Thu, 25 Jan 2007 09:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5rK-0003tY-75 for tsvwg@ietf.org; Thu, 25 Jan 2007 09:45:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5rG-000584-30 for tsvwg@ietf.org; Thu, 25 Jan 2007 09:45:48 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 70682206D9 for ; Thu, 25 Jan 2007 15:45:41 +0100 (CET) X-AuditID: c1b4fb3c-b1fccbb0000007de-cb-45b8c295ffb8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3EA5420512 for ; Thu, 25 Jan 2007 15:45:41 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 15:45:41 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 15:45:40 +0100 Message-ID: <45B8C294.6070608@ericsson.com> Date: Thu, 25 Jan 2007 15:45:40 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 14:45:40.0814 (UTC) FILETIME=[7BFEB6E0:01C7408F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org WG, There are some substantial changes in this version of the document to address IETF LC comments. Please review and provide any comments within a week. A side by side diff of the changes are available here: http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-ipsec/draft-ietf-tsvwg-rsvp-ipsec-04-from-03.diff.html Cheers Magnus Internet-Drafts@ietf.org skrev: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations > Author(s) : F. Le Faucheur, et al. > Filename : draft-ietf-tsvwg-rsvp-ipsec-04.txt > Pages : 30 > Date : 2007-1-24 > > [RSVP-AGG] defines aggregate Resource ReSerVation Protocol (RSVP) > reservations allowing resources to be reserved in a Diffserv network > for a given Per Hop Behavior (PHB), or given set of PHBs, from a > given source to a given destination. [RSVP-AGG] also defines how end- to-end RSVP reservations can be aggregated onto such aggregate > reservations when transiting through a Diffserv cloud. There are > situations where multiple such aggregate reservations are needed for > the same source IP address, destination IP address and PHB (or set of > PHBs). However, this is not supported by the aggregate reservations > defined in [RSVP-AGG]. In order to support this, the present document > defines a more flexible type of aggregate RSVP reservations, referred > to as generic aggregate reservation. Multiple such generic aggregate > reservations can be established for a given PHB (or set of PHBs) from > a given source IP address to a given destination IP address. The > generic aggregate reservations may be used to aggregate end-to-end > RSVP reservations. This document also defines the procedures for such > aggregation. The generic aggregate reservations may also be used end- > to-end directly by end-systems attached to a Diffserv network. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-tsvwg-rsvp-ipsec-04.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-ietf-tsvwg-rsvp-ipsec-04.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. > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Thu Jan 25 11:07:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA77B-00052Y-SB; Thu, 25 Jan 2007 11:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA77A-00052Q-NG for tsvwg@ietf.org; Thu, 25 Jan 2007 11:06:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA778-0003rX-W1 for tsvwg@ietf.org; Thu, 25 Jan 2007 11:06:16 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jan 2007 17:06:16 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0PG6Ees029433; Thu, 25 Jan 2007 17:06:14 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0PG6EC8006883; Thu, 25 Jan 2007 17:06:14 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 17:06:06 +0100 Received: from [144.254.53.92] ([144.254.53.92]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 17:06:06 +0100 In-Reply-To: <45B8C294.6070608@ericsson.com> References: <45B8C294.6070608@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-ipsec-04.txt Date: Thu, 25 Jan 2007 17:04:12 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Jan 2007 16:06:06.0133 (UTC) FILETIME=[B81BF650:01C7409A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5213; t=1169741174; x=1170605174; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Tsvwg]=20I-D=20ACTION=3Adraft-ietf-tsvwg-rsvp-ipsec- 04.txt |Sender:=20; bh=xdSUXe2IwYxM8YxTREH3WZQ4Vzx2t8K4vyjYnHW4xXc=; b=c9RnpA0/Ih/UxYC8uPMuNEb1FzX7eKWddtLIYZ1C8GAJAqpGizWnKBSAiC4kn/C8sbmN8Ia2 jvCO2ZjkyBVZULqshVH61oFNOINJaGLteUza22DXEb5Ym1UoL+TNhA6W; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Hello, On 25 Jan 2007, at 15:45, Magnus Westerlund wrote: > WG, > > There are some substantial changes in this version of the document > to address IETF LC comments. To facilitate this review, the key changes are: o rewritten and considerably expanded Security Considerations section (with text agreed on mailing list) o correction in description of "Take highest priority" in section 3.1.1. o use of PHB-ID instead of DSCP in Session object. This is to address David Black's comment. PHB-ID allows explicit indication of whether the aggregate RSVP reservations take resource from a single PHB (e.g. EF) or a set of PHBs (e.g. AF4x). Also, it allows aggregate RSVP reservations to span multiple Diffserv Domains even if those happen to use different DSCP values for the PGB (or set of PHBs) of interest. Cheers Francois > Please review and provide any comments within a week. > > A side by side diff of the changes are available here: > http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-ipsec/draft- > ietf-tsvwg-rsvp-ipsec-04-from-03.diff.html > > Cheers > > Magnus > > Internet-Drafts@ietf.org skrev: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Transport Area Working Group >> Working Group of the IETF. >> Title : Generic Aggregate Resource ReSerVation Protocol (RSVP) >> Reservations >> Author(s) : F. Le Faucheur, et al. >> Filename : draft-ietf-tsvwg-rsvp-ipsec-04.txt >> Pages : 30 >> Date : 2007-1-24 >> >> [RSVP-AGG] defines aggregate Resource ReSerVation Protocol >> (RSVP) reservations allowing resources to be reserved in a >> Diffserv network for a given Per Hop Behavior (PHB), or given >> set of PHBs, from a given source to a given destination. [RSVP- >> AGG] also defines how end- to-end RSVP reservations can be >> aggregated onto such aggregate reservations when transiting >> through a Diffserv cloud. There are situations where multiple >> such aggregate reservations are needed for the same source IP >> address, destination IP address and PHB (or set of PHBs). >> However, this is not supported by the aggregate reservations >> defined in [RSVP-AGG]. In order to support this, the present >> document defines a more flexible type of aggregate RSVP >> reservations, referred to as generic aggregate reservation. >> Multiple such generic aggregate reservations can be established >> for a given PHB (or set of PHBs) from a given source IP address >> to a given destination IP address. The generic aggregate >> reservations may be used to aggregate end-to-end RSVP >> reservations. This document also defines the procedures for >> such aggregation. The generic aggregate reservations may also >> be used end- >> to-end directly by end-systems attached to a Diffserv network. >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp- >> ipsec-04.txt >> To remove yourself from the I-D Announcement list, send a message >> to i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. You can also visit https://www1.ietf.org/ >> mailman/listinfo/I-D-announce to change your subscription settings. >> 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- >> ietf-tsvwg-rsvp-ipsec-04.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-ietf-tsvwg-rsvp-ipsec-04.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. > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From tsvwg-bounces@ietf.org Thu Jan 25 15:55:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABck-00037R-AR; Thu, 25 Jan 2007 15:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABci-00036y-6M; Thu, 25 Jan 2007 15:55:08 -0500 Received: from drew.ipv6.franken.de ([2001:638:a02:a001:20e:cff:fe4a:feaa] helo=mail-n.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABcd-0008VT-Rp; Thu, 25 Jan 2007 15:55:08 -0500 Received: from [192.168.1.2] (p508FDAD8.dip.t-dialin.net [80.143.218.216]) by mail-n.franken.de (Postfix) with ESMTP id EB47A80000A3; Thu, 25 Jan 2007 21:55:02 +0100 (CET) (KNF-authenticated sender: macmic) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: SIGTRAN , TSWG , RAI From: Michael Tuexen Date: Thu, 25 Jan 2007 21:55:04 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.6 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Tsvwg] SIGTRAN Interop in Moscow from April 16th to 20th X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dear all, I'm forwarding this official invitation from ETSI. Best regards Michael Dear Madam, Dear Sir, The ETSI=92s PlugtestsTM Service is pleased to invite you to the next =20= SIGTRAN Interoperability Test Event, which will take place from 16th =20 to 20th April 2007 at ZNIIS (Russian Central Science Research =20 Institute) in Moscow. ZNIIS possesses interesting facilities which will provide the =20 community additional value such as SS7 connectivity to address =20 further SS7-SIGTRAN interoperability after the first experience =20 gained at the last event. We will also gain valuable knowledge from =20 their NGN testing experience. The SIGTRAN (Protocol Testing) family of protocols (IUA, DUA, V5UA, =20 M2PA, M2UA, M3UA, SUA) addresses the transport of packet-based PSTN =20 signaling over IP Networks, taking into account functional and =20 performance requirements of the PSTN signaling. This event is an opportunity for engineers from competing =20 organizations to meet together in a commercially secure environment, =20 to share experiences and improve interoperability between their =20 implementations. Should you be interested, you will be able to retrieve all =20 information related to this event at the following address: http://=20 www.etsi.org/plugtests/SIGTRAN.htm Registration is open until 31st of March 2007. Please take into account that you will need a few weeks to obtain =20 your VISA in order to get to Moscow. Please find all the information =20 about how to get a VISA under Travel & VISA information. We would be pleased to welcome you to SIGTRAN Protocol Testing =20 Plugtests Event. Yours faithfully, Philippe COUSIN Interoperability Service Manager= From tsvwg-bounces@ietf.org Thu Jan 25 18:51:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEMY-0003wR-1z; Thu, 25 Jan 2007 18:50:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEMS-0003lB-Nx; Thu, 25 Jan 2007 18:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAEMS-0007ac-DZ; Thu, 25 Jan 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 571D82AD02; Thu, 25 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAELy-0001mn-3j; Thu, 25 Jan 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 25 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tsvwg@ietf.org Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-emergency-rsvp-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Author(s) : F. Le Faucheur, et al. Filename : draft-ietf-tsvwg-emergency-rsvp-01.txt Pages : 29 Date : 2007-1-25 An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-tsvwg-emergency-rsvp-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-ietf-tsvwg-emergency-rsvp-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-25154036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tsvwg-emergency-rsvp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tsvwg-emergency-rsvp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-25154036.I-D@ietf.org> --OtherAccess-- --NextPart-- From tsvwg-bounces@ietf.org Thu Jan 25 19:07:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEcb-0001hn-GI; Thu, 25 Jan 2007 19:07:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEcZ-0001hQ-Rz for tsvwg@ietf.org; Thu, 25 Jan 2007 19:07:11 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAEcY-0002JB-6g for tsvwg@ietf.org; Thu, 25 Jan 2007 19:07:11 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0Q07FZZ001023; Fri, 26 Jan 2007 01:07:15 +0100 To: Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Fri, 26 Jan 2007 01:07:06 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/26/2007 01:07:08 Content-Type: multipart/mixed; boundary="=_mixed 0000A6A6C125726F_=" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --=_mixed 0000A6A6C125726F_= Content-Type: text/plain; charset="US-ASCII" lars - i am more generally questioning cost/perf. gain & value for 3 major reasons (they would deserve imho further discussion - or at least further proof of evidence) o) if it is to come up with a forwarding paradigm that becomes equivalent to IP probably we should then start questioning the need for MPLS itself (in part. in the present case focusing on intra-domain operations where i always thought that data-traffic and resource-oriented perf. objectives were taken into account for edge-to-edge MPLS path provisioning) o) MPLS paradigm assumed "intelligence@edges" we progressively enter into a mode where intermediate LSRs will become (see end of section 3) progressively require/result again more selective processing of traffic o) initial MPLS-ECN based its reasoning on expectations from experience - quoting: "We believe the benefits from ECN of better overall performance for a wide range of applications because of reduced packet loss (especially those using non-TCP transports) and reduced queueing delay is sufficiently significant. Furthermore, there seems to be no reasons for LSRs to lack this capability as it becomes available in other (non-label switched) IP routers." it would have been interesting to sustain the reasoning with more tangible proofs - with the underlying question are we here waiting for this doc. to make such experiment possible ? much thanks, - d. 18/01/2007 11:49 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: tsvwg@ietf.org Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item < Attachment smime.p7s removed > Dimitri, > discussion was led on the list mid november - no real > conclusion or action where derived from the concerns > expressed at that time thanks for pointing out that this draft was also discussed elsewhere! As for your specific points: > > 1. CN marking in the EXP bits of the MPLS header falls imho under the > > MPLS change process that states for an optional problem statement and > > a mandatory prior requirements statement I-D to commit for any > > specific change or extension to MPLS > > > > see section 2.1.1 and 4.2 of > > The process described in that document isn't official procedure yet, and has raised significant concern in parts of the IESG. IMO it is unlikely to proceed without major changes. Hence, it's questionable that we should apply it here and now. > [dp] the same section 7 mentions > > "[RFC3168] does not give any reasons against conveying CE information > from the inner header to the outer in the "full functionality" mode." > > nor the other way around - which leaves the point open for ECN itself > -> the issue i am raising is that in absence of evidence current the > processing should be left per RFC3168 and not inline with the expected > PCN needs (even if it does not affect the former) I'm not quite sure I understand your point - are you saying that the benefits of ECN for MPLS are unclear? Thanks, Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com --=_mixed 0000A6A6C125726F_= Content-Type: application/octet-stream; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE4MTA0OTMwWjAjBgkqhkiG 9w0BCQQxFgQUe6x0QlkFoKGNtaoaOOIYmNR/FxEwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAKciKq8x6JlGuvAKrdd5RVoCesYKJfVlYlm61NXp sokmLwBffirpXBqZ7XuxXyLq2tExJDH0NyLOy4pniHBqrD3dx1e2mwxaW5q91qVuqo9GLNgH+JXI kouTWfOiXXSuBoSQ/jQvlngWoI1tw3RU3SYNUO3I4HBOUw6aNmfKc9dPslV2G2VsXm9+5KChlfqb OWue3KDiN2y/UUOhnpsp/HP95AymRRX4z6631PYRrCEz5cEWqaM8Zk5WeqWM2eyMJJje7HMm6Ryk L6pDKMjJaZzsEdvqaJ47gfWA7S4A3+ijf8J4+UcGLI46rOd+jHoYgSq8VWl1YUr0yLIYT/yjadwA AAAAAAA= --=_mixed 0000A6A6C125726F_=-- From tsvwg-bounces@ietf.org Fri Jan 26 04:49:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANhL-0006FH-T9; Fri, 26 Jan 2007 04:48:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANhK-0006Ew-Nu; Fri, 26 Jan 2007 04:48:42 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HANhJ-0007V2-8v; Fri, 26 Jan 2007 04:48:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0Q9jjER030256; Fri, 26 Jan 2007 11:46:05 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:49:12 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Jan 2007 11:48:25 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-80-371657636; protocol="application/pkcs7-signature" Message-Id: <895DE7DB-FAB3-463D-9E1F-0177087BC607@nokia.com> From: Lars Eggert Date: Fri, 26 Jan 2007 11:48:22 +0200 To: pcn@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 09:48:25.0011 (UTC) FILETIME=[1F70E830:01C7412F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: tsv-area@ietf.org, tsvwg Subject: [Tsvwg] HEADS UP: looking for co-chairs for PCN X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg-ads@tools.ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-80-371657636 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, we're looking for volunteers interested in co-chairing the Pre- Congestion Notification (PCN) WG. Note that a final chartering decision has not yet been made, and depends on the outcome of the ongoing discussion. This will be a new WG with a moderately busy initial charter, so we're looking for two chairs with sufficient weekly cycles to actively see this WG off to a good start. Experience with DiffServ/ IntServ, signaling and/or congestion control is a plus. Although we'd like chairs with a technical background that fits the scope of the WG, we'd also like them to not become major technical contributors. The current charter revision is at http://www1.ietf.org/mail-archive/ web/pcn/current/msg00261.html, but likely to change. Note: We're trying to train new chairs for the TSV area, so there is *no* requirement to having had prior chairing experience. If you are interested in co-chairing PCN, please respond to tsvwg- ads@tools.ietf.org with your name, affiliation and a brief summary of your IETF experience by February 9, 2006. Thanks, Lars --Apple-Mail-80-371657636 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjYwOTQ4MjJaMCMGCSqGSIb3DQEJBDEWBBTRGW/FDyuE4q+R Hwk6MZSIS3tNYzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAsC1e+UxWAkaXmydOEnMP8n+2D3lCuhEBvs1SY2dF8f2XG0YUk+Yg 1x/GSEd6tRIDRYdkbKspDgT8LQU1pXktG2NuxBK5pj0UAFYpotkUN1Zr3oW6nP3GztlBTtMOad7S 0kq15IfGCJWMji6DX7nnkGbYRRvF1bVOMHTPkRTtn0W/eYymEWnH/fcQmlYEo85QUpdND00PPQx6 V7P9qf8vY5W+sar5zLczs+ulOdU07zb+oj+ak3MICpUiGBWRjoIl0l5xggnL3u8z3LmSLmFItJFI aZHR3gc1n71+7x5cwTZaYQU9LotR8SgFaQnskxrFmY4xxrnwjEEO6dtaoM1d0AAAAAAAAA== --Apple-Mail-80-371657636-- From tsvwg-bounces@ietf.org Fri Jan 26 08:39:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HARI0-0004rE-I0; Fri, 26 Jan 2007 08:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HARHz-0004r9-Ag for tsvwg@ietf.org; Fri, 26 Jan 2007 08:38:47 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HARHw-0005ZJ-Lx for tsvwg@ietf.org; Fri, 26 Jan 2007 08:38:47 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2007 05:38:44 -0800 X-IronPort-AV: i="4.13,242,1167638400"; d="scan'208"; a="105738365:sNHT59908068" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0QDciHC007678; Fri, 26 Jan 2007 05:38:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QDcfDk006557; Fri, 26 Jan 2007 05:38:41 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 05:38:41 -0800 Received: from [10.32.241.68] ([10.32.241.68]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 05:38:40 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Davie Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Date: Fri, 26 Jan 2007 08:38:25 -0500 To: Dimitri.Papadimitriou@alcatel-lucent.be X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jan 2007 13:38:40.0984 (UTC) FILETIME=[4A671580:01C7414F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5434; t=1169818724; x=1170682724; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bdavie@cisco.com; z=From:=20Bruce=20Davie=20 |Subject:=20Re=3A=20[Tsvwg]=20Making=20draft-davie-ecn-mpls=20a=20TSVWG=2 0item |Sender:=20; bh=E/VuGQ9/wknIiOby9o2F+8dA0dsaTXFePwBuDLwcL4Y=; b=GqrjNBD3Yn4e0QbTsJPvAHa1atyi5KBS4LbGfmKtGY5Y5y6degBGUN8n8GAx4xsDnQD0M0Qj 8lt4oETKX/HmEbp67Afer7SYqghAsRptrFBOv1vUm8bNsnD7uR7EFa9u; Authentication-Results: sj-dkim-4; header.From=bdavie@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org On Jan 25, 2007, at 7:07 PM, Dimitri.Papadimitriou@alcatel-lucent.be wrote: > lars - > > i am more generally questioning cost/perf. gain & value for 3 > major reasons (they would deserve imho further discussion - or > at least further proof of evidence) > > o) if it is to come up with a forwarding paradigm that becomes > equivalent to IP probably we should then start questioning the > need for MPLS itself (in part. in the present case focusing on > intra-domain operations where i always thought that data-traffic > and resource-oriented perf. objectives were taken into account > for edge-to-edge MPLS path provisioning) I think the need for MPLS is to support capabilities like VPNs and constraint-based routing. Giving MPLS the ability to support Diffserv (as was done in RFC3240) did not take away the need for VPNs or constraint-based routing. It simply enabled an operator to deploy MPLS to gain the extra capabilities of MPLS, without giving up the ability to do Diffserv. The same reasoning applies here: we want to allow an operator to deploy MPLS for the purposes of VPNs, TE, etc., without forcing him to give up the ability to do ECN. Of course, an operator who has no interest in ECN can leave this functionality disabled, just as RFC3270 functionality can be disabled for those operators who don't care for it. In short, adding more capabilities to MPLS does not negate the advantages that MPLS brings. > > o) MPLS paradigm assumed "intelligence@edges" we progressively > enter into a mode where intermediate LSRs will become (see end > of section 3) progressively require/result again more selective > processing of traffic > I'm not at all convinced that view is universally held. The task of assigning packets to FECs is indeed done at the edges, but I don't believe there is a grand principle that says MPLS core devices must do nothing other than forward packets based on the label. In fact, as one of the people who designed the MPLS shim header, I can say that the reason for reserving the 3 "EXP" bits was to allow for queueing treatment to be applied to packets independent of the label. That is exactly what both RFC3270 and this mpls-ecn draft do with those bits. > o) initial MPLS-ECN based its reasoning on expectations from > experience - quoting: > > "We believe the benefits from ECN of better overall performance > for a wide range of applications because of reduced packet loss > (especially those using non-TCP transports) and reduced queueing > delay is sufficiently significant. Furthermore, there seems to > be no reasons for LSRs to lack this capability as it becomes > available in other (non-label switched) IP routers." > > it would have been interesting to sustain the reasoning with > more tangible proofs - with the underlying question are we here > waiting for this doc. to make such experiment possible ? It is certainly true that ECN has yet to be proven to be universally useful. That is one reason why the draft goes to some lengths to specify this as optional behavior. But I can't see what bad thing will happen if TSVWG starts working on an MPLS ECN draft now. If proven utility is the standard that we have to reach before embarking on a working group draft, then a lot of work at the IETF should be stopped now. Bruce > > much thanks, > - d. > > > > > > > > 18/01/2007 11:49 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: tsvwg@ietf.org > Subject: RE: [Tsvwg] Making draft-davie-ecn-mpls a > TSVWG > item > > > < Attachment smime.p7s removed > > > > Dimitri, > >> discussion was led on the list mid november - no real >> conclusion or action where derived from the concerns >> expressed at that time > > thanks for pointing out that this draft was also discussed elsewhere! > > As for your specific points: > >>> 1. CN marking in the EXP bits of the MPLS header falls imho under > the >>> MPLS change process that states for an optional problem statement > and >>> a mandatory prior requirements statement I-D to commit for any >>> specific change or extension to MPLS >>> >>> see section 2.1.1 and 4.2 of >>> > change-06 > .txt> > > The process described in that document isn't official procedure > yet, and > has raised significant concern in parts of the IESG. IMO it is > unlikely > to proceed without major changes. Hence, it's questionable that we > should apply it here and now. > >> [dp] the same section 7 mentions >> >> "[RFC3168] does not give any reasons against conveying CE information >> from the inner header to the outer in the "full functionality" >> mode." >> >> nor the other way around - which leaves the point open for ECN itself >> -> the issue i am raising is that in absence of evidence current the >> processing should be left per RFC3168 and not inline with the >> expected >> PCN needs (even if it does not affect the former) > > I'm not quite sure I understand your point - are you saying that the > benefits of ECN for MPLS are unclear? > > Thanks, > Lars > -- > NEW EMAIL: lars.eggert@nokia.com > NEW MOBILE: +358 50 48 24461 > NEW JABBER: lars.eggert@googlemail.com > > > > From tsvwg-bounces@ietf.org Fri Jan 26 12:50:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVCO-00056t-L7; Fri, 26 Jan 2007 12:49:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVCN-00056i-0s for tsvwg@ietf.org; Fri, 26 Jan 2007 12:49:15 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVCL-0001v6-Mr for tsvwg@ietf.org; Fri, 26 Jan 2007 12:49:15 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2007 12:49:13 -0500 X-IronPort-AV: i="4.13,244,1167627600"; d="scan'208"; a="112561706:sNHT45327456" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QHnD3U008881 for ; Fri, 26 Jan 2007 12:49:13 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QHnDVT010844 for ; Fri, 26 Jan 2007 12:49:13 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:49:13 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.16.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:49:12 -0500 Message-Id: <4.3.2.7.2.20070126114550.027fb828@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2007 11:49:12 -0600 To: tsvwg From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Jan 2007 17:49:12.0914 (UTC) FILETIME=[4A219320:01C74172] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2077; t=1169833753; x=1170697753; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for= 20the=2068th=20IETF=0A=20=20=20Meeting=20in=20Prague, =20Czech=20Republic=2 0 |Sender:=20 |To:=20tsvwg=20; bh=jFz/PO5Abwx+rJI2EHpJ1DV2IOUA2/AIQXqVK4H5IQM=; b=AeGTGMVfviyBPX8CiaA701hudr6wAiV08StZtiKi/EusNfwDtg9iEahF1LOCSOLhShmiqBMw M379bw36lmbxWcKaIPhhCgOwz2Q6QDq/cF2cv9Vl2YLaDjVsAt64Ld6b; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Tsvwg] Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org fyi and please, if you are submitting into TSVWG, please include "tsvwg" in the filename so the chairs can track the docs, for example: draft-polk-tsvwg-....-00.txt The above would be if I were to write an ID into tsvwg the first time. Thank you! >From: ietf-secretariat@ietf.org >Date: Fri, 26 Jan 2007 00:00:02 -0500 >Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF > Meeting in Prague, Czech Republic > >There are two (2) Internet-Draft cutoff dates for the 68th >IETF Meeting in Prague, Czech Republic: > >February 26th: Cutoff Date for Initial (i.e., version -00) >Internet-Draft Submissions > >All initial Internet-Drafts (version -00) must be submitted by Monday, >February 26th at 9:00 AM ET. As always, all initial submissions with a >filename beginning with "draft-ietf" must be approved by the >appropriate WG Chair before they can be processed or announced. The >Secretariat would appreciate receiving WG Chair approval by Monday, >February 19th at 9:00 AM ET. > >March 5th: Cutoff Date for Revised (i.e., version -01 and higher) >Internet-Draft Submissions > >All revised Internet-Drafts (version -01 and higher) must be submitted >by Monday, March 5th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their respective >cutoff dates will not be made available in the Internet-Drafts >directory or announced until on or after Monday, March 19th at 9:00 >AM ET, when Internet-Draft posting resumes. Please do not wait until >the last minute to submit. > >Thank you for your understanding and cooperation. If you have any >questions or concerns, then please send a message to >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other significant dates >for the 68th IETF Meeting can be found at >http://www.ietf.org/meetings/cutoff_dates_68.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce From tsvwg-bounces@ietf.org Sun Jan 28 23:52:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOTv-0006fS-4u; Sun, 28 Jan 2007 23:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOTt-0006fN-4H for tsvwg@ietf.org; Sun, 28 Jan 2007 23:51:01 -0500 Received: from smtpout.mac.com ([17.250.248.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBOTq-0001GF-Jb for tsvwg@ietf.org; Sun, 28 Jan 2007 23:51:00 -0500 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id l0T4op30019703; Sun, 28 Jan 2007 20:50:51 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-226-78.dsl.snfc21.sbcglobal.net [70.231.226.78]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l0T4omtL004709; Sun, 28 Jan 2007 20:50:49 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1be98113302be79756ad291725ac6dab@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] ECN nonce snag in TCP ESTATS MIB Date: Sun, 28 Jan 2007 20:50:47 -0800 To: Matt Mathis X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: djw@cs.washington.edu, nspring@cs.washington.edu, TCP ESTATS MIB team , ely@cs.washington.edu, Transport WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Matt - > The document draft-ietf-tsvwg-tcp-mib-extension has been stalled due > to a > "DOWNREF", a normative reference from a standards track document to > to a less mature document. In this case to an Experimental Protocol, > RFC3540, > Robust ECN Signaling with Nonces. ... > There are two obvious approaches to fix this: > 1) Pursue the downref procedure in RFC 3967. This entails writing a > justification for the downward reference and re-issuing the IETF last > call. > 2) Deleting the object entirely. Since this is a substantial > technical change > to the document, it requires re-issuing the TSVWG LC and possibly the > IETF LC. > > I am willing to pursue either approach, however I think it would be > best to > match the likely ultimate trajectory for RFC 3540. > > My questions: > Are there any known implementations of RFC3540 in the field? > > Can somebody provide some pointers to either dependent or alternative > nonce mechanisms? > > Given that RFC 3540 conflicts with RE-ECN, what is (your opinion of) > the > likely trajectory for RFC 3540? My apologies for the long delay in getting to this. If this is still an open question, my preference would be for (1), writing a justification for the downward reference, and keeping the ECN nonce item in the TCP MIB. I don't know of any implementations of RFC 3540. However, my own prediction would be that RFC 3540 would eventually become Proposed Standard, regardless of the fact that RE-ECN conflicts with the ECN Nonce. For a first draft of mine on why RFC 3540 should go to Proposed Standard (not yet submitted as an internet-draft), you could see the following: "http://www.icir.org/floyd/papers/draft-floyd-tsvwg-ecn-nonce-00a.txt" - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Mon Jan 29 02:41:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBR8H-0003Hz-6U; Mon, 29 Jan 2007 02:40:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBR8F-0003Hr-Nu for tsvwg@ietf.org; Mon, 29 Jan 2007 02:40:51 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBR8E-00012e-BI for tsvwg@ietf.org; Mon, 29 Jan 2007 02:40:51 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0T7cZi3004091 for ; Mon, 29 Jan 2007 09:38:41 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 09:40:31 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 09:40:31 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: tsvwg Message-Id: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-623196960; protocol="application/pkcs7-signature" From: Lars Eggert Date: Mon, 29 Jan 2007 09:40:41 +0200 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 07:40:31.0020 (UTC) FILETIME=[C0A00EC0:01C74378] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-2-623196960 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, the authors of draft-floyd-tsvwg-cc-alt have asked us to adopt the document as a WG item with a publication target of BCP. Please review the document and send your comments to the list no later than Friday, Feb 9. Thanks, Lars --Apple-Mail-2-623196960 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkwNzQwNDFaMCMGCSqGSIb3DQEJBDEWBBR/+8iJdENCIrki dDDqCV70h+X77jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAO5l1yxlPGe3Q8vdcgJtjvzZ/d+z78FpyPTgkqNSNOGFnBKr37o3L zTYTn1ePl8LGW046Y8QY4YLVWDj4PxkH1fOW2Z8+HNg+QRL4aU1AkWLBWDVlj06sr3Ep2yd7KUfs 4PBzF2IwMpU/d4+4RohCjaf0yyOxUvwmpj7Z6YNxYVqx4dEoXlFo3YL3GJJGVUd3juSrRUjHJ3vt IT/T4MMAsV1yQg/vKDSlFSUKp4GAs4rgeslYFMxDUQ803q3j1CFjMqaq9w5J8V4tky9N44oBTeK8 1Zn+r/qlA+AGYUvexGxFB4Oypf5Z5fAjFjYft29wGpeInzOeqWANW9Zzi3O0uwAAAAAAAA== --Apple-Mail-2-623196960-- From tsvwg-bounces@ietf.org Mon Jan 29 14:53:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcYF-0000y6-LZ; Mon, 29 Jan 2007 14:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcYD-0000xw-WE for tsvwg@ietf.org; Mon, 29 Jan 2007 14:52:26 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBcY8-0004ri-KZ for tsvwg@ietf.org; Mon, 29 Jan 2007 14:52:25 -0500 Received: from jurassic.eng.sun.com ([129.146.108.38]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0TJqHHi028818; Mon, 29 Jan 2007 12:52:17 -0700 (MST) Received: from [129.146.107.157] (d-mpk17-107-157.SFBay.Sun.COM [129.146.107.157]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0TJqGGh319403; Mon, 29 Jan 2007 11:52:16 -0800 (PST) Message-ID: <45BE50C2.2020306@sun.com> Date: Mon, 29 Jan 2007 11:53:38 -0800 From: Anders Persson User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: [Tsvwg] TCP and UDP MIB issues References: <45A68ABA.9070501@sun.com> <45B5E8BD.1080504@erg.abdn.ac.uk> In-Reply-To: <45B5E8BD.1080504@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Gerrit Renker , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Gorry, The same general issue does seem to appear within the UDP-Lite MIB, which is how to deal with multiple processes using the same UDP-Lite endpoint. For example, on a system using sockets, you can have one socket being shared between multiple processes if the creator of the socket uses fork() to create child processes. However, with the current MIB it is only possible to associate one processes with an endpoint. There are at least four ways this could be addressed: (1) Use udpliteEndpointInstance to create multiple entries. Unfortunately, this approach makes it look like multiple independent endpoints, which might be a bit deceiving (2) Make udpliteEndpointProcess part of the INDEX (3) Create a new Identifier object (like tcpEStatsConnectIdEntry), which could then be referenced by other tables. For example, we could then have udpliteProcessTable (4) Create udpliteProcessTable that mirrors the INDEX of udpliteEndpointTable, but adds udpliteEndpointProcess to the INDEX as well :-( My personal choice would be (3), as it allows the MIB to be extended in the future. Cheers, Anders Gorry Fairhurst wrote: > > Generally, the proposed UDP-Lite MIB follows that for UDP (supporting > both multicast and unicast). It does differ in the udpliteEndpointTable: > > http://tools.ietf.org/wg/tsvwg/draft-renker-tsvwg-udplite-mib-01.txt > > If there are implications on the UDP-Lite MIB, we'd be pleased to try > to understand what these are, and any ideas of what we should do. > > Best wishes, > > Gorry > From tsvwg-bounces@ietf.org Mon Jan 29 15:40:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdHi-0003m0-P7; Mon, 29 Jan 2007 15:39:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdHh-0003lu-T7 for tsvwg@ietf.org; Mon, 29 Jan 2007 15:39:25 -0500 Received: from mail.nuim.ie ([149.157.1.19] helo=LARCH.MAY.IE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdHb-0004ZV-EY for tsvwg@ietf.org; Mon, 29 Jan 2007 15:39:25 -0500 Received: from [192.168.0.3] ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01MCIJHSYTRI0169FG@NUIM.IE> for tsvwg@ietf.org; Mon, 29 Jan 2007 20:39:40 +0000 (GMT) Date: Mon, 29 Jan 2007 20:38:28 +0000 From: Douglas Leith In-reply-to: To: tsvwg@ietf.org Message-id: <07C47285-B415-415F-A37B-F818DBBF0943@nuim.ie> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Tsvwg] draft-floyd-tsvwg-cc-alt-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org A couple of brief comments/queries on this ID ... The "Difficult Environments" clause is important but pretty non- specific at the moment. It might be helpful to provide a few more examples illustrating the types of situations you have in mind. It might also worth commenting in some way that the performance of standard TCP is not necessarily all that well understood in some challenging environments -- for example,TCP performance in 802.11 wireless environments is still an active research topic; similarly behaviour with reverse path queueing. As a result, it might not be entirely reasonable to place a much higher bar on new algorithms than currently exists for standard TCP. Similar comments apply to the "Responses to Sudden or Transient Events" text. At the moment its not clear where the real thrust of this is aimed at and so its usefulness as a guideline is perhaps reduced. Doug www.hamilton.ie On 29 Jan 2007, at 07:40, tsvwg-request@ietf.org wrote: > Send tsvwg mailing list submissions to > tsvwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/tsvwg > or, via email, send a message with subject or body 'help' to > tsvwg-request@ietf.org > > You can reach the person managing the list at > tsvwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tsvwg digest..." > > > Today's Topics: > > 1. HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt (Lars > Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Jan 2007 09:40:41 +0200 > From: Lars Eggert > Subject: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt > To: tsvwg > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi, > > the authors of draft-floyd-tsvwg-cc-alt have asked us to adopt the > document as a WG item with a publication target of BCP. > > Please review the document and send your comments to the list no > later than Friday, Feb 9. > > Thanks, > Lars > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2446 bytes > Desc: not available > Url : http://www1.ietf.org/pipermail/tsvwg/attachments/ > 20070129/9cfe54ea/smime.bin > > End of tsvwg Digest, Vol 33, Issue 39 > ************************************* From tsvwg-bounces@ietf.org Mon Jan 29 18:30:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfvs-0003E6-CA; Mon, 29 Jan 2007 18:29:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfvq-0003Do-I1 for tsvwg@ietf.org; Mon, 29 Jan 2007 18:29:02 -0500 Received: from smtpout.mac.com ([17.250.248.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfvo-0004JB-4a for tsvwg@ietf.org; Mon, 29 Jan 2007 18:29:02 -0500 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id l0TNSrVm024492; Mon, 29 Jan 2007 15:28:53 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-226-78.dsl.snfc21.sbcglobal.net [70.231.226.78]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l0TNSkV2021978; Mon, 29 Jan 2007 15:28:47 -0800 (PST) In-Reply-To: <07C47285-B415-415F-A37B-F818DBBF0943@nuim.ie> References: <07C47285-B415-415F-A37B-F818DBBF0943@nuim.ie> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3bddc50e49533049bb182c33509ea36a@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [Tsvwg] draft-floyd-tsvwg-cc-alt-00.txt Date: Mon, 29 Jan 2007 15:28:46 -0800 To: Douglas Leith X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Transport WG , Mark Allman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Doug - > The "Difficult Environments" clause is important but pretty > non-specific at the moment. It might be helpful to provide a few > more examples illustrating the types of situations you have in mind. > It might also worth commenting in some way that the performance of > standard TCP is not necessarily all that well understood in some > challenging environments -- for example,TCP performance in 802.11 > wireless environments is still an active research topic; similarly > behaviour with reverse path queueing. As a result, it might not be > entirely reasonable to place a much higher bar on new algorithms than > currently exists for standard TCP. > > Similar comments apply to the "Responses to Sudden or Transient > Events" text. At the moment its not clear where the real thrust of > this is aimed at and so its usefulness as a guideline is perhaps > reduced. We will add more examples to both sections. We will also try to make the context more clear. The intent is not to place a higher bar on new algorithms than on standard TCP, in terms of performance. But if a new mechanism is shown to perform significantly worse than standard TCP in "Difficult Environments" on in "Responses to Sudden or Transient Events", my hope would be that the IETF takes this into account in its recommentations concerning the appropriate deployment of the new mechanism in question. - Sally http://www.icir.org/floyd/ From tsvwg-bounces@ietf.org Mon Jan 29 19:13:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgcM-0005A3-Tq; Mon, 29 Jan 2007 19:12:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgcL-00059y-Oz for tsvwg@ietf.org; Mon, 29 Jan 2007 19:12:57 -0500 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgcE-0002zc-0o for tsvwg@ietf.org; Mon, 29 Jan 2007 19:12:57 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 00:12:44 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Jan 2007 00:12:43 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1170115962362; Tue, 30 Jan 2007 00:12:42 +0000 Received: from mut.jungle.bt.co.uk ([10.86.0.7]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l0U0CYU6008497; Tue, 30 Jan 2007 00:12:41 GMT Message-Id: <5.2.1.1.2.20070129221119.028df180@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 30 Jan 2007 00:10:27 +0000 To: Sally Floyd , Matt Mathis From: Bob Briscoe Subject: Re: [Tsvwg] ECN nonce snag in TCP ESTATS MIB In-Reply-To: <1be98113302be79756ad291725ac6dab@mac.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Jan 2007 00:12:43.0912 (UTC) FILETIME=[5CFE7880:01C74403] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: djw@cs.washington.edu, TCP ESTATS MIB team , nspring@cs.washington.edu, ely@cs.washington.edu, Transport WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Matt, Sally, At 04:50 29/01/2007, Sally Floyd wrote: >Matt - > >>The document draft-ietf-tsvwg-tcp-mib-extension has been stalled due to a >>"DOWNREF", a normative reference from a standards track document to >>to a less mature document. In this case to an Experimental Protocol, >>RFC3540, >>Robust ECN Signaling with Nonces. >... >>There are two obvious approaches to fix this: >>1) Pursue the downref procedure in RFC 3967. This entails writing a >>justification for the downward reference and re-issuing the IETF last call. >>2) Deleting the object entirely. Since this is a substantial technical >>change >>to the document, it requires re-issuing the TSVWG LC and possibly the >>IETF LC. >> >>I am willing to pursue either approach, however I think it would be best to >>match the likely ultimate trajectory for RFC 3540. Reasonable approach, but difficult to judge... >>My questions: >>Are there any known implementations of RFC3540 in the field? >> >>Can somebody provide some pointers to either dependent or alternative >>nonce mechanisms? back in Nov '06 I promised an alternative at the transport layer. It's nearly complete (but internally we also still have to get clearance to publish). As I said when I promised it, it deals with the problems of receivers suppressing losses (including optimistic acks and split acks), but not ECN (which we claim re-ECN would cover). >>Given that RFC 3540 conflicts with RE-ECN, what is (your opinion of) the >>likely trajectory for RFC 3540? > >My apologies for the long delay in getting to this. If this is still an >open question, >my preference would be for (1), writing a justification for the downward >reference, >and keeping the ECN nonce item in the TCP MIB. I have no preference. All I'll try to do is advise on the likely course of RFC3540 and re-ECN, so the TCP ESTATS MIB authors can judge what is best. 1/ Our considered opinion of the worth of the ECN nonce is given in Appendix I of . In summary: "Delaying the ECN nonce is justified because the applicability of the ECN nonce seems too limited for it to consume a two-bit codepoint in the IP header. " By 'too limited', we mean it is no longer sufficient to consider that senders will protect the network against abuse. When the nonce was first proposed, that seemed reasonable, given most big senders were managed servers. Now nearly everyone's a big sender. See the diag in slide 6 that I showed at IETF-67: Another argument (new since in Appendix I): A sender cannot use the ECN nonce to detect a cheating receiver if the receiver claims not to support the ECN nonce. All it can do is throttle all receivers that don't support the ECN nonce (currently it would have to throttle everyone except Neil). There's no alternative deployment incentive to get round this deployment bootstrap killer. 2/ On the other hand, re-ECN is still a long way from general acceptance - I think in most people's minds it is at the stage of "sounds interesting, but it has major implications so we need to understand these better". I'm second-guessing voter's reasoning, but I suspect that was why the straw poll at IETF-67 preferred RFC3540 to be held back at experimental for longer, in case the ECT(1) codepoint in the IPv4 header could indeed be better used for re-ECN (given it polices senders as well as receivers). I'm acutely aware that what re-ECN claims to do is fix a very hard problem. Doing this in the minimal available space left in the IPv4 header was never going to be easy. Originally our target was for IPv6 or a 'future Internet architecture'. Then we came up with a way it could just be squeaked into IPv4 as well. I live in fear of an attack on re-ECN being published that no-one can fix within the available space. Then we'd have to return to the original target of something like re-ECN in IPv6 and 'future architectures'. But all security solutions are in this constant state of uncertainty (HMAC & SHA hash algorithms being current cases in point). --- Either way, Neil Spring's right that we have the ECN nonce innoculation sitting on the shelf if we need it. I know Neil didn't like the conclusion "too limited for IP header." But I'd like to hear Neil's thoughts on each of the critiques of the ECN nonce that we wrote into Appendix I of . Despite appearances, I'm willing to shut up if the carefully thought through points I make are successfully argued down. >I don't know of any implementations >of RFC 3540. However, my own prediction would be that RFC 3540 would >eventually become Proposed Standard, regardless of the fact that RE-ECN >conflicts with the ECN Nonce. For a first draft of mine on why RFC 3540 >should go to Proposed Standard (not yet submitted as an internet-draft), >you could see >the following: > "http://www.icir.org/floyd/papers/draft-floyd-tsvwg-ecn-nonce-00a.txt" Sally, I understand this is not a complete draft, but I think it needs to address each critique we made of the ECN nonce in Appendix I mentioned above. Currently it just says the nonce is good without rebutting anything that's been said against it. I'm not saying re-ECN's perfect, but I don't think the criticism you've chosen is valid. You seem to be saying re-ECN doesn't protect parts of the network that haven't deployed it. That's like saying Yale locks are crap because burglars can break in to your porch if you only install a Yale lock on the inner door of your porch. Perhaps you meant it might be hard to deploy at the very edge? Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From tsvwg-bounces@ietf.org Mon Jan 29 19:49:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhB0-00056c-2j; Mon, 29 Jan 2007 19:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhAw-00056D-J6; Mon, 29 Jan 2007 19:48:42 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhAu-0000lW-T5; Mon, 29 Jan 2007 19:48:42 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l0U0mewl030715; Mon, 29 Jan 2007 16:48:40 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l0U0mehx030714; Mon, 29 Jan 2007 16:48:40 -0800 Date: Mon, 29 Jan 2007 16:48:40 -0800 Message-Id: <200701300048.l0U0mehx030714@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [Tsvwg] RFC 4782 on Quick-Start for TCP and IP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4782 Title: Quick-Start for TCP and IP Author: S. Floyd, M. Allman, A. Jain, P. Sarolahti Status: Experimental Date: January 2007 Mailbox: floyd@icir.org, mallman@icir.org, a.jain@f5.com, pasi.sarolahti@iki.fi Pages: 82 Characters: 214489 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-quickstart-07.txt URL: http://www.rfc-editor.org/rfc/rfc4782.txt This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request. This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Transport Area Working Group Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From tsvwg-bounces@ietf.org Wed Jan 31 05:29:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCChY-0003By-OY; Wed, 31 Jan 2007 05:28:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCChX-0003Bs-GP for tsvwg@ietf.org; Wed, 31 Jan 2007 05:28:27 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCChU-0002Ya-1d for tsvwg@ietf.org; Wed, 31 Jan 2007 05:28:27 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VAPJLp028963; Wed, 31 Jan 2007 12:25:26 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:28:06 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 12:27:52 +0200 In-Reply-To: <1be98113302be79756ad291725ac6dab@mac.com> References: <1be98113302be79756ad291725ac6dab@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-88-806037935; protocol="application/pkcs7-signature" Message-Id: <683DEDB6-0365-41C9-9E4B-F3AD2C5BB982@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] ECN nonce snag in TCP ESTATS MIB Date: Wed, 31 Jan 2007 12:28:02 +0200 To: ext Sally Floyd X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 10:27:52.0057 (UTC) FILETIME=[76603690:01C74522] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Matt Mathis , djw@cs.washington.edu, Transport WG , nspring@cs.washington.edu, ely@cs.washington.edu, TCP ESTATS MIB team X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-88-806037935 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-29, at 6:50, ext Sally Floyd wrote: > My apologies for the long delay in getting to this. If this is > still an open question, > my preference would be for (1), writing a justification for the > downward reference, > and keeping the ECN nonce item in the TCP MIB. I don't know of any > implementations > of RFC 3540. However, my own prediction would be that RFC 3540 would > eventually become Proposed Standard, regardless of the fact that RE- > ECN > conflicts with the ECN Nonce. For a first draft of mine on why RFC > 3540 > should go to Proposed Standard (not yet submitted as an internet- > draft), you could see > the following: > "http://www.icir.org/floyd/papers/draft-floyd-tsvwg-ecn- > nonce-00a.txt" The result of our mini-WGLC didn't bring up any disagreements with Matt's proposed approach, namely, to remove a part of the MIB, and we've taken that route. A future revision/augmentation of the MIB can add the removed parts, if the ECN nonce progresses. Lars --Apple-Mail-88-806037935 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExMDI4MDJaMCMGCSqGSIb3DQEJBDEWBBT8rjBLF8BZaQMq LtyY3nmf+0Tg+DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAYyG14OTW2wygqU70bKlTh6ua4zWJo6noWTE/GTr6e1uS6P7cukyd tPp8EmxOTnXYVU6aX5s0zI4ZI2CHElllgO3YRwjNozignBFeywuk4PsIHgo0Jl7JvqxyeggTbONs oOOc2vsMgDN9g8h0AYrq8aZys5axjcuqdEj6Xh3rObggWtSz/BFpVpji+Snv73nibyuonHRnke3t S1DoNWWl298THnGOBB57J4pt0Q0KZKj+SkNhHrGbh9I2oEpbd8PiNurTW8TI3KSR/07x7EKGDcjG jT+h83J//X84Fh+GyBF0DizW3blU3bJ0izELC8pHN3+QLAFBrTL/Ojy7z5CxcgAAAAAAAA== --Apple-Mail-88-806037935-- From tsvwg-bounces@ietf.org Wed Jan 31 05:32:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCClh-0005Ao-3o; Wed, 31 Jan 2007 05:32:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCClf-00058r-JR for tsvwg@ietf.org; Wed, 31 Jan 2007 05:32:43 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCClb-0003ua-OW for tsvwg@ietf.org; Wed, 31 Jan 2007 05:32:43 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VAUQM2022776; Wed, 31 Jan 2007 12:30:33 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:32:08 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 12:32:08 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-89-806295500; protocol="application/pkcs7-signature" Message-Id: <46A086EF-F492-4B53-88D4-9A630AE251F9@nokia.com> From: Lars Eggert Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item Date: Wed, 31 Jan 2007 12:32:19 +0200 To: ext Bruce Davie X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 10:32:08.0807 (UTC) FILETIME=[0F692770:01C74523] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org --Apple-Mail-89-806295500 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, FYI, my current view of the consensus is that although some concerns have been raised, the bulk of the overall comments on this document (meeting + list) have been positive. Please send final comments by the end of this week. Lars --Apple-Mail-89-806295500 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExMDMyMjBaMCMGCSqGSIb3DQEJBDEWBBQAbtQWgdMivZxA 86VOfceXXTYIzTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAuamyrhDGZ7270OneHf28Ho6rkMV8+tVEZ4gO2oqUbTKTco548Fce UWpGg4DL5e71qJamcR0YnCmpPu4x7Av38tITLksghjVHBtT76kh4ekeH/4V0Xn+Cox/0/TK1ib71 zv6kXXQyxPnHwFDAbT9lNjzJiagBJ79yuxdvWJL1wuC40UipQqgAUiH2LcDxuel6ZrVm9hJNNnxD E+bLclzT2oy3+lLA80WnXAPQJHL0jM2st9ztLctNpDHF5QlGbXDJKlP+Cp6ZX6PmSsTQTfN13LCe +YgRiKogVlCOfAdWpIQ9dNnlTnrlE6TwM6vBiIztfec6lDCMX5kQXvbWdSbh/AAAAAAAAA== --Apple-Mail-89-806295500-- From tsvwg-bounces@ietf.org Wed Jan 31 10:15:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHAh-0002ee-Ob; Wed, 31 Jan 2007 10:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHAg-0002eX-6b for tsvwg@ietf.org; Wed, 31 Jan 2007 10:14:50 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHAd-0005Wf-MW for tsvwg@ietf.org; Wed, 31 Jan 2007 10:14:50 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VFEk4u011502 for ; Wed, 31 Jan 2007 16:14:46 +0100 From: Michael Welzl To: tsvwg@ietf.org Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1170256466.4805.614.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Jan 2007 16:14:26 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: () -4.4 ALL_TRUSTED,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Tsvwg] Separate header checksums and WiFi X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org Dear all, A long time ago, at the San Diego IETF meeting in August 2004, I presented an idea called "Corruption Notification Options" (a proposal which is some sort of a refined specification of the TCP HACK idea) to the TCPM group. The group's feedback was that this is useless, as errors occur in such a clustered fashion that you wouldn't see any packets with an intact header but erroneous payload (which is the only situation where the scheme would yield any benefit). I think that it was Gorry Fairhurst who said this. I figured that the only convincing way to prove him wrong is to actually do a real-life test. I did, and proved him right :) that is, disabling checksums for parts of packets doesn't yield much of a benefit in WiFi networks, where it seems that frames are delivered in an all-or-nothing fashion. Doing this test requires patching the device driver (to disable the link layer CRC), and above all, finding a good student - all of this took quite some time, but now it's over, and the documentation can be found at: http://www.welzl.at/research/projects/corruption/ (bottom of the page) I learned my lesson, and thought I'd share it with you - but this result only concerns WiFi. I'll keep this as a low-priority "background" project and may take a closer look at other link layers one day... in any case, that topic still interests me, and I can't believe that it wouldn't be possible to get a benefit out of such a scheme. I'm sending this note to TCPM, TSVWG and DCCP because there are similar mechanisms there (DCCP: the Data Checksum option; SCTP: http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt although I just noticed that this is apparently not a WG item... still, it's SCTP related). This note also goes to ICCRG, because I think that this should be the place for related discussions (in fact Lachlan Andrew will give us a related talk at our upcoming meeting: http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda ) Cheers, Michael