From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 6519C3CB35; Mon, 4 Oct 2021 19:16:24 -0400 (EDT) Received: by mail-il1-x132.google.com with SMTP id b6so20080096ilv.0; Mon, 04 Oct 2021 16:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xROJlc5K0uX/bAOyAfqawUUnLoSc9CMwDiNE1/p5IwU=; b=Vv6wcyNyEeugiGawLoWH4MqL9o5L3pvmpne1mICqwlbbx3QchGFkYGv/PL6Jmu6HzN sGIS6Lbmx/yoStmcjTjHOVoSw0pM2VVSNWFcU0aHTKwPUL+w16mJH9e1Ex3HycPxpd24 ejscDALiLof1EueGaWVyIC5nzjNJZGwz0oh17jj+HCbhFDqU5ZMxxy3ygUu2x5M3lrcN EIEAJ3jvxtOEFear5Sk93QFMuWrpkARh22eNWjlMeBF5fpfpgmDv3YxSKf+KYWxEfcN0 V1Uyu6+PbGvnm+MC24PJHIAJodNB/REr5QDXhfErbaxo4aTPvzw5ZWxHBZJy+HHM90rk e0jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xROJlc5K0uX/bAOyAfqawUUnLoSc9CMwDiNE1/p5IwU=; b=HjA93JhXD/WKczDTa5dMcbhPGvnifd/FXSlHzPxGToc8LOJP0PDE9sjuYyaJtZ2/b1 3XpgC46TqqP55kX040RlTKrLf8ECUa48SIjNjDqc+BeWrUnkGuc8wYxsOHeSDUwjq9vQ Sr2h+3jh7w/3aPYTsWohMdDDLMa9PtaIB6Hf1MTnMCORLMMD7Wt3xic5bY+kZJgxUap+ 9kliR87EtVZPUAHBzz7jxWOeEcTt+Vf/7GM5r9v1S7cwMstfxsQVK8r+bhiRxIv49wXm r7P+7Sa1mQwrFLiY2A/q4bFjpVRHk6udeiDng8oVm4gWiaJpeK8lRkmniAsfWRmf0HJw Lhxw== X-Gm-Message-State: AOAM532qUEkDGYlyFtb3JlPRarKAhr5p5E5Ajppt8tX3Z5cgYyT2b7fe AoXjCe3oEYEBxc6atf2NYQIZBKLiF53Nh1zicqY= X-Google-Smtp-Source: ABdhPJwTMHsP6Z24Ua8PXpInFbgJx+cIKhjCbXxediJow8ScD6zZDGvVMrUUYT085liMIBL87YJjoNFfo1HvGD/Kp58= X-Received: by 2002:a05:6e02:c11:: with SMTP id d17mr563934ile.25.1633389383622; Mon, 04 Oct 2021 16:16:23 -0700 (PDT) MIME-Version: 1.0 References: <56ef13985bd34834916aabef978db1f1@EX16-05.ad.unipi.it> In-Reply-To: From: Dave Taht Date: Mon, 4 Oct 2021 16:16:10 -0700 Message-ID: To: Matt Mathis Cc: Luigi Rizzo , Bob McMahon , Karl Auerbach , "rpm@lists.bufferbloat.net" , Luigi Rizzo , bloat , Ben Greear Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Rpm] [Bloat] Relentless congestion control for testing purposes X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 23:16:24 -0000 On Mon, Oct 4, 2021 at 3:45 PM Matt Mathis via Rpm wrote: > > Please don't send this upstream. It would makesTCP into the evil transp= ort from hell. You mean it isn't already? :) There are a lot of test tools in the world (like pktgen) that are designed to do evil things to the network, why not evilTCP(tm)? Too many tools synthesize evil one way traffic and people draw incorrect conclusions from those.... > Modern loss recovery is robust enough to run hardcoded cwnd=3D and= persistent losses, Please don't make this too easy for people who are inte= nt on getting their "fair" share of the network before the greedy people. > > Dave overlooked an important detail in relentless TCP: It had been a while, and it was intended to be a complex point. But thx for the correction. >It reduced the window by exactly the losses, such that the presented load = was exactly the quantity of data successfully delivered on the previous RTT= . I have forgotten the details of the increase function, but it was somet= hing Reno like but only on loss less RTTs. What I was looking for was a test tool that mimicked enough of tcp's coupled ack behavior to give more predictable results, when looking for expected behavior from an AQM (or policer). What I had been using before was a udp flood, but that was dicy (and very misleading) on non-duplex wireless. That, and a small nuclear reactor so I'd never have to put more diesel in my (still broken) boat. > > > If you want to adapt TCP > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > We must not tolerate intolerance; > however our response must be carefully measured: > too strong would be hypocritical and risks spiraling out of c= ontrol; > too weak risks being mistaken for tacit approval. > > > On Fri, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm wrote: >> >> On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon wr= ote: >> > >> > hmm, this looks interesting to a test & measurement guy. Can it be don= e with a setsockopt? I might want to add this as an iperf2 option, particul= arly if it's broadly available, >> >> >> I would be happy to submit it as one or two upstream patches -- >> perhaps one to implement >> the basic "ignore_holes" + setsockopt(), and another mechanism (if >> there isn't one >> already) to override defaults sockopts on certain sockets. >> >> I do think we need more readily available testing tool, >> >> cheers >> luigi >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC