Re: [rmcat] Hackathon: RMCAT (and CCFB) in Jitsi (fwd)

Jonathan Lennox <jonathan.lennox@8x8.com> Fri, 01 November 2019 20:33 UTC

Return-Path: <jonathan.lennox@8x8.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 257CA120013 for <rmcat@ietfa.amsl.com>; Fri, 1 Nov 2019 13:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.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 vqsNWc9qzjQu for <rmcat@ietfa.amsl.com>; Fri, 1 Nov 2019 13:33:38 -0700 (PDT)
Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7225812000F for <rmcat@ietf.org>; Fri, 1 Nov 2019 13:32:47 -0700 (PDT)
Received: by mail-qt1-x841.google.com with SMTP id x21so14574585qto.12 for <rmcat@ietf.org>; Fri, 01 Nov 2019 13:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=o/iceB2Yk4eUFR0bUUqcUhwu3ZffGHmgnMNoodb/604=; b=DQQrhAKhV51DDJG1SPXciP52Ncz5mOkQDlQQ85gUTVU7dOYkdBxXzEywhgw5SU5Se+ LPNiflphK6nXnwkVboxIWoFJwKLn5eEz4a6F5O9axg194b2VBRTlxEBY7XaJqhA6nFZK gB3czggCFei/8wGktqrV+hXyJCCm0piucS2y4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=o/iceB2Yk4eUFR0bUUqcUhwu3ZffGHmgnMNoodb/604=; b=t02IzgqT4Le6BrGWGjIHPFxlO3PUaMcnfFTPTMmepp2pL/5tfrkwTuDMCmedcV/W8R u4MK0hlFjw4ugbdIGndEpvAgK+0SHSBxgTEZAy/yCU3yJ3SPznE5ey6vDim1M61+a316 nbSdGMr9I3BBL9d0lg6KzOcnpYxV8EvY3bNJ5m7oU4gvf4/Vev5WMvQAShEINldn+7LZ +AksyILliZTu8GPF881Vgj1Y6f5YkqZoJqKX9efWPPl41BKxOcqqeYwKJbdIOgerZcDq 1u5bD22KchzD6k+e3sr9cUYNM2TYuJP3OHR3TjKLz5OlByyRNbGir4u5qmykkoeuGtBS vc7Q==
X-Gm-Message-State: APjAAAXl83DC7orQ8kxSEAUVKcTeaISy7+qoMX0AsMDGaApLlUn8eU9q yZ9dpvB3u4TcmiPLAAoSfKMPW/UPaQM=
X-Google-Smtp-Source: APXvYqwh9BmyrKFOQKPcQkXEEt4soVYo1Li2ce8j+WKLGKPTzbkID4FA/qDZtjvAuYCNb6oO7S/OWw==
X-Received: by 2002:a0c:94fb:: with SMTP id k56mr12200254qvk.127.1572640366143; Fri, 01 Nov 2019 13:32:46 -0700 (PDT)
Received: from [10.195.20.11] (static-68-132-136-52.nycmny.fios.verizon.net. [68.132.136.52]) by smtp.gmail.com with ESMTPSA id h2sm4357738qkl.75.2019.11.01.13.32.45 for <rmcat@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 13:32:45 -0700 (PDT)
From: Jonathan Lennox <jonathan.lennox@8x8.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_805666BB-948B-4288-ADF2-22E08B46CA2E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 1 Nov 2019 16:32:45 -0400
References: <23983.5180.844349.967498@paris.clic.cs.columbia.edu>
To: rmcat@ietf.org
In-Reply-To: <23983.5180.844349.967498@paris.clic.cs.columbia.edu>
Message-Id: <55A979B1-88AC-4556-8888-7E2680A64500@8x8.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/3jV8EQRPC5lmqWGCeLzWSmCxvlc>
Subject: Re: [rmcat] Hackathon: RMCAT (and CCFB) in Jitsi (fwd)
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: Fri, 01 Nov 2019 20:33:40 -0000


> On Oct 22, 2019, at 10:37 AM,Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> Hi Jonathan,
> 
> My C++ interface is slightly different, although I have it implemented for google's transport wide feedback message:
> https://github.com/medooze/media-server/blob/master/include/SendSideBandwidthEstimation.h <https://github.com/medooze/media-server/blob/master/include/SendSideBandwidthEstimation.h>
> 
> Main difference is that I have split your packet arrival processing in two calls, one for notifying when one rtp packet is sent and one to notify when a feedback packet is received with a map of the received stats. If you prefer to have an individual call per feedbacked rtp packet, I think it would be important to notify when the last packet of the feedback has been received as for example I do the final bwe calculations there.

I had a single call in hopes of using the same algorithm interface to implement REMB (receiver-side) feedback with the abs-send-time extension; in that case you only have information at the time of packet receipt, not packet transmission, and each piece of “feedback” information comes in separately.

I agree that some ability to tell the algorithm which feedback came in at once would be useful.

> I miss also to be able to control the congestion control part of the SFU, in my implementation which is based on BBR, I rely heavily on continuously sending RTX as probing bitrate as described on Varum's FRACTAL algorithm. 

How tightly coupled do you think probing needs to be with the algorithm?  I’ve generally considered probing to be a separable piece — the prober’s responsibility is to consume the output of the bwe algorithm, and to generate traffic when appropriate (i.e. when the overall application has some larger discrete quantum of bandwidth that it wants to be able to start sending).

> The main problem when implementing the bwe was about how to test it and troubleshoot it. I tried to use the ns3-rmcat repo, but the differences in behavior with my sfu are so huge that it was not practical. I tried also to use the ns3 direct code execution and reuse the ns3-rmcat scenarios, but the ns3-dce does not work at all with latest linux versions. 
> 
> I ended up testing with custom linux tc scripts, but I am not really sure that the ones I tested are meaningful or how to map them to the rmcat test scenarios. If we could create a common set of tc script modeling the rmcat test cases I think that would be very useful for all of us.

Yes — if there are transport / Linux people who are knowledgable about tc and its parameters, it would be very helpful to have some guidance about which settings best reflect the rmcat test cases in particular, and realistic router and network scenarios in general.

One tool I’ve found is tcconfig — https://github.com/thombashi/tcconfig <https://github.com/thombashi/tcconfig> — which is a front-end to tc with parameters comprehensible by mere mortals who aren’t deeply knowledgeable about Linux kernel queueing.  However, I still don’t know precisely how it should be mapped to rmcat tests.

> I won't be attending the Hackaton in Singapore, but Cosmo's Kite team will, so we could integrate those tc scripts into Kite's network instrumentation tests and have a run test with them for the Hackaton.

That sounds good, I’ll look for them.

> Last topic is troubleshooting, I have created a tool for viewing bwe stats dumps from my SFU: 
> https://github.com/medooze/bwe-stats-viewer <https://github.com/medooze/bwe-stats-viewer>
> 
> If we can agree on a common format for the logs, we could enhance it and use it for troubleshooting and comparing behaviors.

That does look useful.  Do you have documentation for the log format you’re using?

> Best regards
> Sergio
> On 21/10/2019 20:34, Jonathan Lennox wrote:
>> Hi, all —
>> 
>> As I’m now at 8x8 working on the open-source Jitsi project (https://jitsi.org/ <https://jitsi.org/>), I’ve been working on modifying the Jitsi Videobridge to make it easy to adapt it for alternate bandwidth estimation algorithms.  I hope this could be a good environment to make running-code RMCAT testing and comparisons possible.
>> 
>> The API I’ve created is hopefully clean and simple, modeled on the one in the ns3-rmcat repo with some changes.  The code is written in Kotlin, so Kotlin and Java should work with it immediately, and native (C or C++) should be able to work through JNI.
>> 
>> The interface can be seen at https://github.com/jitsi/jitsi-media-transform/blob/master/src/main/kotlin/org/jitsi/nlj/rtp/bandwidthestimation/BandwidthEstimator.kt <https://github.com/jitsi/jitsi-media-transform/blob/master/src/main/kotlin/org/jitsi/nlj/rtp/bandwidthestimation/BandwidthEstimator.kt>.
>> 
>> I welcome any comments, and I’d love it if people could give it a try — I’d be able to help out to let people get a Jitsi meet environment working.
>> 
>> Furthermore, I’ll be attending the Hackathon in Singapore.  Is anyone else planning to attend, in person or remotely, to work on RMCAT or CCFB work?  I’d love to work with folks to try to get interop or testing.
>> 
>> — 
>> Jonathan Lennox
>> jonathan.lennox@8x8.com <mailto:jonathan.lennox@8x8.com>
>> 
> 
> 
> 
> 
> -- 
> Jonathan Lennox
> lennox@cs.columbia.edu