IETF
iccrg
iccrg@jabber.ietf.org
Tuesday, November 8, 2022< ^ >
jishac has set the subject to: Internet Congestion Control Research Group
Room Configuration
Room Occupants

GMT+0
[13:07:56] frodek joins the room
[13:07:57] <zulipbot> (Kyle Rose) Hear hear
[13:19:19] <zulipbot> (Christian Huitema) Processing transactions faster saves energy per transaction. Fine. But does it lead to more transactions?
[13:24:47] <zulipbot> (Wolfgang Beck) maybe energy efficiency deserves its on research group
[13:35:24] <zulipbot> (Christian Huitema) Venkat is right, this is a very real problem. We can see issues like that even with Hystart
[13:37:18] <zulipbot> (Christian Huitema) Lots of studies of that effect for LEDBAT, e.g., https://arxiv.org/ftp/arxiv/papers/1006/1006.3018.pdf
[13:41:12] <zulipbot> (Ayush Mishra) Q: Do you differentiate between self-inflicted delay variation vs. delay variation caused by a competing flow? Would a delay convergent CCA starve even while competing with a non-delay convergent CCA?
[13:44:23] <zulipbot> (Ayush Mishra) Thanks Jana!
[13:44:37] <zulipbot> (Ayush Mishra) Got it, thanks Venkat!
[13:51:05] <zulipbot> (Christian Huitema) BBR has this regular probing for higher bandwidth. I was wondering whether there should be some equivalent "downward probing" in which for a given epoch the sender just slows down. Would that be a way to deliberately oscillate the delay?
[13:52:25] <zulipbot> (Kyle Rose) 👏
[13:54:24] <zulipbot> (Massimiliano Pala) yes.
[13:57:07] <zulipbot> (Venkat Arun) @Christian - That could work. The key is that the probe should indicate the level of congestion to the other flows observing the delay. BBR and LEDBAT do this, but only with the intention of discovering the min RTT. This is insufficient to solve this problem
[13:58:10] <zulipbot> (Christian Huitema) My other question is whether the correction shall require cooperation of other flows, or whether it can be done individually
[14:00:19] <zulipbot> (Vidhi Goel) Wouldn't ECN be helpful here to detect congestion building up due to other flows?
[14:00:45] <zulipbot> (Venkat Arun) I don't know yet. I think it will be easier to answer this question once we actually have a CCA that works when everybody is using the same algorithm. Then we can see whether we can create a standard analogous to "TCP friendliness" where we can allow individual flows to customize their CCA
[14:02:26] <zulipbot> (Christian Huitema) For ECN, the condition is probably to do something like multiplicative decrease, so there is asymptotic convergence to the desired state
[14:03:25] <zulipbot> (Venkat Arun) @Vidhi - Yes. With ECN I believe we can get close to ideal performance if done correctly. I don't know if RED/CoDel are the answer. Potential answers include accel-brake control (ABC) and its classical precursors RCP/XCP. The challenge of course is with universal deployment
[14:04:53] <zulipbot> (Vidhi Goel) Well, we have been making a lot of progress with L4S in the IETF as well as preparing for the deployment. It uses ECN in a similar way as DCTCP ( I am oversimplifying) on WAN
[14:06:45] <zulipbot> (Christian Huitema) @Vidhi -- yes, ECN is good. But Venkat is right to point out that it is not universally deployed. Also, some bottlenecks and some source of delay jitter happen below IP routing, and wont be signalled by ECN.
[14:07:53] <zulipbot> (Ayush Mishra) For starvation between BBR flows with different RTTs, starvation always happens in one direction (the smaller RTT flow always suffers). That makes me wonder if the starvation between diff RTT BBR flows is simply because they are bound by different cwnds (larger BDP estimate for the larger flow) rather than the fact that they are delay convergent.
[14:08:35] <zulipbot> (Vidhi Goel) Yes, that is self inflicted delay issue
[14:09:27] <zulipbot> (Ian Swett) +1 to Bob's comment.  Also, applications use networks in somewhat unpredictable ways.
[14:09:56] <zulipbot> (Roland Bless) @**Ayush Mishra** Yes, especially in BBRv1 it is the case that it's the CWnd Cap that is larger for larger RTT flows. For BBRv2 there are more subtle dependencies...
[14:10:09] <zulipbot> (Venkat Arun) @Vidhi - I would love to see ECN more widely deployed. If you are working toward that, that would be very helpful. I'm happy to discuss offline which methods of setting ECN will help
[14:10:43] <zulipbot> (Venkat Arun) @Ayush - You are right. cwnd cap => delay convergence => starvation. So both statements are correct :)
[14:10:56] <zulipbot> (Christian Huitema) Not sure about Bob's comment. Lenore points out the need to "model the assumptions", and it is better to make these model explicit.
[14:11:26] <zulipbot> (Ian Swett) Since the queue is closed, I was going to say that there might be value in proving that congestion controllers do the thing we expect them to do in even simplified circumstances.  Even if they can't model anything close to reality.
[14:11:39] <zulipbot> (Ian Swett) Good is better than perfect.
[14:12:40] <zulipbot> (Ian Swett) Sorry, I meant good is better than nothing.
[14:13:49] <zulipbot> (Venkat Arun) @Lenore, @Ken - I have been working on formal verification of CC (SIGCOMM 21). We came across some of the challenges you mentioned and solved some of them. Would love to chat more offline
[14:14:31] <zulipbot> (Vidhi Goel) @Venkat, happy to discuss offline. (I am not onsite but available on slack etc)This talk from Ingemar touches on adoption of L4S in 5G
[14:15:46] <zulipbot> (Venkat Arun) @Vidhi - you can reach me at venkatar@mit.edu
[14:16:15] <zulipbot> (Randell Jesup) I wonder how it decides what packets go into "latency sensitive traffic"?
[14:17:10] <zulipbot> (Vidhi Goel) That is an implementation detail but L4S spec says use ECT1 as a classifier
[14:23:32] <zulipbot> (Ian Swett) Which implementation of BBRv1 and LEDBAT++ are these?  Linux?
[14:24:11] <zulipbot> (Vidhi Goel) AFAIK, Linux doesn't have LEDBAT++ (and rLEDBAT)
[14:24:26] <zulipbot> (Randell Jesup) This is the same sort of issue we discussed in IETF XX back in 2011(?)  in Vancouver when we had the workshop on realtime data congestion control, and then created the RMCAT working group.
[14:24:53] <zulipbot> (Randell Jesup) (With regards to (plain) LEDBAT and realtime flows)
[14:26:30] <zulipbot> (Randell Jesup) A lot of this was driven by the 100ms(? IIRC) target delay for the original LEDBAT.   This modification looks interesting
[14:29:01] <zulipbot> (Randell Jesup) IIRC the original LEDBAT had fairness issues between LEDBAT streams as well.  Not sure if they had a similar cause
[14:29:28] <zulipbot> (Randell Jesup) Note: I'm not an expert on LEDBAT; this is all based on my memories from around the time of that IETF meeting
[14:30:08] <zulipbot> (Venkat Arun) @Randell - I believe that the original LEDBAT was not designed for inter-LEDBAT fairness
[14:30:08] frodek leaves the room
[14:30:21] <zulipbot> (Christian Huitema) I hate the idea of fixed delays, like "100ms" or "10 seconds". Also, synchronization is generally a failure.
[14:30:47] <zulipbot> (Christian Huitema) Something random would be much simpler.
[14:30:47] <zulipbot> (Randell Jesup) I don't see how you can synchronize successfully with N streams on a link
[14:31:21] <zulipbot> (Simone Ferlin) Yes, we can @Gorry :)
[14:31:34] <zulipbot> (Christian Huitema) How you will. If multiple processes have the same period, then it takes very little signal to have them come in synch.
[14:32:35] <zulipbot> (Ian Swett) Scan early, scan often
[14:32:49] <zulipbot> (Christian Huitema) It will take several periods, bt not many.
[14:33:23] <zulipbot> (Randell Jesup) How does a new flow syncrhonize?  If flows start and stop often, then will it synch?
[14:58:51] frodek joins the room
[15:29:52] frodek leaves the room