[Bloat] Relentless congestion control for testing purposes

[Dave Taht]

In today's rpm meeting I didn't quite manage to make a complicated
point. This long-ago proposal
of matt mathis's has often intrigued (inspired? frightened?) me:

https://datatracker.ietf.org/doc/html/draft-mathis-iccrg-relentless-tcp-00

where he proposed that a tcp variant have no response at all to loss
or markings, merely
replacing lost segments as they are requested, continually ramping up
until the network
basically explodes.

In the context of *testing* bidirectional network behaviors in
particular, seeing tcp tested more than unicast udp
has been, in more labs, has long been on my mind.

Also, I have a long held desire to more quickly and easily determine
the correct behavior (or existence) of a particular aqm in a given
implementation,  so the predictability of such an approach has appeal.
Having a well defined mis-behavior of being "relentless" then lets
other variables along the path such as the client's particular tcp
acking methods, ack filtering at the bottleneck, request/grant delays
on a wifi AP/client setup, etc., be more visible.

This particular approach might actually find multiple bottlenecks,
until the ack channel itself gets backlogged. That too is
interesting... and a test using this method to probe for available
bandwidth would complete quickly and produce a more reliable result.

policer and ddos defense designers would find such behavior useful to
test against, also.

I return now to scraping americium out of my private collection of
smoke detectors with my teeth so as to
repower my boat with a small nuclear reactor.

(the above statement is a joke, but I'm kind of serious about
everything else. I think. Do any commercial
 test tools have such a tcp?)

-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC