[{"author": "Chris Box", "text": "

I don't attend v6ops so I'm glad this is being raised here. Getting optimisations right could significantly affect user experience. Good to see these ideas.

", "time": "2023-11-09T08:43:04Z"}, {"author": "Christian Huitema", "text": "

There are tons of complications with new transport -- like the QUIc handshake going hrough three stages each of which provide info, the use or not of 0-RTT, etc. That argues for transport, not IPv6!

", "time": "2023-11-09T08:47:56Z"}, {"author": "Jonathan Morton", "text": "

(slowly removes gloves and rolls up sleeves)

", "time": "2023-11-09T08:50:01Z"}, {"author": "Madhan Kanagarathinam", "text": "

Ditto, QUIC has inherent advantage of the connection establishment .. I think it would be better to take this in QUIC .. This is kinda different from v4 and v6 race .. it would be more interesting to discuss this topic in transport

", "time": "2023-11-09T08:50:57Z"}, {"author": "Rodney Grimes", "text": "

Why does the customer have a 225mS upstream queue avaliable?

", "time": "2023-11-09T09:00:45Z"}, {"author": "altanai", "text": "

For a tunneled packets : Isn't the ECN /DSCP tag from the inner header invisible tp the gateway like this for classification into low latency or normal latency ?
\nAdditionally an encapsulated protocol like ipse can set its own DSCP 45 to outer header to hijack the queues ?

", "time": "2023-11-09T09:04:25Z"}, {"author": "altanai", "text": "

encapsulating protocol like IPSec *

", "time": "2023-11-09T09:05:00Z"}, {"author": "Chris Box", "text": "

Presumably the increase in RPM will be larger once the downstream L4S support is deployed.

", "time": "2023-11-09T09:14:26Z"}, {"author": "Madhan Kanagarathinam", "text": "

8325 recommends gaming in VI

", "time": "2023-11-09T09:15:49Z"}, {"author": "Vidhi Goel", "text": "

@Chris: RPM can be measured separately for UL vs DL. In case of comcast results, there were some discrepancies in how users were running those tests. As Jason said, RPM improved after they confirmed with customers

", "time": "2023-11-09T09:18:15Z"}, {"author": "Chris Box", "text": "

Thanks Vidhi. I hadn't grasped that part. Jason implied he was looking for RPMs in the thousands so I guess there's work to do to identify where the packets are spending their time.

", "time": "2023-11-09T09:20:10Z"}, {"author": "Jason Livingood", "text": "

@Chris - We are very interested in the diff when we get the cable modem config files that had been incorrectly limiting upstream L4S throughput.

", "time": "2023-11-09T09:24:58Z"}, {"author": "Chris Box", "text": "

Yes many of us will be interested in the numbers. If you can share those that would be brilliant.

", "time": "2023-11-09T09:28:04Z"}, {"author": "Jason Livingood", "text": "

@rodney re \"Why does the customer have a 225mS upstream queue avaliable?\" Typically with DOCSIS PIE AQM you'd see maybe 25-30 ms of p99 LUL between CM and CMTS. Extending that across a much longer path off-net elevates that number and so e2e LUL around p99 at that level isn't unexpected.

", "time": "2023-11-09T09:29:06Z"}, {"author": "Rodney Grimes", "text": "

Is there any topology descriptions and data collected during these interops?

", "time": "2023-11-09T09:29:35Z"}, {"author": "Jonathan Morton", "text": "

30ms at the CM-CMTS plus 30ms baseline path is only 60ms though

", "time": "2023-11-09T09:29:47Z"}, {"author": "Jonathan Morton", "text": "

so there's 160ms missing from the accounting somewhere

", "time": "2023-11-09T09:30:45Z"}, {"author": "Rodney Grimes", "text": "

@jason my expierence says this 225ms is mostly at the upstream bottleneck in the modem.

", "time": "2023-11-09T09:30:57Z"}, {"author": "Madhan Kanagarathinam", "text": "

@jason in the GEForce slide

\n

With L4S: latency 28ms, uplink speed: 119Mbps

\n

without: 259 ms, uplink speed: 57

\n

No tradeoff? the uplink BE traffic any special treatment with L4S

", "time": "2023-11-09T09:33:41Z"}, {"author": "Jonathan Morton", "text": "

those numbers also don't at all match the 35Mbps upload capacity from slide 4

", "time": "2023-11-09T09:34:27Z"}, {"author": "Jason Livingood", "text": "

@Madhan see also https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-21.html#name-interoperability-with-exist

", "time": "2023-11-09T09:35:20Z"}, {"author": "Jason Livingood", "text": "

@jonathan There's also server-side processing at work in this - these are layer 7 stats from the client itself

", "time": "2023-11-09T09:37:05Z"}, {"author": "Jason Livingood", "text": "

@jonathan said \"225ms is mostly at the upstream bottleneck in the modem.\" Depends on the modem. If D3.0 then yes - buffer control usually sets it as 250ms max IIRC but D3.1 is AQM is on would be much lower. Again though this only focuses on the DOCSIS layer in the hop between CM and CMTS. When we pop up to layer 7 and go off-net there are additional variable.

", "time": "2023-11-09T09:38:46Z"}, {"author": "Jonathan Morton", "text": "

that was actually Rod

", "time": "2023-11-09T09:39:23Z"}, {"author": "Jonathan Morton", "text": "

but in this application, I'd expect even layer 7 to try very hard to minimise added delay

", "time": "2023-11-09T09:39:58Z"}, {"author": "Jonathan Morton", "text": "

so again, how are you getting 225ms latency without L4S?

", "time": "2023-11-09T09:40:36Z"}, {"author": "Madhan Kanagarathinam", "text": "

from experience (paper to be presented in GS), the default gaming does use suggested DSCP or the Wi-Fi UP .. In Android (Samsung), we ensure that real-time gaming Wi-Fi UP is AC_VI .. if the legacy apps were configured properly, then further comments .. :)

\n

Game and video call both should be VI btw .. so current L4S is as per RFC .. I hope non-L4S is also as per RFC 8325 :grinning:

", "time": "2023-11-09T09:40:47Z"}, {"author": "Jason Livingood", "text": "

@jonathan re \"those numbers also don't at all match the 35Mbps upload capacity from slide 4\" That 35 Mbps was one example of a gig tier user with 35 Mbps US. We also have advertised rates of 100 Mbps and 200 Mbps in the test (provisioned at 125 Mbps and 250 Mbps respectively).

", "time": "2023-11-09T09:40:55Z"}, {"author": "Madhan Kanagarathinam", "text": "

no further comments *

", "time": "2023-11-09T09:41:35Z"}, {"author": "Jason Livingood", "text": "

@jonathan re \"so again, how are you getting 225ms latency without L4S?\" Keep in mind these are not ISP stats off layer 3 but app developer stats off layer 7. There's a lot happening at that layer. See for example this NetForecast report on video conferencing (figure 8) https://www.netforecast.com/wp-content/uploads/NFR5137-Videoconferencing_Internet_Requirements.pdf. That example shows even aside from the network RTT that there may be audio & video processing and other app layer interactions. In any case, these are straight out of the application.

", "time": "2023-11-09T09:45:35Z"}, {"author": "Jonathan Morton", "text": "

as I said in the beginning, these are exactly the kinds of things that get solved by deploying Cake (or fq_codel), without needing any wire protocol changes

", "time": "2023-11-09T09:50:39Z"}, {"author": "Jason Livingood", "text": "

:shrug:\u200d\u2642\ufe0f

", "time": "2023-11-09T09:58:18Z"}, {"author": "Jason Livingood", "text": "

(tried to send a shurg emoji @JM - what a strange way that came to the chat!)

", "time": "2023-11-09T09:58:53Z"}, {"author": "Jonathan Morton", "text": "

apparently the emojis are broken, Meetecho know about it

", "time": "2023-11-09T09:59:15Z"}, {"author": "Greg White", "text": "

The D3.1 spec recommends that CM implementations default to a 50ms buffer (with RFC8034 AQM), it may be worth validating that these CMs are in fact defaulting to something close to that value. If not, the buffer can be configured to be so.

", "time": "2023-11-09T09:59:53Z"}, {"author": "Spencer Dawkins", "text": "

I can HEAR Gorry remotely, but I can imagine that Gorry can't THINK when he hears drilling ...

", "time": "2023-11-09T10:06:05Z"}, {"author": "Jonathan Morton", "text": "

yeah, the drilling is not loud through the mic, but it's probably a lot louder locally

", "time": "2023-11-09T10:06:35Z"}, {"author": "Greg White", "text": "

Madhan Kanagarathinam said:

\n
\n

I hope non-L4S is also as per RFC 8325 :grinning:

\n
\n

Any info on prevalence of RFC8325 in the wild?

", "time": "2023-11-09T10:09:09Z"}, {"author": "Madhan Kanagarathinam", "text": "

The work is yet to be published .. opening up in IEEE Globecom 2-23 .. When I tested top RT gaming apps in Android, everything was AC_BE .. :-( However,, not anymore ..

", "time": "2023-11-09T10:10:43Z"}, {"author": "Madhan Kanagarathinam", "text": "

@GW

", "time": "2023-11-09T10:10:53Z"}, {"author": "Vidhi Goel", "text": "

WiFi UP doesn\u2019t provide any benefit after the first hop. That is not enough end to end. And hence L4S.

", "time": "2023-11-09T10:17:18Z"}, {"author": "Madhan Kanagarathinam", "text": "

Yes, but when we talk about best effort upload and gaming uplink traffic racing, then Wi-Fi UP make the difference .. theoretically and practically ..

", "time": "2023-11-09T10:21:45Z"}, {"author": "Vidhi Goel", "text": "

Agreed

", "time": "2023-11-09T10:23:07Z"}, {"author": "Madhan Kanagarathinam", "text": "

Again my curiosity was if the comparison was

\n

L4S AC_Vi vs non -L4S AC_vi

\n

it should not be L4S AC_Vi vs non-L4S AC_Be (most of RT gaming follow this)

", "time": "2023-11-09T10:26:58Z"}, {"author": "Christian Huitema", "text": "

how do we hum remotely?

", "time": "2023-11-09T10:33:39Z"}, {"author": "Jonathan Morton", "text": "

I think raising hands

", "time": "2023-11-09T10:34:21Z"}]