[RTG-DIR] RtgDir Review: draft-ietf-pals-congcons-01
"Keyur Patel (keyupate)" <keyupate@cisco.com> Tue, 08 December 2015 03:08 UTC
Return-Path: <keyupate@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C61B2B62 for <rtg-dir@ietfa.amsl.com>; Mon, 7 Dec 2015 19:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZlfbyY6q_Fe for <rtg-dir@ietfa.amsl.com>; Mon, 7 Dec 2015 19:08:42 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA3F1B2B61 for <rtg-dir@ietf.org>; Mon, 7 Dec 2015 19:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36091; q=dns/txt; s=iport; t=1449544122; x=1450753722; h=from:to:cc:subject:date:message-id:mime-version; bh=ErG1p2NyCPxeS/76iUIe67NXBGjjvJEoJcap4psT+zo=; b=YbKtOXOOiJmlwWzLCDUw1iEW4Xc7tAQI3eNUEZIj+A70l7ilDAeK6C32 lRBbdxYLkL0gXqKRtg+okXWtKpc03dKCxkZHmm48dr7elM0xCCSbyOolk CIVVrCxD96cIa4YZLk4Xp7VFA879nf+6ZeJvbiLdiBdlUCDjiB/WkSrBX Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BQBABbSWZW/51dJa1egm5MU24GvQMrAQ2BbiGFbR6BKTgUAQEBAQEBAYEKhDcEI0QSEgEcJAoCBDAnBAENiDQNsDCQfwEBAQEBAQQBAQEBAQEBARuGVIkxR4J8gUQFkneDagGFLIJyhR2BW0mDepZOAREOAQFChARzhCRDgQcBAQE
X-IronPort-AV: E=Sophos; i="5.20,397,1444694400"; d="scan'208,217"; a="56310791"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2015 03:08:40 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tB838dah012718 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Dec 2015 03:08:40 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Dec 2015 22:08:39 -0500
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Mon, 7 Dec 2015 22:08:39 -0500
From: "Keyur Patel (keyupate)" <keyupate@cisco.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "Jon Hudson (jon.hudson@gmail.com)" <jon.hudson@gmail.com>
Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-pals-congcons-01
Thread-Index: AQHRMWW8YjppKcE4eEqzcuVciM6wGQ==
Date: Tue, 08 Dec 2015 03:08:39 +0000
Message-ID: <D28B89B4.31DBA%keyupate@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.46.200]
Content-Type: multipart/alternative; boundary="_000_D28B89B431DBAkeyupateciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/3KHCyThkFwr6YxZBpvxZCRRr5QI>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-pals-congcons.all@tools.ietf.org" <draft-ietf-pals-congcons.all@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: [RTG-DIR] RtgDir Review: draft-ietf-pals-congcons-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 03:08:46 -0000
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir. Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pals-congcons-01 Reviewer: Keyur Patel Review Date: 07-Dec-2015 Intended Status: Informational Track Summary: No major technical issues found. Minor nits are listed below. Comments: IMHO, the document authors could try and simplify the document text. Major Issues: None. Minor Issues None. Nits: 1) Abstract: <snip> PWs consume no more network capacity than a TCP flow. </snip> Consider replacing with: PWs do not consume any more network capacity than a TCP flow. 2) Abstract: <snip> For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater than this bound, and typically much lower. </snip> consider replacing with: For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater than this bound, and is typically much lower. 3) Abstract: <snip> with acceptable TDM service criteria. </snip> consider replacing with: with an acceptable TDM service criteria. 4) Introduction, 7th paragraph: <snip> Were we to accept this tenet, we would require a PW to back off under congestion to consume no more bandwidth than a single TCP flow under such conditions (see [RFC5348]). However, since PWs may carry.... </snip> Consider replacing with: If we were to accept this tenet, we would require a PW to back off under congestion in order to not consume any more bandwidth than a single TCP flow under such conditions (see [RFC5348]). However, since a PW may carry 5) Introduction, 8th paragraph: <snip> The following two sections consider PWs of two types. </snip> Consider replacing with: The following two sections evaluates/analyses PWs of two types of data flows. 6) Introduction, 9th Paragraph: replace/behaviors/behavior 7) Introduction, 9th Paragraph: What is TCP-unfriendly? It would be nice to spell this out explicitly (atleast for the first reference). 8) Section 3, last paragraph: <snip> We have limited our treatment to the case of TCP traffic carried by Ethernet PWs (which are by far the most commonly deployed packet- carrying pseudowires) .... </snip> consider replacing it with: We have limited our analysis to the case of TCP traffic carried by Ethernet PWs (which by far are the most commonly deployed packet- carrying pseudowires) 9) Section 4, 1st paragraph: <snip> Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are potentially more problematic than the elastic PWs of the previous section. </snip> consider replacing with: Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are potentially more problematic than the elastic PWs mentioned in the previous section. 10) Section 4, 3rd paragraph: <snip> In the following we will focus on structure-agnostic TDM PWs [RFC4553] although similar analysis can be readily applied to structure-aware PWs (see Appendix B). </snip> Consider replacing with: In this section We will focus on structure-agnostic TDM PWs [RFC4553] although similar analysis can be readily applied to structure-aware PWs (see Appendix B). 11) Section 4, 3rd paragraph: replace/acceptable TDM Service/an acceptable TDM service.. 12) Section 4, 4th paragraph: <snip> Also note that being unable to deliver acceptable TDM service for a short amount of time is insufficient justification for shutting down a TDM PW. </snip> Consider replacing it with: Also note that being unable to deliver an acceptable TDM service for a short amount of time is an insufficient justification for shutting down a TDM PW. 13) Section 4, 5th paragraph: <snip> Due to native TDM services being designed with this low latency in mind, emulated TDM services are usually required to have similarly low end- to-end delay. </snip> Consider replacing it with: Since the native TDM services are being designed with this low latency in mind, the emulated TDM services are also required to have similarly low end- to-end latency. 14) Section 4, 8th Paragraph: <snip> Since the TDM rates are constant (T1 and E1 having payload throughputs of 1.544 Mbps and 2.048 Mbps respectively), and Structure-Agnostic TDM over packet (SAToP) can only faithfully emulate a TDM service up to a PLR of about half a percent, the T1 and E1 pseudowires occupy line segments on the graph. On the other hand, the TCP rate equation produces rate curves dependent on both one-way delay and packet loss. </snip> Consider replacing it with: Since the TDM rates are constant (T1 and E1 payload having throughputs of 1.544 Mbps and 2.048 Mbps respectively), and Structure-Agnostic TDM over packet (SAToP) can only faithfully emulate a TDM service up to a PLR of about half a percent, the T1 and E1 pseudowires occupy line segments on the graph. On the other hand, the TCP rate equation produces rate curves dependent on both one-way delay and the packet loss. 15) Section 4, 9th paragraph: <snip> Only for small packets, long one-way delays, and high packet loss ratios, do TDM PWs potentially consume more bandwidth, and even then only marginally. Further, our "apples to apples" comparison forced the TCP traffic to use packets much smaller than would be typical. </snip> Consider replacing it with: Only for small packet sizes, long one-way delays, and high packet loss ratios, the TDM PWs potentially consume more bandwidth, and even then only marginally. Furthermore, our "apples to apples" comparison forced the TCP traffic to use much smaller than the typical packet size. 16) Section 4, 12th paragraph: <snip> We can use the TCP rate equation to determine precise conditions under which a TDM PW consumes no more bandwidth than a TCP flow between the same endpoints would consume under identical conditions. </snip> Consider replacing it with: We can use the TCP rate equation to determine precise conditions under which a TDM PW consumes no more bandwidth than a TCP flow between the same endpoints under identical conditions.
- [RTG-DIR] RtgDir Review: draft-ietf-pals-congcons… Keyur Patel (keyupate)
- Re: [RTG-DIR] RtgDir Review: draft-ietf-pals-cong… Bob Briscoe