Re: [rmcat] NADA Implementation in Mozilla

Sergio Mena <semena@cisco.com> Tue, 08 December 2020 16:43 UTC

Return-Path: <semena@cisco.com>
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 D30FB3A1027 for <rmcat@ietfa.amsl.com>; Tue, 8 Dec 2020 08:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 zYkjqFSmBLPp for <rmcat@ietfa.amsl.com>; Tue, 8 Dec 2020 08:43:33 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB323A1031 for <rmcat@ietf.org>; Tue, 8 Dec 2020 08:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14999; q=dns/txt; s=iport; t=1607445811; x=1608655411; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=r6e88e2wjFA1dS+RmMC7wfJ9r2otrUUtOUURnKTMDcU=; b=EcNIbhey6yoLOhYJUOVUqED7H/czLqYI5WWoLnMbBX9OIAgauMPdeBDv bU8NGTG9Ea/g+WnqV871piwe3IbCEMVPyFtiKccADxIYTUsINPqMSUQuS EYKZ++TF9qO9JX5dTquOXyrb8IlHXLnJgmRkH6UaQ2MRiFyGpo6DcaMm+ Q=;
X-IPAS-Result: A0APBgCwrM9f/xbLJq1iHQEBAQEJARIBBQUBgg+BI1KBKlcBIBIuhD6JBId3CCUDlBiIGgELAQEBDQEBJQoEAQGESgKBfyY4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVzAQMCHQYEQBIQCQIYKgICVwYBDAgBAYMiAYMGD5ELmxJ2fzODeUUBAwIBAYERg2GBPAaBOI1egUE/gREnDIFnfj6CGkMBAQIBFoRdgl8EgkUfZRkWAk8GJRUHGxg3cYxAglcDlwuRM4J+iR6SFgUHAx+DI4okFYUXj0GTeoIChUuDPpE+hFkCBAsCFYFtI4FXMxoIGxWDJU8ZDY4tF4NOhRSFRUADMAIQJQIGAQkBAQMJjQkBAQ
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.78,402,1599523200"; d="scan'208,217"; a="29307921"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Dec 2020 16:43:26 +0000
Received: from [192.168.89.140] (ams3-vpn-dhcp162.cisco.com [10.61.64.162]) (authenticated bits=0) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPSA id 0B8GhP2x024098 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2020 16:43:26 GMT
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu=40cisco.com@dmarc.ietf.org>, "rmcat@ietf.org WG" <rmcat@ietf.org>
Cc: "zhuxq@alumni.stanford.edu" <zhuxq@alumni.stanford.edu>
References: <DM5PR11MB14507C955C53880ADCB0C70FC9CD0@DM5PR11MB1450.namprd11.prod.outlook.com> <b11e706f-3ef4-f407-9022-80e097e560e5@gmail.com>
From: Sergio Mena <semena@cisco.com>
Message-ID: <81165c72-7423-fb15-c201-777436bbaf76@cisco.com>
Date: Tue, 08 Dec 2020 17:43:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b11e706f-3ef4-f407-9022-80e097e560e5@gmail.com>
Content-Type: multipart/alternative; boundary="------------17002A6B50FE6FA62BBAA3A0"
Content-Language: en-US
X-Authenticated-User: semena
X-Outbound-SMTP-Client: 10.61.64.162, ams3-vpn-dhcp162.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/yzleny5hZcdN0Q16ZbMKzqLmc6I>
Subject: Re: [rmcat] NADA Implementation in Mozilla
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: Tue, 08 Dec 2020 16:43:36 -0000

Hi Sergio,

Thanks a lot for your interest.

It’s a great idea to be able to compare common statistics across 
different bandwidth estimation algorithms.  In fact, in our code we had 
to modify the logging process in the default algorithm to support that, 
but the plotting part is less sophisticated than what you've been 
sharing :-)

Would you be willing to hook (and modify as needed) the logging 
mechanism in our Firefox branch to your repo? We can explain where all 
logs are located.

In one of our algorithm's modes -- NADA-OWD -- we are indeed still using 
transport-wide cc feedback. We had also implemented the new CCFB format 
(in past hackathons) in another branch, but we never came round to 
merging both branches.

About how we carried out the testing scenarios, they were mostly manual, 
i.e., having actual calls between two of us, then collecting and 
processing the logs from the sender. For more details on this, please 
check our update at IETF-106 
(https://www.ietf.org/proceedings/106/slides/slides-106-rmcat-nada-update-01). 
If someone could write scripts to automate this, that would be of course 
awesome!

Thanks,

Xiaoqing & Sergio


On 08/12/2020 17:03, Sergio Garcia Murillo wrote:
> Hi Xiaoqing and Sergio,
>
> Great to see you are still working on it.
>
> I proposed a while back the use of a common logging format for being 
> able to create tools for measuring the performance and comparing the 
> behavior of the different bwe algorithms:
>
> https://github.com/medooze/bwe-stats-viewer
>
> Would you consider adding support to it on your source code? If you 
> are still using the transport wide cc feedback messages the 
> information dumped would be quite straight forward.
>
> Also, it would be interesting knowing how did you perform the testing 
> scenarios and if we could create a set of scripts to replicate them 
> easily, what do you think?
>
> Best regards
> Sergio
>
> On 08/12/2020 16:24, Xiaoqing Zhu (xiaoqzhu) wrote:
>>
>> Hi all,
>>
>> A while back we presented some initial evaluation results of the NADA 
>> implementation in the open-source Mozilla browser under various 
>> real-world settings at IETF-106 
>> <https://www.ietf.org/proceedings/106/slides/slides-106-rmcat-nada-update-01>. 
>> After further tinkering, we are happy to share a cleaned-up version 
>> of our implementation rebased to a recent version of the Mozilla code:
>>
>> https://github.com/sergio-mena/gecko-dev/tree/nada
>>
>> It supports the use of either one-way-delay (OWD) or round-trip-time 
>> (RTT) as the congestion signal for NADA, and includes all algorithmic 
>> features for congestion control as described in the corresponding RFC 
>> <https://tools.ietf.org/html/rfc8698>. Some illustrative results from 
>> running the modified Firefox Nightly browser using the default 
>> algorithm, or OWD/RTT-based NADA can be found here 
>> <https://www.dropbox.com/s/g3idujywj573gax/2020-12-07-nada-eval-in-mozilla.pdf?dl=0>. 
>>
>>
>> For your convenience, this branch also contains a folder. It contains 
>> brief instructions and a utility python script for post-processing 
>> the logsand plotting the graphs (as shown in the link above):
>>
>> https://github.com/sergio-mena/gecko-dev/tree/nada/nada_eval
>>
>> Since this effort has spanned over multiple years, we’ve rebased our 
>> code twice along the way to catch up with major changes in the 
>> Mozilla base code.Those rebases required us to squash our commit 
>> history. So we are also sharing two branches below for archiving the 
>> original commit history:
>>
>> https://github.com/sergio-mena/gecko-dev/tree/nada_rebase_0
>>
>> https://github.com/sergio-mena/gecko-dev/tree/nada_rebase_1
>>
>> Please feel free to check out the above. Let us know if you are 
>> interested inintegrating it in your WebRTC-based app ortesting it out 
>> in the real-world – always happy to jump on a call for that😊
>>
>> Thanks,
>>
>> Sergio and Xiaoqing
>>
>
> -->