Early Review of draft-ietf-pals-congcons-01
review-ietf-pals-congcons-01-rtgdir-early-patel-2016-01-15-00

Request Review of draft-ietf-pals-congcons
Requested rev. no specific revision (document currently at 02)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-01-15
Requested 2015-11-02
Authors Yaakov Stein, David Black, Bob Briscoe
Draft last updated 2016-01-15
Completed reviews Genart Last Call review of -01 by Ron Bonica (diff)
Secdir Last Call review of -01 by Hilarie Orman (diff)
Opsdir Last Call review of -01 by Menachem Dodge (diff)
Rtgdir Early review of -01 by Keyur Patel (diff)
Assignment Reviewer Keyur Patel
State Completed
Review review-ietf-pals-congcons-01-rtgdir-early-patel-2016-01-15
Reviewed rev. 01 (document currently at 02)
Review result Has Nits
Review completed: 2016-01-15

Review
review-ietf-pals-congcons-01-rtgdir-early-patel-2016-01-15






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.