Re: [rmcat] Proposed text on fairness for draft-ietf-rmcat-eval-criteria

Colin Perkins <> Thu, 29 March 2018 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A30112DA1C for <>; Thu, 29 Mar 2018 09:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hR2aBJKxPN9b for <>; Thu, 29 Mar 2018 09:34:37 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 2AF6E12420B for <>; Thu, 29 Mar 2018 09:34:37 -0700 (PDT)
Received: from [] (port=63679 by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1f1aVU-0004ha-Vh; Thu, 29 Mar 2018 17:34:35 +0100
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1314C84F-02FA-4B42-A526-612CA7C99B52"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 29 Mar 2018 17:34:29 +0100
In-Reply-To: <>
Cc: "" <>
To: =?utf-8?B?SsO2cmcgT3R0?= <>, "Xiaoqing Zhu (xiaoqzhu)" <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 14
Archived-At: <>
Subject: Re: [rmcat] Proposed text on fairness for draft-ietf-rmcat-eval-criteria
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2018 16:34:40 -0000


Thanks, Xiaoqing!  Along with the minutes, summarising the other decisions ( <>), it should now be possible to revise this draft. Jörg, do you have everything you need?


> On 26 Mar 2018, at 16:35, Xiaoqing Zhu (xiaoqzhu) <>; wrote:
> Hi,
> This is to follow up on a discussion we had at the recent IETF-101 RMCAT WG, regarding how to address the notion of "fairness" in the eval-criteria draft.  
> Brief recap for folks not at the meeting: There was consensus to remove the current open issue (#1) on using Jain's Fairness Index (JFI) as fairness metric since nobody used it in their tests. On the other hand, there were some debates/discussions regarding whether & how to address the issue of fairness in the eval-criteria draft.  I signed up to provide some updated text to cover this topic. 
> As promised, please find below my proposed revision for #7 in Sec. 3, Metrics: 
> -------------------------------------
> 7. Self-Fairness and Fairness with respect to cross traffic:  Experiments testing a given RMCAT proposal must report on relative ratios of the average throughput (measured at coarser time intervals) obtained by each RMCAT stream. In the presence of background cross-traffic such as TCP, the report must also include the relative ratio between average throughput of RMCAT streams and cross-traffic streams. 
> During static periods of a test (i.e., when bottleneck bandwidth is constant and no arrival/departure of streams),  these report on relative ratios serve as an indicator of how fair the RMCAT streams share bandwidth amongst themselves and against cross-traffic streams. The throughput measurement interval can be set at a few values --- for example, at 1s, 5s, and 20s --- so as to measure fairness across different time scales. 
> As a general guideline, the relative ratio between RMCAT flows with the same priority level and similar path RTT should be bounded between (0.333 and 3.) 
> --------------------------------------
> The last part of this write-up spells a rough guide-rail on fairness. I've removed the other two criteria in the original text for the following reasons: 
> * On 1. Does not trigger the circuit breaker:  this is already stated in the intro and should always apply; 
> * On 3. RTT should not grow by a factor of 3 for the existing flows when a new flow is added: I understand this to be more a measure of low-latency instead of fairness.   Also I am not aware that any eval tests have used this in the past.  Am I missing something here? 
> Additional feedback and input is welcome.  I'll leave it to the authors on how they want to incorporate this. 
> Thanks,
> Xiaoqing

Colin Perkins