From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from roobidoo.pudai.com (unknown [216.14.118.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1E2113B29E for ; Tue, 14 Apr 2020 10:15:45 -0400 (EDT) Received: from [71.219.88.243] (port=6352 helo=[10.168.3.100]) by roobidoo.pudai.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jOMLo-0006Xi-PP; Tue, 14 Apr 2020 09:15:45 -0500 Cc: tim@timhiggins.com To: make-wifi-fast@lists.bufferbloat.net References:

From: Tim Higgins Message-ID: Date: Tue, 14 Apr 2020 10:15:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - roobidoo.pudai.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - timhiggins.com X-Get-Message-Sender-Via: roobidoo.pudai.com: authenticated_id: tim@timhiggins.com X-Authenticated-Sender: roobidoo.pudai.com: tim@timhiggins.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Tue, 14 Apr 2020 10:31:20 -0400 Subject: Re: [Make-wifi-fast] some review needed X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 14:15:45 -0000

On 4/13/2020 7:53 PM, Dave Taht wrote:

On Mon, Apr 13, 2020 at 8:00 AM Tim Higgins <tim@timhiggins.com> wrote:



On 4/12/2020 1:17 PM, Dave Taht wrote:

https://tools.ietf.org/html/draft-ietf-rmcat-wireless-tests-11

I'm more interested in testing with actual APs and STAs than simulators.

 Me too! Also, trying to figure out where a standardized test and
testing environment veers from reality too much.

What are folks using to generate RTP video traffic for testing?

I've only begun to research this subject again. Back in the good ole
days (2002!)
I worked on asterisk and had a ton of rtp tools. Today, all the rtp
information is
encrypted so you can't get at it easily unless you instrument your own server.

There's been some really good webrtc work I've begun to look over -
everything from
janus from meetecho, to jitsi, to BBB, to something juliusz just
whipped up over the weekend.

and I had at one point (2014?) worked on google congestion control for
rmcat and kind of understood how both NADA and scream were supposed to
work.

The spec seems light on expected results for Wi-Fi cases.

3.2.4, bullet 1: "The end-to-end delay and packet loss ratio experienced by each flow should be within an acceptable range for real-time multimedia applications". And what would those be?
It also specs no video stats, like dropped frames

I can't say it's that much of an rfc either. I vastly prefer ieee
802.11 specs to ietf's, and
in part, why flent exists, was to actually be able to look hard at
this kind of stuff.

But the place for feedback is on the relevant ietf list, it's just
that sometimes easier to get
the attention of experts, here....

Thanks, Dave. If you come across any good real-world testing techniques / tools, please post.
I poked at VLC a bit the other day. It provides video stats (dropped frames and more), but last time I tried retrieving stats via the API, it didn't work. That was on Windows, however. Haven't tried it with Linux.