Subject: [tcpm] Review of draft-ietf-tcpm-proportional-rate-reduction-01

From: Michael Welzl <[email-masked]>
Date: Tue, 13 Mar 2012 15:11:29 +0100

Hi all,

I just read this draft, and don't see any problems with it. I don't have 
the same insight into the Linux implementation details as Mirja, and so 
I might have missed some issues - like the ones that Mirja pointed out, 
which I found to be very sound criticism, but which was in my opinion 
also amply answered by Matt.

So, as a reader who was convinced by the document that this is a good 
idea, what's left for me to comment on is nits, and nothing but nits.

They're below.

Cheers,
Michael

-----

abstract: remove first "that" in "that such that the number of ACKs"
intro: par 2: "It's stated goal" => "Its stated goal"
further down: "...expected behavior would be _to_ wait for half _a_ 
window of ACKs to pass..."
par 3: Rate-having => Rate-halving
par 4: remove comma before ssthresh
next sentence: "appropriate for _the_ target window chosen..."

section 3, algorithm description: why i think it's understandable what's 
meant with it, the function "delta" isn't defined or described anywhere, 
and this should be done.

section 3.1: "In all cases we assume bulk data, ..." => I guess what you 
mean is that you assume a greedy sender transmitting bulk data, and I 
would suggest that phrase instead.

par underneath the first example graphs: "Note that all three algorithms 
send _the_ same total amount of data"

par no. 3 below the next example graphs: "PRR_CRB implements _a_ 
conservative reduction bound"
next par: "remember that this _is_ actually less aggressive..."

about the graphs, what's the intuition behind the use of "f" and "d" for 
RB? This would be easier to read if one would understand the logic 
behind this choice of letters for the flag (sorry, maybe this is obvious 
and I just missed it).

appendix a: par 4 (the thought experiment): "I mean when a packet 
is..."  => I think this should be "we mean ..."

next par: "Any more aggressive algorithm which sends additional data 
_can_ cause a queue overflow and loss."  .... I think this is more precise.

next par: remove "of" in "includes appropriately sharing of the network"