Yes, additionsally, though, we can learn lessons from data centers where there is a whole body ofwork on dealing with many-to-many (e.g. apps using map/reduce platforms and similar) that cause congestion in ways that might often be analgous to control plane traffic between routers of many kinds - this work post dates most the TFRC work (though usually is baselined on that for the pairwise case) - way back when saly & van wrote this from the routing perspective: https://www.icir.org/floyd/papers/sync_94.pdf
a few years back we did this https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-grosvenor_update.pdf which is from the data center, swtch queueu perspective (so about 75% non relevant) but table 2 on page 13 might give some ideas... cheers jon p.s. some people might like that you can click on the graphs in our paper and you get to go to the link for pages that hold code and data > > On 17 Dec, 2022, at 4:32 pm, Jeffrey (Zhaohui) Zhang > <[email protected]> wrote: > > > > - There are situations where a non-TCP based solution is needed even > when a parallel TCP-based option is also present, so we can not simply > disallow the former. We can discuss examples separately (one example is > actually PIM as BIER overlay vs mLDP/BGP as BIER overlay). > > There are also congestion control algorithms that don't rely on an > underlying TCP session, such as TFRC (TCP Friendly Rate Control). > Possibly these could be applied to existing protocols. > > - Jonathan Morton > _______________________________________________ > routing-discussion mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/routing-discussion >
