[tsvwg] rrul yet?
Dave Taht <firstname.lastname@example.org> Sun, 09 February 2020 03:34 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1437912008B for <email@example.com>; Sat, 8 Feb 2020 19:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M6sRK-JtnN3 for <firstname.lastname@example.org>; Sat, 8 Feb 2020 19:34:10 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00:e000:2d4:f00f:f00f:b33b:b33b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B89D120077 for <email@example.com>; Sat, 8 Feb 2020 19:34:10 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2601:646:8301:676f:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 6BEE22286B for <firstname.lastname@example.org>; Sun, 9 Feb 2020 03:34:06 +0000 (UTC)
From: Dave Taht <email@example.com>
Date: Sat, 08 Feb 2020 19:34:04 -0800
Subject: [tsvwg] rrul yet?
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Sun, 09 Feb 2020 03:34:12 -0000
I do kind of miss the days when we were all in this bloat together, and a variety of metrics mattered. So far I've been following along only a bit, I've just gone through the simplistic 2 or so flow ones again just now. Is there any chance these benchmarks, using L4S (or SCE) style traffic (dctcp and bbrv2), can be repeated? Specifically fig 14-16, 24, and 28 tracking metrics like loss also? https://www-res.cablelabs.com/wp-content/uploads/2019/02/28094118/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf There were a few things wrong with this benchmark string as turned out afterwards - the projection for the growth of a webpage was way off, quic didn't exist, pacing didn't exist - but they did stress out more than two flows at a time - and merely seeing a shot through that code with these new variables applied vs as things existed then would be of comfort. Secondly... Has anyone done a rrul style benchmark yet? (flooding the uplink and downlink with mixed traffic, especially one with asymmetric bandwidth) Probably my greatest concern with either approach was the gradual rate reduction stuff would be too gradual when the return path is inflated by other traffic. My testbed is mostly focused on wifi where things like hardware retries dominate the impacts of new algorithms.