Subject: Re: [rmcat] WG last call draft-ietf-rmcat-eval-test-06

From: Colin Perkins <[email-masked]>
Date: Sun, 15 Jul 2018 15:37:12 -0400

> On 21 Jun 2018, at 14:00, Colin Perkins <[email-masked]> wrote:
> 
> This is to announce a working group last call on “Test Cases for Evaluating RMCAT Proposals” (draft-ietf-rmcat-eval-test-06). 
> 
> Please send any final comments to the working group mailing list and the authors by 20 July 2018 (the date of the RMCAT session at IETF 102). If no substantive comments are received by that time, we intend to submit this draft to the IESG for publication as an Informational RFC.

Some quick comments on this draft:

Introduction uses RFC 2119 terms, but the draft doesn’t cite RFC 2119.
Section 5.1, 3rd bullet: rather thnan “the application will attempt to” should this be “when the application tries to”?
Section 5.1: the description of oscillations in “Expected Behaviour” suggests that they will occur, rather than they might occur if there are problems with the congestion control. Maybe change “The oscillations occur when” to “Such oscillations might occur if”? 
Section 5.1: the description of what causes oscillation is also missing some mention of them being uncontrolled/excessive rate changes; as written, it could apply to any system that probes the rate, backs off, and then increases rate again later.
Section 5.7: the introductory remarks talk about “up to 4” TCP flows, but the Competing Traffic part uses 10 TCP flows.
Security considerations: maybe say that the security considerations of eval-criteria and the relevant congestion control algorithms apply?

Colin

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 16 Jul 2018 21:49:42 +0000

Thanks Colin for your review.

Please see inline below.

BR

Zahed

On 2018-07-15, 15:37, "Colin Perkins" <[email-masked]<mailto:[email-masked]>> wrote:

·         Introduction uses RFC 2119 terms, but the draft doesn’t cite RFC 2119.
Will add.
·         Section 5.1, 3rd bullet: rather thnan “the application will attempt to” should this be “when the application tries to”?
Ok.
·         Section 5.1: the description of oscillations in “Expected Behaviour” suggests that they will occur, rather than they might occur if there are problems with the congestion control. Maybe change “The oscillations occur when” to “Such oscillations might occur if”?
Makes sense to me.
·         Section 5.1: the description of what causes oscillation is also missing some mention of them being uncontrolled/excessive rate changes; as written, it could apply to any system that probes the rate, backs off, and then increases rate again later.
Not sure I understand your points here. Are you saying that the oscillation can be caused by some other events like competing flow (non- congestion controlled or congestion controlled)? That is possible. However, in that case it will be still be a case of overshooting the bitrate as the estimated link capacity will vary and the congestion control algorithm if not tracking that correctly will overshoot.
·         Section 5.7: the introductory remarks talk about “up to 4” TCP flows, but the Competing Traffic part uses 10 TCP flows.
Good catch, thanks.
·         Security considerations: maybe say that the security considerations of eval-criteria and the relevant congestion control algorithms apply?
Makes complete sense to me. Thanks again.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 20 Jul 2018 12:25:11 -0400

> On 16 Jul 2018, at 17:49, Zaheduzzaman Sarker <[email-masked]> wrote:
> 
> On 2018-07-15, 15:37, "Colin Perkins" <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  

No, I was more saying that oscillation isn’t just that the rate increases and decreases, but that it does so in an uncontrolled manner. A minor wording change: highlight the uncontrolled nature of the oscillation more.

-- 
Colin Perkins
https://csperkins.org/