Re: [iccrg] MulTFRC, a zombie calls from a grave

[Michael Welzl <[e-mail]>]

> On Jan 11, 2024, at 8:23 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> 
> On 1/8/2024 11:54 PM, Michael Welzl wrote:
>> It is a cool October night; close to midnight, in fact, but the moon is out, and so you don’t worry much about finding your steps on your way back home.
>> You and your friends had a great evening in town!  But did you really have to take that shortcut through the graveyard, you think to yourself? You know how it always makes you feel uneasy. The shadows cast by the trees, the flickering light of grave lanterns, and, last but not least, the smell. That smell!  You always hated it. The smell of earth that had been freshly turned over... as a kid, you used to imagine that it is the smell of death, emanating from the rotten corpses below the ground.
>> You shrug it off; this must be the tipsiness getting to you… you did have a few drinks too many after all. You’re a tech person, an IETFer - IETFers don’t believe in ghosts!  "But they believe in IPv6", you think to yourself, and it makes you chuckle.
>> All of a sudden, you hear a sound coming straight from a grave - clearly from below the ground: “MMMMMM”.
>> What was that? You stop and listen:  “Mmmmm….  Muuul…  MulTFRC !”
>> You had heard of TFRC before: an equation-based TCP-friendly congestion control algorithm from the good old days. So long ago… did YOU come across it, or is it a story that your parents had told you about?  You have also heard of MulTCP: a TCP variant that allows its user to configure how many TCP connections it should emulate. But, MulTFRC?
>> The grave opens, and a zombie steps out: https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-multfrc <https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-multfrc><https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-multfrc <https://datatracker.ietf.org/doc/html/draft-irtf-iccrg-multfrc>>
>> Vidhi, in her role as ICCRG chair, came across this zombie and asked us authors what we intend to do with it.  She wants to either kill it or revive it before it eats someone’s brain; it’s the protection instinct of an IRTF group chair, and you should all be thankful.
>> The idea behind this draft was to publish what we, back then, thought would be a useful algorithm for the community: similar to TFRC, but configurable to emulate N flows, where N is a float. So, a MulTFRC flow can be as aggressive as 1, 5, 10 TCP connections, but this number can also be 2,5 or 1.3 or even 0.3. It’s all based on an extension of the TCP steady-state equation by Padhye et al.   We did go through several reviews, and in the end failed to address one point made by Lachlan Andrew about getting the code to run in the kernel, without floats. We put some serious effort into trying to make this work, but then dropped the ball - also because we didn’t exactly see people shouting demands at us. Lachlan later told me that he didn’t think this was a blocking issue - and today, much CC. code is being run in user space. The question really is: does anyone care?
> 
> There were some discussions of that when beginning the development of QUIC 5 or 6 years ago -- tweaking the CC algorithm to emulate 2 connections, because when using TCP browsers often use 2 connections. I am not aware of anyone asking for fractions.
> 
> The draft is largely assuming that the CC algorithm works like RENO or CUBIC, i.e., uses CWIN as the control variable and reacts on packet loss. It is kind of irrelevant if the CC algorithm uses pacing rate as the control variable and measures path bandwidth, as BBR does.

FWIW, I agree…  I also believe that this is of historical value at best; but it was worth asking, I figured. And, it’s not even like Reno “or Cubic”: the TFRC equation models Reno.

Cheers,
Michael