From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 43A823CB35 for ; Mon, 4 Oct 2021 19:29:31 -0400 (EDT) Received: by mail-wr1-x431.google.com with SMTP id r18so6417935wrg.6 for ; Mon, 04 Oct 2021 16:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VMODE4BDH3o+Iom17yPM6RJn/lHJMJNMitPJN5Q/si4=; b=QX93eAW195EO3ENRfn5iz8YCYNiU4c9NWdujCSQdJP7eggUOytSB4YMu08NswFqTyl X6aR5aWcG2hmekVvsVGew7QmhRPGpj0zZ2yZwMvzcDtyi51mctqzPynV/A2i9ODiDsqy 5IV6FxuTcDi+/xz7+kl1FzjQE5Q+oIlw9gxJaFhgIuYQ2O+VevA6uSaITs+UAJZp2aQA 3bD6XY59V9kag6lSt9JnaprnQwVQriwTtnNkcIS1X8KZP5MTjrR+uN4w7MZa3qDC68Um 55YkdsUMUcMa8ns1mtopnn32zkEB3+b+zUnZBD/NfTcuREcrdS3b290lCn4QXgthTVyg 4r+Q== 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; bh=VMODE4BDH3o+Iom17yPM6RJn/lHJMJNMitPJN5Q/si4=; b=rKO+TZrcp3tkMuFBSjR5Lx+1anTPGkdUVXnD8F11fvFieLYcuJlS7vau2BdVN+xXCE Q1fkBG/PCjN0gr7UMoTRJv6hoj9G5i9MK/69IFgtVPI1DApquLMTn6+fw2A5RM3Ts1UX 1i2fjxAZYsAges/3AqRX0a2YYQheQ03ephCYaLh0IVeed1aK7JBvXEOVcNLNZA4TbJ33 R/UVn/8ejzWTwbqtU+OJwjdfmP2Q2JFyfWVrud4tdwk78n81ThfPVl9SpYsF46gN6WZm DIDmLNU9Icw7eFJ2OXv/lK1GUbBlODwwf3AsT/9f0b1lxoh5uUP2QLkNo9wguKNzNWNY HqDQ== X-Gm-Message-State: AOAM530hJf2iMp7vsKQ0qnDgev/iS+n4OH1b1djLRAEpfRDc84WewhPF S6JsqBjwpW3uoFj+BcLJAVh4VhIEgG4vcefLrSo6w7ayylXt1g== X-Google-Smtp-Source: ABdhPJyNWX2+ZrUUSC0D85Tldud7dfjoSKpIrBdgMe0ueS3XWRu0c/2jhxuQKYisCXV8sjoUGHboCOLVOaaLHf8rL1M= X-Received: by 2002:adf:a48c:: with SMTP id g12mr1909534wrb.341.1633390170043; Mon, 04 Oct 2021 16:29:30 -0700 (PDT) MIME-Version: 1.0 References: <56ef13985bd34834916aabef978db1f1@EX16-05.ad.unipi.it> In-Reply-To: From: Matt Mathis Date: Mon, 4 Oct 2021 16:29:17 -0700 Message-ID: To: Dave Taht Cc: Luigi Rizzo , Bob McMahon , Karl Auerbach , "rpm@lists.bufferbloat.net" , Luigi Rizzo , bloat , Ben Greear Content-Type: multipart/alternative; boundary="000000000000ddd19905cd8f48f0" 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:29:31 -0000 --000000000000ddd19905cd8f48f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Spewing crap is easy, but useless except to annoy people. EvilTCP would actually reliably deliver data and could do extremely useful work, at the expense of other users. 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 control; too weak risks being mistaken for tacit approval. On Mon, Oct 4, 2021 at 4:16 PM Dave Taht wrote: > 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 > transport 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 a= nd > persistent losses, Please don't make this too easy for people who are > intent 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 loa= d > was exactly the quantity of data successfully delivered on the previous > RTT. I have forgotten the details of the increase function, but it was > something 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 > control; > > too weak risks being mistaken for tacit approval. > > > > > > On Fri, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm < > rpm@lists.bufferbloat.net> wrote: > >> > >> On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon > wrote: > >> > > >> > hmm, this looks interesting to a test & measurement guy. Can it be > done with a setsockopt? I might want to add this as an iperf2 option, > particularly 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 > > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwg= w > > Dave T=C3=A4ht CEO, TekLibre, LLC > --000000000000ddd19905cd8f48f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Spewing crap is easy, but useless=C2=A0except to annoy=C2= =A0people.=C2=A0 =C2=A0EvilTCP would actually reliably deliver data and cou= ld do extremely useful work, at the expense of other users.

Thanks,
--MM--
The best way to predict the future is to cre= ate it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefu= lly measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too= strong would be hypocritical and risks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mistaken fo= r tacit approval.

=
On Mon= , Oct 4, 2021 at 4:16 PM Dave Taht <dave.taht@gmail.com> wrote:
On Mon, Oct 4, 2021 at 3:45 PM Matt Mathis via Rpm <rpm@list= s.bufferbloat.net> wrote:
>
> Please don't send this upstream.=C2=A0 =C2=A0It would makesTCP int= o the evil transport 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....

>=C2=A0 Modern loss recovery is robust enough to run hardcoded cwnd=3D&l= t;blat> and persistent losses, Please don't make this too easy for p= eople who are intent 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 lo= ad was exactly the quantity of data successfully delivered on the previous = RTT.=C2=A0 =C2=A0I have forgotten the details of the increase function, but= it was something 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<= br> in my (still broken) boat.

>
>
> If you want to adapt TCP
> Thanks,
> --MM--
> The best way to predict the future is to create it.=C2=A0 - Alan Kay >
> We must not tolerate intolerance;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 however our response must be carefully meas= ured:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too strong would be hyp= ocritical and risks spiraling out of control;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too weak risks being mi= staken for tacit approval.
>
>
> On Fri, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm <rpm@lists.bufferbloat.net<= /a>> wrote:
>>
>> On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon <bob.mcmahon@broadcom.com>= wrote:
>> >
>> > hmm, this looks interesting to a test & measurement guy. = Can it be done with a setsockopt? I might want to add this as an iperf2 opt= ion, particularly 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 mec= hanism (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@lis= ts.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm



--
Fixing Starlink's Latencies: https://www.youtube.co= m/watch?v=3Dc9gLo6Xrwgw

Dave T=C3=A4ht CEO, TekLibre, LLC
--000000000000ddd19905cd8f48f0--