[Bloat] [Rpm] Relentless congestion control for testing purposes

Matt Mathis mattmathis at google.com
Mon Oct 4 19:29:17 EDT 2021


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 <dave.taht at gmail.com> wrote:

> On Mon, Oct 4, 2021 at 3:45 PM Matt Mathis via Rpm
> <rpm at lists.bufferbloat.net> 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=<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.
> >
> > 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
> 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 at lists.bufferbloat.net> wrote:
> >>
> >> On Fri, Oct 1, 2021 at 6:33 PM Bob McMahon <bob.mcmahon at 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 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 at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/rpm
> >
> > _______________________________________________
> > Rpm mailing list
> > Rpm at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20211004/df624ccf/attachment.html>


More information about the Bloat mailing list