Good morning
", "time": "2024-11-05T09:32:16Z"}, {"author": "Zeqi Lai", "text": "Good morning!
", "time": "2024-11-05T09:35:11Z"}, {"author": "Marten Seemann", "text": "It's 5 min past and we haven't started yet?
", "time": "2024-11-05T09:35:18Z"}, {"author": "Reese Enghardt", "text": "We'll get started now
", "time": "2024-11-05T09:35:32Z"}, {"author": "Marten Seemann", "text": "That's what they call slow start
", "time": "2024-11-05T09:35:45Z"}, {"author": "Craig Taylor", "text": ":drum:
", "time": "2024-11-05T09:36:57Z"}, {"author": "Christian Huitema", "text": "How do you change a parameter? Easy. You change the value, recompile your QUIC stack, and ship it.
", "time": "2024-11-05T09:42:41Z"}, {"author": "Christian Huitema", "text": "(kidding)
", "time": "2024-11-05T09:43:05Z"}, {"author": "Eduard V", "text": ":smiley:
", "time": "2024-11-05T09:43:14Z"}, {"author": "Ingemar Johansson", "text": "Agree \"If it compiles, ship it!\" :-)
", "time": "2024-11-05T09:44:28Z"}, {"author": "Jonathan Lennox", "text": "\"For LEO, there's an entire space to explore\"...pun intended?
", "time": "2024-11-05T09:57:33Z"}, {"author": "Ingemar Johansson", "text": ":grinning_face_with_smiling_eyes:
", "time": "2024-11-05T09:57:46Z"}, {"author": "Ingemar Johansson", "text": "With some luck, and if the time schedule holds, I will be able to (at the ICCRG session on friday) bring up a few of the quirks and farts with 5G networks and how it impacts congestion control design.
", "time": "2024-11-05T10:00:55Z"}, {"author": "Christian Huitema", "text": "There are two parts in the equation: description of networks, and description of workloads. The \"rate limited\" discussion is an example of issues driven more by the workload than the network.
", "time": "2024-11-05T10:04:11Z"}, {"author": "Reese Enghardt", "text": "Agreed. 5033bis already has some great content on networks and workloads, which I hope can be a great reference point for us here
", "time": "2024-11-05T10:05:11Z"}, {"author": "Christian Huitema", "text": "I am always a bit queasy with the \"fair to cubic\" discussions. For example, the changes in BBrv3 for Cubic fairness come at the cost of longer adaptive loops -- tradeoffs! There should be a way to weight these tradeoffs without necessarily bowing to cubic.
", "time": "2024-11-05T10:28:17Z"}, {"author": "Ingemar Johansson", "text": "Perhaps not fully relevant but, RFC9331 is experimental and that does not stop L4S deployment. I guess the weight of experimental vs standards track differ between WGs
", "time": "2024-11-05T10:32:08Z"}, {"author": "Christian Huitema", "text": "Mo points out a practical feedback loop that is different from \"finding things in simulation\". We take a customer experience, such as \"running realtime video over Wi-Fi\", we find issues, and then we design simulations that capture the issue and let us test possible fixes.
", "time": "2024-11-05T10:36:39Z"}, {"author": "Christian Huitema", "text": "Mark discusses the issue with \"early exit from slow start\". I think the underlying issue is the huge difference in gain, or aggression, between slow start (double every RTT) and congestion avoidance (double after 30-60 RTT). That creates a discontinuity in the behavior. It be nice if transitions were much more gradual.
", "time": "2024-11-05T10:41:16Z"}, {"author": "Jonathan Morton", "text": "I have something in the pipeline about that.
", "time": "2024-11-05T10:41:45Z"}, {"author": "Ingemar Johansson", "text": "Chirped slow start tried to address slow start. One issue is that cellular links can aggregate TCP ACKs. Does this work perform well when subject to ACK aggregation ?
", "time": "2024-11-05T10:43:39Z"}, {"author": "Christian Huitema", "text": "QUIC does end-to-end ACK aggregation. With QUIC \"ACK Frequency\", you get typically 4 to 8 ACK per RTT, even if the window is 100 to 500 packets.
", "time": "2024-11-05T10:45:55Z"}, {"author": "Christian Huitema", "text": "The control loop is RTT long. It does not make too much sense to make 500 control decisions within one RTT...
", "time": "2024-11-05T10:46:47Z"}, {"author": "Kyle Rose", "text": "Christian Huitema said:
\n\n\nI am always a bit queasy with the \"fair to cubic\" discussions. For example, the changes in BBrv3 for Cubic fairness come at the cost of longer adaptive loops -- tradeoffs! There should be a way to weight these tradeoffs without necessarily bowing to cubic.
\n
I would go further and argue that there should be a strong incentive to move away from loss-based/queue-building CC algorithms like cubic. As long as BBR is viable, i.e., can achieve stability with itself and similar CC algs, anything that discourages bufferbloat is a net positive for low-latency applications.
", "time": "2024-11-05T10:47:50Z"}, {"author": "Christian Huitema", "text": "Kill Cubic and Reno in the name of low latency? Part of me would like that, but another part of my brain considers wrecking the experience of millions of users as not necessarily the best tradeoff...
", "time": "2024-11-05T10:51:16Z"}, {"author": "Jinoo Joung", "text": "As far as I understand the CC for TCP flows is for the network, not the flow performance itself. Los latency flows should use UDP.
", "time": "2024-11-05T10:53:53Z"}, {"author": "Jinoo Joung", "text": "Low latency flows
", "time": "2024-11-05T10:54:10Z"}, {"author": "Kyle Rose", "text": "That outcome seems unlikely to me, but I'd also argue most clients will update pretty quickly when the writing is on the wall. But sure, tuning the trade-offs so the transition happens in a few less severe steps seems fine: it would just be nice to complete the transition in finite time.
", "time": "2024-11-05T10:54:30Z"}, {"author": "Ingemar Johansson", "text": "TCP or [something] over UDP is just the pack horse
", "time": "2024-11-05T10:54:49Z"}, {"author": "Neal Cardwell", "text": "tcp_slow_start_after_idle
", "time": "2024-11-05T10:54:51Z"}, {"author": "Kyle Rose", "text": "I.e., \"wreck\" seems like too strong a descriptor for what most users will actually observe.
", "time": "2024-11-05T10:55:46Z"}, {"author": "Craig Taylor", "text": "yes, and is on by default.
", "time": "2024-11-05T10:55:49Z"}, {"author": "Ingemar Johansson", "text": "I guess slow_start_after_idle disabled requires packet pacing to avoid that queues are bloated at line rate ?
", "time": "2024-11-05T10:56:46Z"}, {"author": "Christian Huitema", "text": "The Search problem could be called \"boiling the milk\". When I was little, we could only get raw milk directly from the farm nearby. We would boil it to kill germs. You had to watch the pot and stop before the milk actually boiled and spilled. You would turn off the heat immediately when it started to bubble. But not too soon, because we really needed to kill the germs. Slow start is a bit like that. We want to stop doubling and avoid spilling vast numbers of packets over the network queues. We would like to have a signal similar to the tiny bubbles in the boiling milk. Hystart uses \"slight delay variations\" for that, but that signal is not overly reliable. What else?
", "time": "2024-11-05T10:56:56Z"}, {"author": "Jonathan Morton", "text": "Christian, remind me to talk to you about ESSP.
", "time": "2024-11-05T10:57:52Z"}, {"author": "Craig Taylor", "text": "Disabling slow_start_after_idle is orthoganol to pacing. It's a very common change for server infrastructure
", "time": "2024-11-05T10:58:00Z"}, {"author": "Ingemar Johansson", "text": "Yes, sure. But for instance for VoD it can be quite a challenge to push a large CWND of data when a new 2MByte VoD chunk is to be transmitted
", "time": "2024-11-05T10:59:09Z"}, {"author": "Christian Huitema", "text": "Did someone study the difference between the BBR \"bandwidth plateau\" and Hystart's \"growing delay\" ?
", "time": "2024-11-05T11:00:54Z"}, {"author": "Michael Welzl", "text": "Does disabling slow_start_after_able enable new_cwv, or does it just make the sender keep cwnd as it was?
", "time": "2024-11-05T11:01:53Z"}, {"author": "Jinoo Joung", "text": "Why would a VoD flow use TCP? It can use UDP and maybe a solution being discussed in the DetNet WG.
", "time": "2024-11-05T11:02:30Z"}, {"author": "Tim Chown", "text": "i voted no as i don't think search is top priority, but it is very interesting
", "time": "2024-11-05T11:04:39Z"}, {"author": "Kyle Rose", "text": "\"No, because I have forgotten how to write software\"
", "time": "2024-11-05T11:04:44Z"}, {"author": "Jonathan Morton", "text": "IMHO, slow-start is an important topic, but SEARCH might not be the best solution.
", "time": "2024-11-05T11:06:02Z"}, {"author": "Michael Welzl", "text": "Jonathan Morton said:
\n\n\nIMHO, slow-start is an important topic, but SEARCH might not be the best solution.
\n
Could you elaborate?
", "time": "2024-11-05T11:14:14Z"}, {"author": "Jonathan Morton", "text": "We're working on ESSP, taking yet another approach to the same problem.
", "time": "2024-11-05T11:15:22Z"}, {"author": "Jonathan Morton", "text": "There's no significant memory overhead per flow, in particular.
", "time": "2024-11-05T11:16:13Z"}, {"author": "Michael Welzl", "text": "Jonathan Morton said:
\n\n\nWe're working on ESSP, taking yet another approach to the same problem.
\n
This would be it: https://github.com/heistp/essp/blob/main/ESSP.md and I think it's a bigger change, to all of slow start - thus not a direct \"competitor\" to SEARCH IMO, as SEARCH just suggests the exit point of otherwise unchanged SS.
", "time": "2024-11-05T11:19:37Z"}, {"author": "Jonathan Morton", "text": "It's more analogous to HyStart++, in that there's more than one stage of growth.
", "time": "2024-11-05T11:21:24Z"}, {"author": "Tim Chown", "text": "so we've voted to focus on two things.. odd :)
", "time": "2024-11-05T11:21:59Z"}, {"author": "Tim Chown", "text": "\"work on\" vs \"focus on\" ?
", "time": "2024-11-05T11:22:18Z"}]