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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
