[{"author": "Eduard V", "text": "<p>It is strange that search for \"BBR\" in the presentation or the draft gives no result. Is PPR better? How BBR is solving this issue? BBR claimed that have fast start on recovery</p>", "time": "2024-03-18T05:43:44Z"}, {"author": "Neal Cardwell", "text": "<p>Hi Eduard. PRR is applicable for standard congestion controls: either Reno or CUBIC. BBR uses a very different approach, and PRR does not apply.</p>", "time": "2024-03-18T05:50:51Z"}, {"author": "Neal Cardwell", "text": "<p>PRR does a great job of handling high loss situations, but it uses the ssthresh decision from the congestion control algorithm, so the long-term behavior for a connection using PRR is determined by the Reno or CUBIC algorithms (with all the pros and cons that implies).</p>", "time": "2024-03-18T05:53:28Z"}, {"author": "Eduard V", "text": "<p>But is BBR better/worse on the recovery?</p>", "time": "2024-03-18T05:53:49Z"}, {"author": "Neal Cardwell", "text": "<p>BBRv1 uses an approach very similar to PRR. BBRv3 uses an approach that is simpler than PRR and more aggressive than PRR. Which approach is better will depend on the scenario. :-)</p>", "time": "2024-03-18T05:55:09Z"}, {"author": "Eduard V", "text": "<p>thanks</p>", "time": "2024-03-18T05:55:52Z"}, {"author": "Zaheduzzaman Sarker", "text": "<p>lets not break the Internet with experiments.... :-).. even for experimental RFC we will need data to say it is working.</p>", "time": "2024-03-18T06:08:15Z"}, {"author": "Carles Gomez", "text": "<p>Agreed :)</p>", "time": "2024-03-18T06:12:09Z"}, {"author": "Martin Duke", "text": "<p>+1 to Ian. TCP is the wrong layer to solve this problem.</p>", "time": "2024-03-18T06:24:34Z"}, {"author": "Martin Duke", "text": "<p>Aside from the authentication problems, it saves us adding a new kernel API</p>", "time": "2024-03-18T06:25:11Z"}, {"author": "Gorry Fairhurst", "text": "<p>Oh... I've just learned what a ghost ACK is :-(</p>", "time": "2024-03-18T06:40:32Z"}, {"author": "Ziyang Xing", "text": "<p>Dear chairman,<br>\nAt the end of the meeting, I would like to introduce our work on MPTCP MPQUIC multipath. Is that okay? thanks</p>\n<p><a href=\"https://datatracker.ietf.org/doc/draft-xing-nmop-sdn-controller-aware-mptcp-mpquic/\">https://datatracker.ietf.org/doc/draft-xing-nmop-sdn-controller-aware-mptcp-mpquic/</a></p>", "time": "2024-03-18T06:41:47Z"}, {"author": "Yoshifumi Nishida", "text": "<p>hmm. I'm not sure if we can guarantee it at this point.</p>", "time": "2024-03-18T06:43:01Z"}, {"author": "Yoshifumi Nishida", "text": "<p>I'm guessing current presentation can take some time.</p>", "time": "2024-03-18T06:44:58Z"}, {"author": "Aijun Wang", "text": "<p>@Martin, there are lots  of applications that run directly on TCP, then why  TCP is the wrong layer to solve the problem?</p>", "time": "2024-03-18T06:46:02Z"}, {"author": "Aijun Wang", "text": "<p>Only TCP based applications need the service  affinity features.  QUIC  has similar mechanism, but TCP has no now</p>", "time": "2024-03-18T06:53:24Z"}, {"author": "John Border", "text": "<p>If keeping stats is an issue, can't you just remember the starting sequence number?</p>", "time": "2024-03-18T06:53:37Z"}, {"author": "Yepeng Pan", "text": "<p>@John: Yes (which is also state).</p>", "time": "2024-03-18T06:57:12Z"}]