[{"author": "Jason Livingood", "text": "<p>Re slide 8 - why did idle latency drop in June 2024? That is when Starlink implemented AQM on the home gateway.</p>", "time": "2025-07-25T07:43:28Z"}, {"author": "Jason Livingood", "text": "<p>It is not a Q</p>", "time": "2025-07-25T07:43:55Z"}, {"author": "Jason Livingood", "text": "<p>(slide 8 <em>asked</em> the Q - I tried to answer it)</p>", "time": "2025-07-25T07:44:19Z"}, {"author": "Dave Plonka", "text": "<p>ah, tnx. hard to track the content while chairing (for me) :)</p>", "time": "2025-07-25T07:44:37Z"}, {"author": "Jason Livingood", "text": "<p>;-)</p>", "time": "2025-07-25T07:44:44Z"}, {"author": "Anders K\u00f6lligan", "text": "<p>IONOS is also a cloud provider.</p>", "time": "2025-07-25T07:45:33Z"}, {"author": "Jason Livingood", "text": "<p><strong>great</strong> comment from Lorenzo! Excellent point on the 5% loss.</p>", "time": "2025-07-25T07:46:32Z"}, {"author": "Mike Blanche", "text": "<p>@Anders - but traffic going from HE (a global backbone provider) to IONOS and then back to HE makes absolutely no sense</p>", "time": "2025-07-25T07:48:00Z"}, {"author": "Mike Blanche", "text": "<p>which made me wonder what that traceroute graph was showing</p>", "time": "2025-07-25T07:48:18Z"}, {"author": "Florian Obser", "text": "<p>the <a href=\"http://k.root-servers.org\">k.root-servers.org</a> traceroute didn't make sense either. AS25152 is k.root-servers.<em>net</em>, k.root-servers.<em>org</em> is operated by AS3333. also, if you trace to AS25152 you are not going to see 3 hops inside of that AS.</p>", "time": "2025-07-25T07:50:53Z"}, {"author": "Mike Blanche", "text": "<p>yeah, typo maybe. k-root is anycast from AS25152. If HE is starlink's preferred transit provider I'd expect almost every traceroute to go directly 6939-&gt;25152</p>", "time": "2025-07-25T07:54:44Z"}, {"author": "Jason Livingood", "text": "<p>I pinged a buddy at Starlink to ask if he could come to IETF-124 &amp; present in some WG.</p>", "time": "2025-07-25T07:57:39Z"}, {"author": "Anders K\u00f6lligan", "text": "<p>@Mike the plot also says \"Most Frequent ASN\". Now I am unsure if this means \"most frequent next hop\" or \"most frequent AS for that number of hops\" probably the latter?</p>", "time": "2025-07-25T08:08:53Z"}, {"author": "Lucas Pardue", "text": "<p>Thanks for this work and for reaching out to implementers</p>", "time": "2025-07-25T08:28:26Z"}, {"author": "Alan Frindell", "text": "<p>no proxygen/mvfst  :(</p>", "time": "2025-07-25T08:32:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "<p>mvfst has so many dependencies and is much harder to use... at least in my out-dated experience.</p>", "time": "2025-07-25T08:33:18Z"}, {"author": "Lucas Pardue", "text": "<p>Its splitting hairs but you can't test \"QUIC-only\" because QUIC delegates responsibility for stream or datagram data to applications. </p>\n<p>You can have a \"minimal application layer\" like HTTP/0.9 as shown on slide 6. But the \"QUIC-only\" name is a minsomer - its just a different minimal application layer.</p>", "time": "2025-07-25T08:33:47Z"}, {"author": "Alan Frindell", "text": "<p>For H3 measurements, just pull and build proxygen, which will pull in mvfst and the deps.</p>\n<p>We do serve a lot of traffic, despite the github stars :)</p>", "time": "2025-07-25T08:34:33Z"}, {"author": "Nick Banks", "text": "<p>No msquic either :(</p>", "time": "2025-07-25T08:35:22Z"}, {"author": "Alan Frindell", "text": "<p>Nick: :(</p>", "time": "2025-07-25T08:35:30Z"}, {"author": "Mirja K\u00fchlewind", "text": "<p>okay, yes, we actually wanted to modify the stack but if you just want to test it, it should be easy enough</p>", "time": "2025-07-25T08:35:54Z"}, {"author": "Mirja K\u00fchlewind", "text": "<p>come to the mic and tell them to come back next time with more data</p>", "time": "2025-07-25T08:36:19Z"}, {"author": "Alan Frindell", "text": "<p>There's also an http performance testing tool in the proxygen repo: httperf2: <a href=\"https://github.com/facebook/proxygen/tree/main/proxygen/httpclient/samples/httperf2\">https://github.com/facebook/proxygen/tree/main/proxygen/httpclient/samples/httperf2</a></p>", "time": "2025-07-25T08:36:53Z"}, {"author": "Nick Banks", "text": "<p>@lucas I agree you always need a protocol on top, but my quic perf draft does outline a minimal one that in practice tests only quic</p>", "time": "2025-07-25T08:37:09Z"}, {"author": "Lucas Pardue", "text": "<p>need more precise definitions of what \"only QUIC\" means. Is it eg.\"minimal application space processing\" or is it \"minimal application protocol framing on top of QUIC streams\" or ...</p>", "time": "2025-07-25T08:38:55Z"}, {"author": "Nick Banks", "text": "<p>I agree. That's why a spec is nice</p>", "time": "2025-07-25T08:39:14Z"}, {"author": "Alan Frindell", "text": "<p>how many parallel requests in the test setup?</p>", "time": "2025-07-25T08:39:23Z"}, {"author": "Lucas Pardue", "text": "<p>agree Nick</p>", "time": "2025-07-25T08:39:43Z"}, {"author": "Nick Banks", "text": "<p>I was assuming a single request...</p>", "time": "2025-07-25T08:39:53Z"}, {"author": "Alan Frindell", "text": "<p>The CPU graph was the sum of all cores, but not sure how you would use more than one if only one request at a time</p>", "time": "2025-07-25T08:40:17Z"}, {"author": "Lucas Pardue", "text": "<p>FWIW if this was a performance test using quiche open source tools, take the results with a pinch of salt because those are not optimized for perf</p>", "time": "2025-07-25T08:40:30Z"}, {"author": "Nick Banks", "text": "<p>Msquic supports QUIC (crypto) on one core and UDP on another</p>", "time": "2025-07-25T08:41:00Z"}, {"author": "Alan Frindell", "text": "<p>yeah but they have 8 cores in the test host</p>", "time": "2025-07-25T08:41:19Z"}, {"author": "Nick Banks", "text": "<p>It can effectively double throughout for these types of tests</p>", "time": "2025-07-25T08:41:20Z"}, {"author": "Nick Banks", "text": "<p>Throughput*</p>", "time": "2025-07-25T08:41:32Z"}, {"author": "Alan Frindell", "text": "<p>we don't serve a lot of 8gb http responses, though more now that folks like to download models</p>", "time": "2025-07-25T08:41:44Z"}, {"author": "Nick Banks", "text": "<p>Yeah, it's not a default setting. Only stuff like SMB would use it</p>", "time": "2025-07-25T08:42:58Z"}, {"author": "Lucas Pardue", "text": "<p>thanks for the perf talk though!</p>", "time": "2025-07-25T08:44:16Z"}, {"author": "Chris Box", "text": "<p>Does this mean pacing individual packets, or sending packets in small bursts with pacing between bursts? The former is terrible for Wi-Fi.</p>", "time": "2025-07-25T08:45:27Z"}, {"author": "Chris Box", "text": "<p>Ok so there are small bursts</p>", "time": "2025-07-25T08:49:48Z"}, {"author": "Lucas Pardue", "text": "<p>the authors of the pacing paper might be interested to know that quiche logs a custom \"send_at_time\" filed in the qlog packet sent event, that could be used to link the packet number between internal view and on wire reality</p>\n<p>source: <a href=\"https://github.com/cloudflare/quiche/blob/90163bd5215f6f2f6a8dd376346c1d05e487e144/quiche/src/lib.rs#L5024\">https://github.com/cloudflare/quiche/blob/90163bd5215f6f2f6a8dd376346c1d05e487e144/quiche/src/lib.rs#L5024</a></p>", "time": "2025-07-25T08:50:10Z"}, {"author": "Dave Plonka", "text": "<p>@Chris - good point though. It's interesting to see how this would work where a network segment was on shared radio media.</p>", "time": "2025-07-25T08:50:35Z"}, {"author": "Dave Plonka", "text": "<p>thanks @lucas</p>", "time": "2025-07-25T08:51:14Z"}, {"author": "Gorry Fairhurst", "text": "<p>I wonder how much pacing is benefcial, it's nice to see all the pacers do quite well at avoiding bursts ~ IW, and short bursts may actually be better for multiplexing?</p>", "time": "2025-07-25T08:59:13Z"}]