« Return to Thread: Review of draft-ietf-tcpm-proportional-rate-reduction-01

Review of draft-ietf-tcpm-proportional-rate-reduction-01

by Michael Welzl-2 :: Rate this Message:

| View in Thread

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"


_______________________________________________
tcpm mailing list
tcpm@...
https://www.ietf.org/mailman/listinfo/tcpm

 « Return to Thread: Review of draft-ietf-tcpm-proportional-rate-reduction-01