(turning the page to current meeting)
", "time": "2023-11-07T08:33:44Z"}, {"author": "Reese Enghardt", "text": "Meetecho, can we get camera on the speaker please?
", "time": "2023-11-07T08:37:14Z"}, {"author": "Lorenzo Miniero", "text": "Done!
", "time": "2023-11-07T08:37:36Z"}, {"author": "Reese Enghardt", "text": "Thanks!
", "time": "2023-11-07T08:37:41Z"}, {"author": "Mike English", "text": "good (early) morning
", "time": "2023-11-07T08:41:41Z"}, {"author": "Lars Eggert", "text": "here's an \"interesting\" new CC: https://hysteria.network/docs/advanced/Full-Server-Config/#bandwidth-behavior-explained
", "time": "2023-11-07T08:42:11Z"}, {"author": "Lars Eggert", "text": "\"Brutal operates on a fixed rate model and does not reduce its speed in response to packet loss or RTT changes. If it fails to meet the predetermined target rate, the algorithm calculates the rate of packet loss and compensates by increasing speed.\"
", "time": "2023-11-07T08:42:28Z"}, {"author": "Randell Jesup", "text": "That is \"brutal\" to any other traffic.
", "time": "2023-11-07T08:48:56Z"}, {"author": "Victor Vasiliev", "text": "It's probably a theoretically optimal approach if you have shallow queues and don't care about latency, only the utilization of the network
", "time": "2023-11-07T08:50:20Z"}, {"author": "Spencer Dawkins", "text": "Lars Eggert said:
\n\n\nhere's an \"interesting\" new CC: https://hysteria.network/docs/advanced/Full-Server-Config/#bandwidth-behavior-explained
\n
All new CCs are \"interesting\", until we convince ourselves that they aren't, I think ... :grinning_face_with_smiling_eyes:
", "time": "2023-11-07T08:50:34Z"}, {"author": "Mike English", "text": "\n", "time": "2023-11-07T08:50:41Z"}, {"author": "Mike English", "text": "hence its name.
\n
:astonished:
", "time": "2023-11-07T08:51:00Z"}, {"author": "Spencer Dawkins", "text": "I'm off to a side meeting on SADCDN - Do The Right Thing!
", "time": "2023-11-07T08:51:40Z"}, {"author": "Eric Kinnear", "text": "Christian: feel free to jump back in the queue when you reconnect
", "time": "2023-11-07T08:56:59Z"}, {"author": "Christian Huitema", "text": "Just wanted to support Harald. Building queue is anti-social. Building queues impacts not just audio and video, but also any interactive system.
", "time": "2023-11-07T08:58:57Z"}, {"author": "altanai", "text": "\"Evaluation Criteria\" could become a tree of classes with MUST / SHOULD/others compliance added to a Congestion Control Algorithm's evaluation. This would help developers add classes as tags when presenting their algorithm's evaluation report .
", "time": "2023-11-07T09:01:26Z"}, {"author": "Mike English", "text": "A lot of comments at the mic seem to be about how to engage with unspecified/ non-IETF CC. I understand the intent of this slide to be mostly about how we evaluate IETF CC proposals in light of the existence of non-IETF CC in the wild.
", "time": "2023-11-07T09:01:30Z"}, {"author": "Mike English", "text": "We have only one queue :P
", "time": "2023-11-07T09:07:16Z"}, {"author": "Randell Jesup", "text": "@bob Briscoe -- That's very sad (few networks understand AQM)...
", "time": "2023-11-07T09:09:56Z"}, {"author": "Christian Huitema", "text": "There are places like cable networks where AQM deployment is just part of the spec.
", "time": "2023-11-07T09:10:42Z"}, {"author": "Christian Huitema", "text": "Also, to Matt's point that best effort needs to try to push the network -- it is mainly a question of how to push. There is a big difference for example between Reno, which \"pushes until it breaks\", Hystart, which \"pushes until the delay increases\", and BBR, which \"pushes until pushing does not increase throughput\". Doing the Reno thing today is really anti-social.
", "time": "2023-11-07T09:12:56Z"}, {"author": "Christian Huitema", "text": "+1 Stuart
", "time": "2023-11-07T09:13:14Z"}, {"author": "Christian Huitema", "text": "Traffic that is not delay sensitive should use something like LEDBAT...
", "time": "2023-11-07T09:13:59Z"}, {"author": "Mike English", "text": "+1 Stuart and also Vidhi who made a similar point earlier about not expecting realtime protocols to not also be bandwidth maximizing
", "time": "2023-11-07T09:14:27Z"}, {"author": "Zaheduzzaman Sarker", "text": "Just want to note that unless there is mechanism used to tell the network to put real-time and best effort traffic separately , they are going to share the same queue. and unfortunately that is the most of the cases now. When we design congestion control for real-time, we also consider that TCP CCs are not going to be fair with real-time. Hence the real-time CCs are not so soft on backing and may a bit try to hold their ground and when recovering elbow a bit aggressive to gain some share in the bandwidth. So, I am not completely agree that there is not consideration needed here.
", "time": "2023-11-07T09:14:59Z"}, {"author": "Randell Jesup", "text": "+1 stuart
\nAnd LEDBAT IIRC can cause some level of queuing (100ms?), so I'd be careful about suggesting that
When I said Ledbat, of course it has issue. But the gaol is nice: if you don't care about latency, you should really not try to build queues.
", "time": "2023-11-07T09:16:45Z"}, {"author": "Randell Jesup", "text": "IIRC there's a tuning parameter for target queue depth, but it's been like a decade since I really looked :-)
", "time": "2023-11-07T09:16:50Z"}, {"author": "Christian Huitema", "text": "Also, yes, the bandwidth of video, for example, can vary by two order of magnitues between low def and very high def...
", "time": "2023-11-07T09:18:03Z"}, {"author": "Randell Jesup", "text": "+1 for fifo and an AQM. It's tough in that it's a combinatorial expansion of work; even one AQM doubles the number of test scenarios
", "time": "2023-11-07T09:23:28Z"}, {"author": "altanai", "text": "In a private network where there is more control over the network infrastructure and traffic patterns, the need for AQM is not as critical/even applicable.
\nFor example in tunneled data traffic, prioritization, traffic shaping and resource reservation could be added to the evaluation doc instead of AQM test compliance
How to avoid synchronization using multicast?
", "time": "2023-11-07T09:25:32Z"}, {"author": "altanai", "text": "@Christian : Maybe Randomized start time / retransmission delays ?
", "time": "2023-11-07T09:29:10Z"}, {"author": "Victor Vasiliev", "text": "How does one distinguish self-induced loss from other kinds of loss?
", "time": "2023-11-07T09:32:45Z"}, {"author": "Christian Huitema", "text": "Monotonic feedback has its own issue: protocols there are orders of magnitude differences between the capacity of paths. If the motonic function grows fast, then the signal become very sparse when the capacity increases. If it grows too slowly, then the stabilization property of monotonic increase diminishes a lot...
", "time": "2023-11-07T09:36:59Z"}, {"author": "altanai", "text": "@Victor : self induced
\n can be deduced maybe from pattern classification ? such as ML traffic classification for deliberate traffic shaping, rate limiting, or firewall rules..
Min RTT is very much exposed to late comer advantage...
", "time": "2023-11-07T09:37:32Z"}, {"author": "Christian Huitema", "text": "Hear, hear. The call of this group should be to reduce loss and delays on the whole internet!
", "time": "2023-11-07T09:55:10Z"}, {"author": "Vidhi Goel", "text": "Hystart++ allows to prevent heavy losses during slow start
", "time": "2023-11-07T09:56:32Z"}, {"author": "Christian Huitema", "text": "Harald, it is also possible to do FEC \"above\" congestion control.
", "time": "2023-11-07T10:00:41Z"}, {"author": "Christian Huitema", "text": "For example, if you increase the FEC, you do a corresponding decrease of the CWIND
", "time": "2023-11-07T10:02:22Z"}, {"author": "Vidhi Goel", "text": "+1 to Lars point not to merge new criteria that may not have been evaluated/well understood yet
", "time": "2023-11-07T10:04:23Z"}, {"author": "Fran\u00e7ois Michel", "text": "we discussed FEC and CC quite extensively at nwcrg a few years ago and we came up with an informational RFC here, you might want to have a look at that: https://datatracker.ietf.org/doc/rfc9265/
", "time": "2023-11-07T10:04:34Z"}, {"author": "Fran\u00e7ois Michel", "text": "tldr; when FEC is part of the transport, we advocated to avoid hiding the packet loss signal to the CC when recovery a packet using FEC, and considering FEC packets as part of the congestion window
", "time": "2023-11-07T10:06:04Z"}, {"author": "Eric Kinnear", "text": "Matt: Queue is closed, but definitely worth following up offline
", "time": "2023-11-07T10:17:37Z"}, {"author": "Christian Huitema", "text": "Linux kernel ought to NOT be a reference!
", "time": "2023-11-07T10:20:03Z"}, {"author": "Victor Vasiliev", "text": "As one of the people who discovered the CUBIC quiescence bug while working on QUIC, I am amused by the assumption of Linux kernel being the reference
", "time": "2023-11-07T10:20:26Z"}, {"author": "Christian Huitema", "text": "Lol
", "time": "2023-11-07T10:22:06Z"}, {"author": "Christian Huitema", "text": "One of the point in the cambrian paper is that QUIc Cubic does spurious loss recovery, but Linux does not. And that's bad?
", "time": "2023-11-07T10:22:54Z"}]