[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.