Last Call Review of draft-ietf-tcpm-initcwnd-
review-ietf-tcpm-initcwnd-genart-lc-krishnan-2012-12-11-00

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see


http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-initcwnd-06
Reviewer: Suresh Krishnan
Review Date: 2012/12/11
IESG Telechat date: 2012/12/13

Summary: This document is well written and is ready for publication as
an Experimental RFC. I do have some minor comments you may wish to address.

Minor
=====

* Introduction

Intuitively I feel that an increased value of initcwnd is useful because
of the sizeable increase in the BDP (mainly due to the increase in
bandwidth). Is this correct? If so, it would be worth mentioning in the
introduction.

* Section 2

I am not clear on why this document has to explicitly *allow* existing
implementations to have smaller initcwnd . Isn't this automatically the
case?

"This increase is optional: a TCP MAY start with an initial window that
is smaller than 10 segments."

* Section 3

Not sure how the authors arrived at the following conclusion.

"A larger initial window will incentivize applications to use fewer
concurrent TCP connections."

Since the application (e.g. browser) developer and the TCP stack
developer are usually different, it is not clear why the application
developer would stop using multiple concurrent connections. Can you
clarify this a bit.

* Section 8

Isn't this only an issue for users on slow links which *also* have low RTTs?

Nits
=====

* RFC6077 is listed in the references but not used in the document. Remove?

* Idnits complained about a line longer than 72 chars. I located this
line to be the title line of Section 6 "Disadvantages of...Connection"

Thanks
Suresh