[Rpm] Relentless congestion control for testing purposes

[Rpm] 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

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

[Jonathan Morton]

> On 29 Sep, 2021, at 2:17 am, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 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.

I think "no response at all" is overstating it.  Right in the abstract, it is described as removing the lost segments from the cwnd; ie. only acked segments result in new segments being transmitted (modulo the 2-segment minimum).  In this sense, Relentless TCP is an AIAD algorithm much like DCTCP, to be classified distinctly from Reno (AIMD) and Scalable TCP (MIMD).

   Relentless congestion control is a simple modification that can be
   applied to almost any AIMD style congestion control: instead of
   applying a multiplicative reduction to cwnd after a loss, cwnd is
   reduced by the number of lost segments.  It can be modeled as a
   strict implementation of van Jacobson's Packet Conservation
   Principle.  During recovery, new segments are injected into the
   network in exact accordance with the segments that are reported to
   have been delivered to the receiver by the returning ACKs.

Obviously, an AIAD congestion control would not coexist nicely with AIMD based traffic.  We know this directly from experience with DCTCP.  It cannot therefore be recommended for general use on the Internet.  This is acknowledged extensively in Mathis' draft.

> 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.

Yes, as a tool specifically for testing with, and distributed with copious warnings against attempting to use it more generally, this might be interesting.

 - Jonathan Morton