Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 24 March 2019 13:51 UTC

Return-Path: <kaduk@mit.edu>
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 11F48130DEA; Sun, 24 Mar 2019 06:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8AB6Ex4CF7Za; Sun, 24 Mar 2019 06:51:46 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 77765127AC2; Sun, 24 Mar 2019 06:51:46 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2ODpYwx014258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Mar 2019 09:51:36 -0400
Date: Sun, 24 Mar 2019 08:51:34 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Cc: Benjamin Kaduk via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, "rmcat-chairs@ietf.org" <rmcat-chairs@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, Colin Perkins <csp@csperkins.org>, "draft-ietf-rmcat-eval-test@ietf.org" <draft-ietf-rmcat-eval-test@ietf.org>
Message-ID: <20190324135134.GM77890@kduck.mit.edu>
References: <155197033601.24667.6429871717336324511.idtracker@ietfa.amsl.com> <3C53B15F-9C66-4C64-8C15-A643EADE6B54@ericsson.com> <20190323134227.GZ88959@kduck.mit.edu> <0E1DBC98-6486-483C-8CEA-893BAC4F930E@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0E1DBC98-6486-483C-8CEA-893BAC4F930E@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/lUXGf6z0BzhWkgzzxPg8J3AnYpA>
Subject: Re: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-eval-test-09: (with COMMENT)
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 24 Mar 2019 13:51:49 -0000

On Sun, Mar 24, 2019 at 09:33:33AM +0000, Zaheduzzaman Sarker wrote:
> 
> On 2019-03-23, 14:42, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     On Thu, Mar 21, 2019 at 01:41:28PM +0000, Zaheduzzaman Sarker wrote:
>     > Hi Benjamin,
>     > 
>     > Thanks for the comments. Please see inline below with [ZS] prefix.
>     > 
>     > BR
>     > Zahed
>     > 
>     > On 2019-03-07, 15:52, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote:
>     > 
>     > 
>     > 
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >     
>     >     We don't really explain the usage of the "variation pattern index" that
>     >     I can see.
>     > 
>     > [ZS] right, that column could be removed. I think it is still there for potential reference in the discussion.
>     >     
>     >     Section 3
>     >     
>     >              +  Bottleneck-link capacity: defines minimum capacity of the
>     >                 end-to-end path
>     >     
>     >     I'm not sure I'd describe this as the "minimum capacity of the
>     >     end-to-end path", since attempts to use anything larger than this value
>     >     will pile up at the bottleneck.
>     > 
>     > [ZS] hmm, I guess that is why that link will act as bottleneck link for a respective testcase. If the flows remain below that capacity it should not experience queuing and as you said anything above that capacity will observe queuing. The job of the congestion control algorithm will be to avoid queuing.
>     
>     I think I was expecting "maximum capacity" to be more appropriate than
>     "minimum capacity".  Perhaps I'm confused about what is intended here.
> 
> (disclaimer. this has been done in the long past and I hope my memory is supporting me on explaining it ☺)
> 
> The thinking was that the bottleneck-link capacity was not equals to the maximum link capacity. That means if the maximum link capacity is X then the bottleneck-link capacity is Y , where Y<X and (X-Y) capacity is used by other traffic traversing that link. Hence, in the test if a link is assumed to be bottleneck then the "the bottleneck-link capacity" is the minimum capacity available to the media flow traversing that path. 

Ah, that makes sense.  Maybe "minimum guaranteed capacity" or similar would
convey the intent better.

>   
>     >     Section 5.6, 5.7
>     >     
>     >     Do we want anyone to consider testing with alternative TCP congestion
>     >     control algorithms?
>     > 
>     > [ZS]The text should be read as the minimum one need to do and should encourage other to try with more alternatives. Will add the encouragement text (there is already one for multiple media sources).
>     >     
>     >     Section 6.1
>     >     
>     >     If you're not going to reference what scheme is used for implementing
>     >     priority, say how these priority values are interpreted.
>     > 
>     > [ZS] not sure I understood the comments here. I don’t think we have any recommendation of which priority schemes one need to use. The testers are free to use any priority scheme and the share of the available bandwidth must reflect the priority imposed on flows. What we can ask is to describe the scheme used in the test so that results can be interpreted clearly. Like a particular SCREAM (https://tools.ietf.org/html/rfc8298#section-4.1.2.8) implementation uses a credit based scheme, then presenting results that scheme needs to be described by the proponents. Will this work?
>     
>     The example has priority values of 1 and 2 -- are higher numbers more
>     preferred or lower numbers more preferred?
> 
> Ok Understood, I will explain that in the text. What about the following text?
> 
>    "In this test case media flows will have different priority levels imposed by the application.
>    This will be an extension of Section 5.4 where the same test will be
>    run with different priority levels imposed on each of the media
>    flows.  For example, the first flow (S1) is assigned a priority of 2
>    whereas the remaining two flows (S2 and S3) are assigned a priority
>    of 1.  Here, the higher priority number indicates higher application level priority for bandwidth distribution. The candidate algorithm must reflect the relative priorities
>    assigned to each media flow.  In this case, the first flow (S1) must
>    arrive at a steady-state rate approximately twice of that of the
>    other two flows (S2 and S3).
> 
>     
>     
> 

Thanks!

-Benjamin