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

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

-- Christian Huitema

> 
> If you do find this interesting, please take a look at this page that has all the background material and code:
> https://folk.universitetetioslo.no/michawe/research/projects/multfrc/index.html <https://folk.universitetetioslo.no/michawe/research/projects/multfrc/index.html>
> … and tell us, here on the list, that you would be interested in seeing this published.  In the absence of declarations of interest, this zombie shall die.
> 
> 
> Cheers,
> Michael
> 
> 
> 
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://mailman.irtf.org/mailman/listinfo/iccrg