Costin, The proposed -06 version sufficiently clarifies my one open issue. I agree that the NSDI paper is an important citation and did not intend to suggest that it be removed. In addition, your decision to not cite RFC 3124 is ok with me. Thank you for responding to the review. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Costin Raiciu [mailto:c.raiciu@xxxxxxxxxxxx] > Sent: Tuesday, July 19, 2011 12:35 PM > To: Black, David > Cc: tsv-dir; tsv-area; ietf; m.handley; d.wischik; multipathtcp > Subject: Re: tsv-dir review of draft-ietf-mptcp-congestion-05 > > Hi David, > > Thank you for your review. > > > Major: > > > > I have one open issue - the first two goals (in the Introduction) are to have multipath > > TCP connections behave somewhat like single-path connections in terms of effects on > > (fairness to) other traffic. The algorithm specified accomplishes this solely by > > coupling the additive increase functionality across the flows, but allowing each flow > > to react to drops and congestion separately (no decrease coupling). The draft does > > not explain why increase coupling alone is sufficient to achieve these goals or what > > compromise to the goals results from only coupling increases. > > Our proposal fully achieves goals 1 and 2 - fairness to single path tcp and improve throughput. It > does not fully achieve goal three - balancing congestion; fully achieving goal 3 is very difficult, > and an explanation is attempted in section 5; a reference is given to the NSDI paper for further info. > > > Section 5 is a good start on this discussion, but it's not clear about what compromises > > to the goals results from increase coupling only. Section 5 criticizes an alternative > > that couples both increases and decreases for failing to achieve Goal 1, but doesn't > > say what this approach achieves. At most a few additional sentences in Section 5 should > > suffice to address this concern, and Section 2 should be edited to align with the > > changes to Section 5. > > We have updated section 5 to make these points clear - they weren't clear enough before. > > > Minor: > > > > While the [NSDI] paper is a fine place to reference work published in conferences > > and/or journals, RFC 3124 on the Congestion Manager is related IETF work and should > > be cited here as an Informative Reference. > > The congestion manager is indeed related work and should be cited in a research paper, but does not > help understanding the congestion controller presented in this draft. We chose not to cite it > explicitly. > > We chose to cite the NSDI paper because it describes in detail the design choices that shaped the > algorithm, and it will help an interested reader understand more about the algorithm. > The discussion section is itself a short high level summary of those decisions. > > We attach the new version of this draft to this email (we cannot post a new version online of the > draft because the IETF submission cutoff date has passed). Could you please check the draft and see if > the issues you raised have been clarified? > > We will post the draft as soon as submissions reopen after the IETF > > Thanks, > Costin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf