Subject: [RTG-DIR] RtgDir Review: draft-ietf-pals-congcons-01

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 8 Dec 2015 03:08:39 +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.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 9 Dec 2015 16:24:54 +0000

Keyur,

Thx for confirming you have no technical issues, and for your comments 
on readability.
Responses inline...

On 08/12/15 03:08, Keyur Patel (keyupate) wrote:
> 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.
>
I'm afraid this doc is the result of years of horse-trading over the 
minutiae of the language. So it is best that we resist changes unless 
absolutely necessary. Nonetheless, where I resist some of your specific 
suggestions below, it is irrespective of the likelihood of opening up 
more years of argument - it is because I genuinely prefer the original - 
and I have explained why where necessary.

I should add that most of the original is Yaakov's text, so I cannot be 
accused of being precious with my own words here.

More generally, I prefer not to change a document where the improvement 
is marginal and the original was OK, otherwise it increases the chance 
of errors creeping in (it also consumes time unnecessarily).

> PWs do not consume any more network capacity than a TCP flow.
IMO, the original (Yaakov's text) is neither incorrect nor hard to 
comprehend or scan.
>    than this bound, and is typically much lower.
The "and" couples two adjectives after the verb "to be", so another verb 
"to be" isn't needed. However, the comma should be removed (and I know 
the RFC Editor deals with commas very effectively).

Perhaps better would have been:
TDM service is never significantly greater and typically much lower than 
this bound.
> with an acceptable TDM service criteria.
"criteria" is (deliberately) the plural.
>    such conditions (see [RFC5348]). However, since a PW may carry
OK, Yaakov's style is perhaps a little old-fashioned, but the 
subjunctive mood used here is perfectly comprehensible (and correct).
I don't see the need to make 'PWs' singular in the last sentence either.
> The following two sections evaluates/analyses PWs of two types of data 
[Subject-verb inconsistency in the suggested replacement.]
"consider" seems fine to me anyway.
> replace/behaviors/behavior
We intended "the combined behaviours" to mean "the (plural) behaviours 
before combining", not "the (singular) behaviour after combining".
> (atleast for the first reference).
OK. That's reasonable - at least we should spell out the definition of 
TCP Friendly early in the doc, rather than just by reference. I think 
TCP-unfriendly would then become obvious.

I suggest we alter the sentence in the introduction (already quoted 
above) that refers to RFC5348, as follows:

OLD:
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]).
NEW:
Were we to accept this tenet, we would require a PW to back off under
congestion so as to consume roughly similar bandwidth to a single TCP 
flow under
similar conditions (this is the definition of TCP Friendliness [RFC5348]).

>    Ethernet PWs (which by far are the most commonly deployed packet-
OK, but 'treatment' is no worse IMO.
>    potentially more problematic than the elastic PWs mentioned in the 
Elastic PWs were the core subject of the previous section, so 
"mentioned" is rather too casual. I think the original was fine.
>    structure-aware PWs (see Appendix B).
We did actually mean "the following", not "this section", because the 
earlier text in the section is more general.

I notice the capitalisation of "We" in the middle of the sentence. 
However, we are neither royalty or deity (well, only One of us is ;)
> replace/acceptable TDM Service/an acceptable TDM service..
I prefer it without "an".
>    time is an insufficient justification for shutting down a TDM PW.
Again, I prefer it without "an".
>    emulated TDM services are also required to have similarly low end-

Drawing from both, I prefer:
Since TDM services are designed with this low latency in mind,

    emulated TDM services are usually required to have similar low end-

    to-end delay.

>    dependent on both one-way delay and the packet loss.
I prefer the original in the case of both edits:
* A payload doesn't have a throughput, but a service does have a payload 
throughput.
* One would only use 'the' with packet loss if one was referring to a 
particular packet loss figure, not packet loss as a parameter.
>    use much smaller than the typical packet size.
I don't prefer either suggested replacement.
"Only for small packets ... do PWs consume" was fine for me. But if you 
prefer I would be happy with:
For small packets,long one-way delays, and high packet loss ratios, TDM 
PWs potentially consume more bandwidth, but only marginally.
>    between the same endpoints under identical conditions.
That's better.

Thank you again,

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/