<div dir="ltr">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.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Thanks,</div>--MM--<br>The best way to predict the future is to create it.  - Alan Kay<br><br>We must not tolerate intolerance;</div><div dir="ltr">       however our response must be carefully measured: </div><div>            too strong would be hypocritical and risks spiraling out of control;</div><div>            too weak risks being mistaken for tacit approval.</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 4, 2021 at 4:16 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 4, 2021 at 3:45 PM Matt Mathis via Rpm<br>
<<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
><br>
> Please don't send this upstream.   It would makesTCP into the evil transport from hell.<br>
<br>
You mean it isn't already? :)<br>
<br>
There are a lot of test tools in the world (like pktgen) that are<br>
designed to do evil things to the network,<br>
why not evilTCP(tm)? Too many tools synthesize evil one way traffic<br>
and people draw incorrect conclusions<br>
from those....<br>
<br>
>  Modern loss recovery is robust enough to run hardcoded cwnd=<blat> and 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.<br>
><br>
> Dave overlooked an important detail in relentless TCP:<br>
<br>
It had been a while, and it was intended to be a complex point. But<br>
thx for the correction.<br>
<br>
>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 something Reno like but only on loss less RTTs.<br>
<br>
What I was looking for was a test tool that mimicked enough of tcp's<br>
coupled ack behavior to give more predictable results, when<br>
looking for expected behavior from an AQM (or policer). What I had<br>
been using before was a udp flood, but that was dicy (and very<br>
misleading) on non-duplex wireless.<br>
<br>
That, and a small nuclear reactor so I'd never have to put more diesel<br>
in my (still broken) boat.<br>
<br>
><br>
><br>
> If you want to adapt TCP<br>
> Thanks,<br>
> --MM--<br>
> The best way to predict the future is to create it.  - Alan Kay<br>
><br>
> We must not tolerate intolerance;<br>
>        however our response must be carefully measured:<br>
>             too strong would be hypocritical and risks spiraling out of control;<br>
>             too weak risks being mistaken for tacit approval.<br>
><br>
><br>
> On Fri, Oct 1, 2021 at 11:02 AM Luigi Rizzo via Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
>><br>
>> On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>> wrote:<br>
>> ><br>
>> > 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,<br>
>><br>
>><br>
>> I would be happy to submit it as one or two upstream patches --<br>
>> perhaps one to implement<br>
>> the basic "ignore_holes" + setsockopt(), and another mechanism (if<br>
>> there isn't one<br>
>> already) to override defaults sockopts on certain sockets.<br>
>><br>
>> I do think we need more readily available testing tool,<br>
>><br>
>> cheers<br>
>> luigi<br>
>> _______________________________________________<br>
>> Rpm mailing list<br>
>> <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/rpm" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br>
><br>
> _______________________________________________<br>
> Rpm mailing list<br>
> <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/rpm" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br>
<br>
<br>
<br>
-- <br>
Fixing Starlink's Latencies: <a href="https://www.youtube.com/watch?v=c9gLo6Xrwgw" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=c9gLo6Xrwgw</a><br>
<br>
Dave Täht CEO, TekLibre, LLC<br>
</blockquote></div>