From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5728B3B29D; Tue, 28 Sep 2021 19:17:25 -0400 (EDT) Received: by mail-il1-x136.google.com with SMTP id k13so782176ilo.7; Tue, 28 Sep 2021 16:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=5nD29hY4HU32YHxg4sErsLihGGTnc98g60c9OVCEoAo=; b=qm8CFUYKH/Bg3S/fQEG3vl/TqBn7FPZskjMDkVJA9hx0mBlQQOR5wX8Po1XtCqeHmt 4WAlnqEbabUy5vAr0xS8pKW6VL5WytodhXiA+uk2TD5O5tyWI76tEa9CNr3RWNj0rfAG VwroX6eZTaJoHoolK0Ej6QMJVUb72k3g16uI4r5D0ArYVTIrFyueKescqID3ab04TgGd Vvz9j+xrQ4Z0OyTZoBJtsEbP2jD4g1+MCV6F1YkgtI5JyO9OPPumHZCsGQyDSCW6yZAi cLlkyaOktild6jtbaKxsnvC/+laIZ1r0YdrmvYsu34heBDNKf5vl8Yyu2gsF4QCnfk+l pg9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=5nD29hY4HU32YHxg4sErsLihGGTnc98g60c9OVCEoAo=; b=6EZhUKywZOu3/LyazKEdM61VoD59Ucfp9iUi92KV+GTjXmAOF3kn5oBNUlY/nZnYwz SUfIhJ27Lg9AysxFL/HEdrmAWi9x+rqvau1XT/42V3enZLM4droc9gF063sqkM/S+PvG H1aragLYFh1/6KdjdRs0+J5ZJnEP5werMDIwAkBYmBRu0PkugPHbgd19koxRgGZLqf6M deQPvAuufZ4YMrGc0hk7OSoGyr8wv7DrO0qaISY4tBLLSIXNo9qf8IHST/A8Jg9KcDkc muUC+/+bV7PEDc56WA8qg5E0+trPJ3heSuOTKpgBaIv0pzImNbiuvDOfjutgafIriamd X/HA== X-Gm-Message-State: AOAM532vBh3QnJ1YWyBGroksK4EDTqjHKjI7YAy3UWGzia9Lxk56NMNq dNyNEszUevXsak4jZF/25wJ0JJEU/1mxtrez+OX0jLk+Ipk= X-Google-Smtp-Source: ABdhPJwomBb7Qx7PYltZwxUOYc0NgDl/UaW8Lephv//xlTgvTDJ+R1xG5tRmXaK+4TAJKhN5+jJ78NS01OO1vRsXydc= X-Received: by 2002:a05:6e02:c11:: with SMTP id d17mr6390236ile.25.1632871044590; Tue, 28 Sep 2021 16:17:24 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Tue, 28 Sep 2021 16:17:12 -0700 Message-ID: To: rpm@lists.bufferbloat.net Cc: Ben Greear , Bob McMahon , bloat , Karl Auerbach Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Bloat] Relentless congestion control for testing purposes X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 23:17:25 -0000 In today's rpm meeting I didn't quite manage to make a complicated point. This long-ago proposal of matt mathis's has often intrigued (inspired? frightened?) me: https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00 where he proposed that a tcp variant have no response at all to loss or markings, merely replacing lost segments as they are requested, continually ramping up until the network basically explodes. In the context of *testing* bidirectional network behaviors in particular, seeing tcp tested more than unicast udp has been, in more labs, has long been on my mind. Also, I have a long held desire to more quickly and easily determine the correct behavior (or existence) of a particular aqm in a given implementation, so the predictability of such an approach has appeal. Having a well defined mis-behavior of being "relentless" then lets other variables along the path such as the client's particular tcp acking methods, ack filtering at the bottleneck, request/grant delays on a wifi AP/client setup, etc., be more visible. This particular approach might actually find multiple bottlenecks, until the ack channel itself gets backlogged. That too is interesting... and a test using this method to probe for available bandwidth would complete quickly and produce a more reliable result. policer and ddos defense designers would find such behavior useful to test against, also. I return now to scraping americium out of my private collection of smoke detectors with my teeth so as to repower my boat with a small nuclear reactor. (the above statement is a joke, but I'm kind of serious about everything else. I think. Do any commercial test tools have such a tcp?) --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC