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

Colin Perkins <csp@csperkins.org> Fri, 20 July 2018 16:25 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3673A131138; Fri, 20 Jul 2018 09:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2fQXNmA_qFe; Fri, 20 Jul 2018 09:25:22 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986D013111F; Fri, 20 Jul 2018 09:25:21 -0700 (PDT)
Received: from [2001:67c:370:128:f82d:f560:30d4:2ec3] (port=60938) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <csp@csperkins.org>) id 1fgYDT-0001Jf-SF; Fri, 20 Jul 2018 17:25:20 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <AA599C75-EA6D-4820-A992-1642C9BAEC64@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C66CAD7C-AC1D-4199-AE6C-CD51E5B401CB"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 20 Jul 2018 12:25:11 -0400
In-Reply-To: <506B7742-A2F1-496D-BDEF-A019102642F2@ericsson.com>
Cc: "rmcat@ietf.org WG" <rmcat@ietf.org>, "draft-ietf-rmcat-eval-test@ietf.org" <draft-ietf-rmcat-eval-test@ietf.org>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
References: <B298CB34-37DB-45D2-A4F6-D52CA1E8B9BA@csperkins.org> <F819B214-67AE-4E8B-AF05-A81290D8EB5F@csperkins.org> <506B7742-A2F1-496D-BDEF-A019102642F2@ericsson.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/YmoeLGqQEqRTcJEaINine5AyjbQ>
Subject: Re: [rmcat] WG last call draft-ietf-rmcat-eval-test-06
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2018 16:25:24 -0000

> On 16 Jul 2018, at 17:49, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
> 
> Thanks Colin for your review.
>  
> Please see inline below.
>  
> BR
>  
> Zahed
>  
> On 2018-07-15, 15:37, "Colin Perkins" <csp@csperkins.org <mailto:csp@csperkins.org>> wrote:
>  
>  
> Some quick comments on this draft:
>  
> ·         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.  

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.

> ·         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.



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