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

[Matt Mathis <mattmathis@google.com>]

[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]

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@gmail.com> wrote:

> On Mon, Oct 4, 2021 at 3:45 PM Matt Mathis via Rpm
> <rpm@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@lists.bufferbloat.net> 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 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=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC
>

[-- Attachment #2: Type: text/html, Size: 5336 bytes --]