[{"author": "Lucas Pardue", "text": "

@Victor Vasiliev we had some VC issues on that meeting sorry if you got affected

", "time": "2024-03-19T23:34:34Z"}, {"author": "Ted Hardie", "text": "

What's the downside of being explicit here?

", "time": "2024-03-19T23:39:39Z"}, {"author": "Lucas Pardue", "text": "

its more verbose but beyond that, I don't think there is much downside

", "time": "2024-03-19T23:40:26Z"}, {"author": "Christian Huitema", "text": "

We could test that with a qlog spec for \"siduck\"

", "time": "2024-03-19T23:47:29Z"}, {"author": "Ted Hardie", "text": "

Sorry, the flat white proportion of blood stream is clearly getting dangerously low.

", "time": "2024-03-19T23:48:04Z"}, {"author": "Lucas Pardue", "text": "

Robin and I have volunteerd to reverse engineer moq application logs into a schema. So if folks doing interop on things like the chat app are already logging moq-specific things that would beneift from structured logs, please let us know!

", "time": "2024-03-19T23:49:39Z"}, {"author": "David Schinazi", "text": "

spoilers!

", "time": "2024-03-19T23:49:57Z"}, {"author": "David Schinazi", "text": "

It was already bad enough when Robin let it known that in Oppenheimer the bomb goes off

", "time": "2024-03-19T23:51:03Z"}, {"author": "Ted Hardie", "text": "

I think the chat app he's talking about is the: https://afrind.github.io/draft-frindell-moq-chat/draft-frindell-moq-chat.html#name-introduction

", "time": "2024-03-19T23:51:57Z"}, {"author": "Ted Hardie", "text": "

(But there hasn't been an infusion of flat white, so maybe not)

", "time": "2024-03-19T23:52:16Z"}, {"author": "Martin Thomson", "text": "

An observation: We should not have presentations, but discussions.

", "time": "2024-03-19T23:53:17Z"}, {"author": "Robin Marx", "text": "

@David : be happy I didn't add a reference to the God Emperor

", "time": "2024-03-19T23:53:34Z"}, {"author": "Mike English", "text": "

\ud83e\udeb1

", "time": "2024-03-19T23:53:59Z"}, {"author": "Mathis Engelbart", "text": "

@Lucas: I am logging all the MoQ control stream messages. Structured logs would be useful for that.

", "time": "2024-03-19T23:55:26Z"}, {"author": "Lucas Pardue", "text": "

MT: there were discussion items on qlog slides - just not much engagement :)

", "time": "2024-03-19T23:56:20Z"}, {"author": "Martin Thomson", "text": "

Tommy Pauly: this solves your MASQUE issue

", "time": "2024-03-19T23:56:44Z"}, {"author": "Martin Thomson", "text": "

Lucas: you don't get points for effort, I'm afraid, only results

", "time": "2024-03-19T23:57:19Z"}, {"author": "Mike English", "text": "

Mathis++ early versions of moq-pub did that, too

", "time": "2024-03-19T23:57:23Z"}, {"author": "Lucas Pardue", "text": "

MT: the result I'll take is silence indicates rough consensus. So the editors are unblocked. Next meeting we don't need as much meeting time for sure

", "time": "2024-03-19T23:59:21Z"}, {"author": "Jana Iyengar", "text": "

Does anyone know of deployments of hardware offload for QUIC yet?

", "time": "2024-03-20T00:00:08Z"}, {"author": "Matt Joras", "text": "

There are none.

", "time": "2024-03-20T00:00:22Z"}, {"author": "Matt Joras", "text": "

There will be hardware that can do it probably late this year or early 2025.

", "time": "2024-03-20T00:01:00Z"}, {"author": "Ted Hardie", "text": "

@Jana Not specific to QUIC, but you might be interested in this: https://justinesherry.com/papers/sherry-ccr23.pdf which talks about NIC-DMC in smart NICs.

", "time": "2024-03-20T00:01:40Z"}, {"author": "Matt Joras", "text": "

Also see the work from Broadcom (which we collaborated on): https://lpc.events/event/17/contributions/1592/attachments/1358/2721/LPC2023%20--%20Offloading%20Encryption%20to%20QUIC%20Enabled%20NICs%20v2.pdf

", "time": "2024-03-20T00:03:44Z"}, {"author": "Brian Trammell", "text": "

not going to get into the mic line this late at night / early in the morning local time but +1, this is a good approach to this (and as refined, pretty much what we asked for last meeting)

", "time": "2024-03-20T00:04:14Z"}, {"author": "Ted Hardie", "text": "

@Matt is there a paper coming as well? or a recording of the talk?

", "time": "2024-03-20T00:04:59Z"}, {"author": "Brian Trammell", "text": "

have not read the PR in nitpicky detail but at the level of detail I have, merge it

", "time": "2024-03-20T00:05:19Z"}, {"author": "Matt Joras", "text": "

https://www.youtube.com/watch?v=qDHWHkqaW6U

\n

I think they also had a one pager somewhere, I'll try to find it.

", "time": "2024-03-20T00:05:32Z"}, {"author": "Ted Hardie", "text": "

@matt Thanks!

", "time": "2024-03-20T00:05:46Z"}, {"author": "David Schinazi", "text": "

:ship::right:\ufe0f

", "time": "2024-03-20T00:06:33Z"}, {"author": "Thomas Eizinger", "text": "

Missed opportunity to call it an explicit path forward.

", "time": "2024-03-20T00:07:24Z"}, {"author": "Lucas Pardue", "text": "

@thomas noice

", "time": "2024-03-20T00:07:45Z"}, {"author": "Jana Iyengar", "text": "

Ok, @Christian @Mirja -- @MT reminded me of ack generation issues in particular, and I think that's enough pain to do separate PN spaces per path. I usually think about doing Ack Rate control as well in general, so in my world, I think things will still work. But -- in the general case, there's enough pain that I'll take back my suggestion of using the same PN space across Path IDs.

", "time": "2024-03-20T00:09:36Z"}, {"author": "Martin Thomson", "text": "

Have people looked at Victor's https://datatracker.ietf.org/doc/draft-vvv-quic-namespaces/ ? It strikes me that the trick he is using with the NS frame there might be useful for MP QUIC.

", "time": "2024-03-20T00:10:35Z"}, {"author": "Jana Iyengar", "text": "

Thanks for the pointer, Ted. @Matt: \"There will be hardware\" sounds strongly predictive. I'm curious to know more.

", "time": "2024-03-20T00:10:52Z"}, {"author": "Lucas Pardue", "text": "

MT: would you like to discuss that at the mic?

", "time": "2024-03-20T00:11:00Z"}, {"author": "Ted Hardie", "text": "

If the server can do it at the cost of one RTT by telling the client to do it, then the question seems like whether there are use cases where that RTT is too big a penalty. Do we have evidence of that?

", "time": "2024-03-20T00:13:12Z"}, {"author": "Mike Bishop", "text": "

Doesn't boil this down to peer-to-peer? We certainly know connections like that exist.

", "time": "2024-03-20T00:14:01Z"}, {"author": "Jana Iyengar", "text": "

What's a server-oriented path? Is that just a server-initiated path?

", "time": "2024-03-20T00:14:02Z"}, {"author": "Kazuho Oku", "text": "

On balance +1 to what Christian says

", "time": "2024-03-20T00:14:07Z"}, {"author": "Brian Trammell", "text": "

yep I like Christian's suggestion here

", "time": "2024-03-20T00:14:21Z"}, {"author": "Marten Seemann", "text": "

We need to think about how to negotiate the limit for both directions

", "time": "2024-03-20T00:14:42Z"}, {"author": "Ted Hardie", "text": "

+1 to Christian's suggestion.

", "time": "2024-03-20T00:14:42Z"}, {"author": "Brian Trammell", "text": "

Marten: ISTM limit negotiation is probably not latency sensitive though

", "time": "2024-03-20T00:16:50Z"}, {"author": "Lucas Pardue", "text": "

limit negotiation seems equivalent to extension negotioatn to me

", "time": "2024-03-20T00:17:44Z"}, {"author": "Brian Trammell", "text": "

yep

", "time": "2024-03-20T00:17:52Z"}, {"author": "Quentin De Coninck", "text": "

+1, we could later define such a server-initiated limit as an extension

", "time": "2024-03-20T00:18:23Z"}, {"author": "Marten Seemann", "text": "

you now need to negotiate limits in 2 directions

", "time": "2024-03-20T00:18:24Z"}, {"author": "Lucas Pardue", "text": "

isn't that how most QUIC TPs already work?

", "time": "2024-03-20T00:18:43Z"}, {"author": "Magnus Westerlund", "text": "

I think at a minimum we should do enable future extension with the odd-even split. But I think we can think more about server initiated open and what impact it have.

", "time": "2024-03-20T00:20:26Z"}, {"author": "Ian Swett", "text": "

Paths don't need to be used bidirectionally.

", "time": "2024-03-20T00:21:28Z"}, {"author": "Brian Trammell", "text": "

+1, adding more complexity to the state cleanup seems like a good way to run into more nooks for state exhaustion attacks to hide in

", "time": "2024-03-20T00:22:18Z"}, {"author": "Magnus Westerlund", "text": "

@Ian Swett I think the question of unidirectional paths is one of the interesting ones. And how to validate them.

", "time": "2024-03-20T00:24:06Z"}, {"author": "Ian Swett", "text": "

Path validation in RFC9000 is unidirectional. To be clear, I don't have a pressing use case for unidirectional paths.

", "time": "2024-03-20T00:25:26Z"}, {"author": "Martin Thomson", "text": "

RFC 9000 is unidirectional in a few different ways, including path validation.

", "time": "2024-03-20T00:25:54Z"}, {"author": "Lucas Pardue", "text": "

didn't we decide we didn't watn to go with the uniflows approach to multipath like 4 years ago?

", "time": "2024-03-20T00:26:11Z"}, {"author": "Quentin De Coninck", "text": "

Yeah, I think we already proposed that, but IIRC we mention path validation was actually checking if a path was working in both directions

", "time": "2024-03-20T00:27:02Z"}, {"author": "Brian Trammell", "text": "

yeah but I recall that was part of a general \"let's-defer-this-to-later\"

", "time": "2024-03-20T00:27:10Z"}, {"author": "Martin Thomson", "text": "

Quentin: but it only provides any assurance about path functioning to one endpoint

", "time": "2024-03-20T00:27:43Z"}, {"author": "Brian Trammell", "text": "

the reality is that all paths are unidirectional but the model any two-endpoints protocol can interact with the paths as if they are bidirectional

", "time": "2024-03-20T00:27:59Z"}, {"author": "Magnus Westerlund", "text": "

So to get uni path working would mean that one should clarify that one MAY send the path valid frame on any path.

", "time": "2024-03-20T00:28:03Z"}, {"author": "Brian Trammell", "text": "

it's about the shape of the state at each endpoint

", "time": "2024-03-20T00:28:06Z"}, {"author": "Brian Trammell", "text": "

kind of like i know my coffee is made of quarks but that doesn't really affect my enjoyment of it.

", "time": "2024-03-20T00:28:46Z"}, {"author": "Lucas Pardue", "text": "

brian, I hear particle charges can cause clumping affecting extraction

", "time": "2024-03-20T00:29:22Z"}, {"author": "Brian Trammell", "text": "

:clap:

", "time": "2024-03-20T00:30:52Z"}, {"author": "Fran\u00e7ois Michel", "text": "

one whole hour of \"as-time-permits\" !

", "time": "2024-03-20T00:31:40Z"}, {"author": "David Schinazi", "text": "

Is it me or does our schedule not match the posted agenda at all? asking for a confused note taker

", "time": "2024-03-20T00:32:35Z"}, {"author": "Brian Trammell", "text": "

one hour of as time permits --> when do we rename this group to QUICME?

", "time": "2024-03-20T00:32:57Z"}, {"author": "Matt Joras", "text": "

there was a large amount of last minute agenda bashing. Though it goes beyond bashing and more into rewriting if we are being honest

", "time": "2024-03-20T00:33:04Z"}, {"author": "Lucas Pardue", "text": "

https://datatracker.ietf.org/meeting/119/materials/agenda-119-quic-02

", "time": "2024-03-20T00:33:17Z"}, {"author": "Brian Trammell", "text": "

currently the posted agenda seems synced to me

", "time": "2024-03-20T00:33:26Z"}, {"author": "Lucas Pardue", "text": "

maybe hedgedoc didn't slurp it up david?

", "time": "2024-03-20T00:33:41Z"}, {"author": "Brian Trammell", "text": "

(does hedgedoc autopopulate the agenda? I haven't noticed that in other meetings I'm scribing for)

", "time": "2024-03-20T00:34:10Z"}, {"author": "Lucas Pardue", "text": "

I could be way off

", "time": "2024-03-20T00:34:59Z"}, {"author": "David Schinazi", "text": "

oh I was pulling the agenda from the main agenda and that doesn't refresh? so I got an older version

", "time": "2024-03-20T00:35:39Z"}, {"author": "David Schinazi", "text": "

Thx

", "time": "2024-03-20T00:35:41Z"}, {"author": "Lucas Pardue", "text": "

sorry for your pain

", "time": "2024-03-20T00:35:59Z"}, {"author": "Mike Bishop", "text": "

Marten with the \"I told you so\" slide. :-)

", "time": "2024-03-20T00:38:35Z"}, {"author": "Jonathan Lennox", "text": "

Qui

", "time": "2024-03-20T00:40:55Z"}, {"author": "Jonathan Lennox", "text": "

Quicv3

", "time": "2024-03-20T00:41:03Z"}, {"author": "Mike Bishop", "text": "

Well, you can drop them, which is the point.

", "time": "2024-03-20T00:42:53Z"}, {"author": "David Schinazi", "text": "

re: the agenda issue I filed https://github.com/ietf-tools/datatracker/issues/7238

", "time": "2024-03-20T00:43:10Z"}, {"author": "David Schinazi", "text": "

https://github.com/quicwg/base-drafts/pull/3509

", "time": "2024-03-20T00:45:05Z"}, {"author": "Martin Thomson", "text": "

Do we have issues opened on the base-drafts repo for these? Because fixing this later is probably sensible.

", "time": "2024-03-20T00:46:40Z"}, {"author": "Christian Huitema", "text": "

That's not what the errata process is about. If we want to fix security issues in 9000, we need a new RFC that updates 9000.

", "time": "2024-03-20T00:47:22Z"}, {"author": "Lucas Pardue", "text": "

There should be (and a written process for collecting any/all issues on QUIC specs)

", "time": "2024-03-20T00:47:24Z"}, {"author": "Matt Joras", "text": "

Yes, we are open to discussing how to have a process to do just that, and how to manage those issues long term.

", "time": "2024-03-20T00:47:39Z"}, {"author": "Jonathan Lennox", "text": "

bis, ter, quater

", "time": "2024-03-20T00:47:43Z"}, {"author": "Martin Thomson", "text": "

The process for collecting issues is opening them on the repo, I'd say.

", "time": "2024-03-20T00:47:48Z"}, {"author": "Jonathan Lennox", "text": "

But I think this would be an \u201cUpdates: 9000\u201d

", "time": "2024-03-20T00:48:18Z"}, {"author": "Matt Joras", "text": "

Indeed, it's more about what to do with the issues once they are open, i.e. \"fixing this later\"

", "time": "2024-03-20T00:48:39Z"}, {"author": "Christian Huitema", "text": "

Bis would be producing QUIc v2. I am more thinking about something like \"Protecting against congestion control attack in QUIC\", as short RFC that updates 9000.

", "time": "2024-03-20T00:48:50Z"}, {"author": "Lucas Pardue", "text": "

MT: yeah it can be light touch. We just want it to be discoverable and clear

", "time": "2024-03-20T00:48:51Z"}, {"author": "Brian Trammell", "text": "

+1 to Christian

", "time": "2024-03-20T00:49:05Z"}, {"author": "Lucas Pardue", "text": "

we already have QUIC v2

", "time": "2024-03-20T00:49:22Z"}, {"author": "Brian Trammell", "text": "

fixes to this pattern belong in errata now and an Updates:9000 later

", "time": "2024-03-20T00:49:29Z"}, {"author": "Ian Swett", "text": "

That issue with unlimited control frames was discovered \"experimentally\" early on.

", "time": "2024-03-20T00:49:46Z"}, {"author": "Brian Trammell", "text": "

reality is implementations (at least those connected to this community, seeing this talk, and reading the various blog posts on the issue) will already defend against this, we just need to go fix the spec retroactively to make those fixes compliant.

", "time": "2024-03-20T00:50:14Z"}, {"author": "Jonathan Lennox", "text": "

Errata is supposed to be for cases where the document doesn\u2019t accurately reflect IETF consensus at the time of publication. New consensus should be a new RFC that updates the old one.

", "time": "2024-03-20T00:51:19Z"}, {"author": "Brian Trammell", "text": "

(sorry for hanging out in chat the whole time, one disadvantage of being remote is that when i'm loud at the mic in person, I don't wake up the family)

", "time": "2024-03-20T00:52:01Z"}, {"author": "David Schinazi", "text": "

We actually have 3 ways to send HTTP datagrams but who's counting

", "time": "2024-03-20T00:52:03Z"}, {"author": "Jana Iyengar", "text": "

I agree with @martinduke -- this isn't an issue with RFC 9000 (Sec 5.1.2), so I don't think this is errata: \"An endpoint SHOULD limit the number of connection IDs it has retired locally for which RETIRE_CONNECTION_ID frames have not yet been acknowledged. An endpoint SHOULD allow for sending and tracking a number of RETIRE_CONNECTION_ID frames of at least twice the value of the active_connection_id_limit transport parameter.\"

", "time": "2024-03-20T00:52:06Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

David Schinazi said:

\n
\n

We actually have 3 ways to send HTTP datagrams but who's counting

\n
\n

What's an off by one error between friends?

", "time": "2024-03-20T00:52:42Z"}, {"author": "Peter Thatcher", "text": "

Just build on top of WebTransport for everything from here on out :)

", "time": "2024-03-20T00:52:43Z"}, {"author": "Christian Huitema", "text": "

See the discussion of Slowloris, which effectively allows nodes to close connections if the peer slows down too much. Defences against those attacks are already compliant.

", "time": "2024-03-20T00:53:00Z"}, {"author": "Brian Trammell", "text": "

FWIW my suggestion for an erratum here is a matter of speed

", "time": "2024-03-20T00:53:09Z"}, {"author": "Brian Trammell", "text": "

if we could agree that an Updates: RFC is in charter and get it to WGLC before Vancouver, that would be effective.

", "time": "2024-03-20T00:53:46Z"}, {"author": "Jana Iyengar", "text": "

What would the erratum be?

", "time": "2024-03-20T00:54:09Z"}, {"author": "Lucas Pardue", "text": "

updates are already in charter as far as I'm concerned.

", "time": "2024-03-20T00:54:30Z"}, {"author": "Lucas Pardue", "text": "

but of course we can verify that

", "time": "2024-03-20T00:54:41Z"}, {"author": "Martin Thomson", "text": "

assertions about record/frame/packet size and performance are dubious, the answer is always \"it depends\"

", "time": "2024-03-20T00:55:46Z"}, {"author": "Martin Thomson", "text": "

I want to say that this discussion belongs in this WG, not HTTPbis.

", "time": "2024-03-20T00:56:21Z"}, {"author": "Martin Thomson", "text": "

But the queue is insane.

", "time": "2024-03-20T00:56:28Z"}, {"author": "Brian Trammell", "text": "

jana: content erratum noting that the retirement mechanism in 9000 has a known vuln, reference to the published work explaning it.

", "time": "2024-03-20T00:56:28Z"}, {"author": "Brian Trammell", "text": "

although now that the caffiene-shaped quarks are kicking in that's not what errata are for

", "time": "2024-03-20T00:56:50Z"}, {"author": "Brian Trammell", "text": "

so fast update rfc plz

", "time": "2024-03-20T00:56:56Z"}, {"author": "Martin Thomson", "text": "

This is not just QUIC on TCP, but QUIC on HTTP, or QUIC over another type of tunnel.

", "time": "2024-03-20T00:57:07Z"}, {"author": "Brian Trammell", "text": "

if i can somehow be helpful in \"fast update rfc plz\" consider this to be me volunteering.

", "time": "2024-03-20T00:58:09Z"}, {"author": "Brian Trammell", "text": "

...DNS over QUIC over TCP over IP over DNS over UDP...

", "time": "2024-03-20T00:58:42Z"}, {"author": "Jana Iyengar", "text": "

I wonder if this really should be HTTP/3 over TCP

", "time": "2024-03-20T00:59:40Z"}, {"author": "Alan Frindell", "text": "

To David's point - there will be new application protocols over QUIC (eg: moq) and having a uniform way to do fallback is appealing.
\nAlso, there's not a generic multiplexing protocol over TCP yet, and this can fill that need.

", "time": "2024-03-20T00:59:48Z"}, {"author": "Mike Bishop", "text": "

There is WebTransport for HTTP/2, FWIW. And I think WebTransport over H2 does already give you a QUIC-like API surface over TCP.

", "time": "2024-03-20T01:00:04Z"}, {"author": "Martin Thomson", "text": "

I want to hear someone present an argument that is grounded in principles like the HTML priority of constituencies

", "time": "2024-03-20T01:00:06Z"}, {"author": "Brian Trammell", "text": "

\"run all the things over all the things\" is good for memes, less universally good for protocol deployment dynamics.

", "time": "2024-03-20T01:00:47Z"}, {"author": "Peter Thatcher", "text": "

Can we have \"QUIC over TCP\" built into OS kernels and get them to deliver TCP out of order, and thus get around TCP head-of-line blocking?

", "time": "2024-03-20T01:01:14Z"}, {"author": "Lucas Pardue", "text": "

that is out of scope for this proposal Peter

", "time": "2024-03-20T01:01:34Z"}, {"author": "Lucas Pardue", "text": "

but a suitable question to ask more broadly

", "time": "2024-03-20T01:01:51Z"}, {"author": "Matt Joras", "text": "

Personally I don't really buy the fact that this would harm the adoption of QUIC.

\n

What is the situation where this makes a QUIC transition less likely? If the app over QUIC over TCP version is worse than the raw QUIC version, why would they want to stay on the TCP version?

", "time": "2024-03-20T01:02:00Z"}, {"author": "Peter Thatcher", "text": "

Sure, but it would be an very large potential benefit

", "time": "2024-03-20T01:02:05Z"}, {"author": "Brian Trammell", "text": "

OOO TCP delivery is one of those subservices that breaks for the reasons we decided to move to QUIC.

", "time": "2024-03-20T01:02:14Z"}, {"author": "Stephen McQuistin", "text": "

\"QUIC over TCP Minion\"

", "time": "2024-03-20T01:02:23Z"}, {"author": "Brian Trammell", "text": "

but yes might be a useful tool in the toolbox not universally

", "time": "2024-03-20T01:02:28Z"}, {"author": "Lucas Pardue", "text": "

I am personally very pessimisitc about the deployment reality of changing TCP

", "time": "2024-03-20T01:02:43Z"}, {"author": "Brian Trammell", "text": "

i am probably even more pessimistic than lucas is

", "time": "2024-03-20T01:03:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

I feel weird about this proposal. On one hand side, it would be quite nice because it allows us to build things on top of QUIC without worrying about TCP fallbacks, and without also forcing it onto HTTP. But on the other hand side, +1 to dschinazi about this not helping the adoption of quic.

", "time": "2024-03-20T01:03:13Z"}, {"author": "Matt Joras", "text": "

can you clarify the point about adoption issues?

", "time": "2024-03-20T01:03:29Z"}, {"author": "Alan Frindell", "text": "

+1 marten

", "time": "2024-03-20T01:03:33Z"}, {"author": "Brian Trammell", "text": "

I think the prospect of not having to think about TCP fallback is a very, very attractive feature that will be very, very hard to deliver on the wire as the wire currently exist.

", "time": "2024-03-20T01:04:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Why do we do it? Because we can!

", "time": "2024-03-20T01:04:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

If you can fall back to TCP without users being sad (true today for HTTP1/2/3) then network operators have less incentive to make a UDP/QUIC-clean path.

", "time": "2024-03-20T01:04:31Z"}, {"author": "Brian Trammell", "text": "

building-the-quic-contract on non-quic protocols is what stuff like TAPS is for. :)

", "time": "2024-03-20T01:04:48Z"}, {"author": "Mike Bishop", "text": "

This goes to a comment in the side-meeting that networks which block UDP also block TLS 1.2.

", "time": "2024-03-20T01:04:49Z"}, {"author": "Mike Bishop", "text": "

*1.3

", "time": "2024-03-20T01:04:54Z"}, {"author": "Alex Chernyakhovsky", "text": "

I have seen networks that block UDP but not TLS1.3

", "time": "2024-03-20T01:05:10Z"}, {"author": "Matt Joras", "text": "

I don't follow. They are already getting a worse experience by blocking QUIC, and they don't care. Doing QUIC on TCP which they wouldn't even notice is happening changes nothing about the incentives.

", "time": "2024-03-20T01:05:13Z"}, {"author": "Alex Chernyakhovsky", "text": "

Right. It doesn't help the situation. Which can be argued by some that since it doesn't help, it hurts.

", "time": "2024-03-20T01:05:45Z"}, {"author": "David Schinazi", "text": "

middleboxes look at the cleartext filed in the TLS client hello

", "time": "2024-03-20T01:06:08Z"}, {"author": "David Schinazi", "text": "

fields*

", "time": "2024-03-20T01:06:15Z"}, {"author": "Matt Joras", "text": "

If it makes implementer and protocol designer's lives easier and doesn't _help_ QUIC adoption, we shouldn't do it?

", "time": "2024-03-20T01:06:18Z"}, {"author": "Fran\u00e7ois Michel", "text": "

For new apps, running them over WebTransport kind of addresses the issue. But I can understand the argument behind having a single HTTP version instead of debugging and maintining two versions (the H2 rapid resets not present in H3 is a good example)

", "time": "2024-03-20T01:06:23Z"}, {"author": "Alan Frindell", "text": "

re: use H2 WebTransport or Websocket: Why is this HTTP's problem ?

", "time": "2024-03-20T01:06:27Z"}, {"author": "Brian Trammell", "text": "

I don't think the \"let's adapt to network brokenness and hope we can get through\" is a fruitful strategy in the long run. better to leave broken networks behind.

", "time": "2024-03-20T01:06:40Z"}, {"author": "Ian Swett", "text": "

Dropping HTTP/2 support is one way to fix Rapid Reset.

", "time": "2024-03-20T01:06:42Z"}, {"author": "David Schinazi", "text": "

middleboxes don't know if it's WT vs h2

", "time": "2024-03-20T01:06:43Z"}, {"author": "Lucas Pardue", "text": "

+1 ian

", "time": "2024-03-20T01:06:55Z"}, {"author": "Brian Trammell", "text": "

+1 md 927 ref

", "time": "2024-03-20T01:07:02Z"}, {"author": "Alan Frindell", "text": "

Droping HTTP.1.1 will also solve a bunch of security problems

", "time": "2024-03-20T01:07:13Z"}, {"author": "Brian Trammell", "text": "

as will dropping TCP universally

", "time": "2024-03-20T01:07:24Z"}, {"author": "Brian Trammell", "text": "

where do you draw the line?

", "time": "2024-03-20T01:07:32Z"}, {"author": "Lucas Pardue", "text": "

just turn it all off

", "time": "2024-03-20T01:07:45Z"}, {"author": "Peter Thatcher", "text": "

Might as well turn off IPv4

", "time": "2024-03-20T01:07:50Z"}, {"author": "Christian Huitema", "text": "

If I was trying something like that, I would definitely try to run through the local HTTP proxy...

", "time": "2024-03-20T01:07:56Z"}, {"author": "Brian Trammell", "text": "

wooo final victory for sre :)

", "time": "2024-03-20T01:08:04Z"}, {"author": "Eric Kinnear", "text": "

+1 Ted, that\u2019s one of the fundamental things WebTransport is doing (regardless of how you feel about running that over HTTP)

", "time": "2024-03-20T01:08:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

I guess another question here is should we backport the fixes from h3 to h2(.1)?

", "time": "2024-03-20T01:08:43Z"}, {"author": "Brian Trammell", "text": "

+1 ted

", "time": "2024-03-20T01:08:45Z"}, {"author": "Matt Joras", "text": "

If we didn't have HTTP/2, we don't have to backport anything ;)

", "time": "2024-03-20T01:09:01Z"}, {"author": "Jana Iyengar", "text": "
    \n
  1. I don't think this changes the dynamics adoption of QUIC. To Eric Kinnear's point earlier, I don't think we should have the illusion that we can reduce the number of networks that don't support UDP by holding back on anything.
    2. \n
  2. The slippery slope argument of turtles-on-turtles is not a compelling one... I've been hearing that argument for 25 years, and we still seem to deploy things on top of things just fine. Layering is a state of mind, artifacts however routinely optimize common paths through layers.
    3. \n
  3. Performance being poor IS the argument for endpoints not wanting to use QUIC on TCP. But it's a fallback anyway where function is more important than performance.
    4. \n
\n

Overall, I am supportive of this. Primarily we already have the plethora of things to support because we split HTTP/2 and 3 based on underlying transport, since the assumptions of the transport service are different. This proposal seems to provide a unified surface above the transport (QUIC) where the services offered below are different (UDP/TCP). Unifying this is useful. This isn't going to be simply (as Ted noted), but the complexity might be worth it.

", "time": "2024-03-20T01:09:03Z"}, {"author": "Matt Joras", "text": "

+1 jana

", "time": "2024-03-20T01:09:33Z"}, {"author": "Matt Joras", "text": "

I don't think we should get bogged down on the QUIC adoption spectre. As someone that deals with UDP blocking and still managed to get to 86% QUIC, if we magically changed H2 over to H3 on streams, nothing would meaningfully change

", "time": "2024-03-20T01:10:37Z"}, {"author": "Brian Trammell", "text": "

well put Jana. I'm not sure about the dynamics of QUIC/UDP adoption in a world with QUIC/TCP -- but I think the complexity point Ted makes is scarier than we think it is though

", "time": "2024-03-20T01:11:27Z"}, {"author": "David Benjamin", "text": "

I'm not sure the WebSockets parable is particularly applicable. We mostly solved the WebSockets problem by moving everything to HTTPS and no longer caring.

", "time": "2024-03-20T01:11:35Z"}, {"author": "Alan Frindell", "text": "

I think there's value in this draft in environments where QUIC doesn't make sense (eg: intra dc RPC)

", "time": "2024-03-20T01:11:53Z"}, {"author": "Yaroslav Rosomakho", "text": "

~10 years ago WebSockets were blocked inside HTTPS by most proxies/firewalls that inspect HTTPS.

", "time": "2024-03-20T01:12:11Z"}, {"author": "Ian Swett", "text": "

Localhost sockets

", "time": "2024-03-20T01:12:18Z"}, {"author": "Ted Hardie", "text": "

@Jana I think the complexity could be managed for HTTP use cases, but I think for other uses of QUIC you can't manage it well enough for the application to succeed (MoQ being the poster child at the moment).

", "time": "2024-03-20T01:12:19Z"}, {"author": "Brian Trammell", "text": "

what ted said

", "time": "2024-03-20T01:12:34Z"}, {"author": "Brian Trammell", "text": "

i do think we should keep talking about this though

", "time": "2024-03-20T01:13:02Z"}, {"author": "Brian Trammell", "text": "

in general the \"let's build the quic service model / contract over other things\" would go a long way to getting the API where it needed to be a decade ago already

", "time": "2024-03-20T01:13:41Z"}, {"author": "Jana Iyengar", "text": "

@Ted: If performance is poor enough, you don't use the fallback. That's an application decision. QUIC impls can expose that they are connecting over UDP or TCP, and the app can decide.

", "time": "2024-03-20T01:13:42Z"}, {"author": "David Benjamin", "text": "

Yaroslav Rosomakho said:

\n
\n

~10 years ago WebSockets were blocked inside HTTPS by most proxies/firewalls that inspect HTTPS.

\n
\n

HTTPS-terminating middleboxes is a much, much smaller scope than. QUIC woes are going to be all middleboxes, and I don't think we've ever gotten through those. I doubt cleartext WebSockets works today.

", "time": "2024-03-20T01:13:53Z"}, {"author": "Brian Trammell", "text": "

...i'ma say \"taps\" again and look in david's general direction now...

", "time": "2024-03-20T01:14:14Z"}, {"author": "Victor Vasiliev", "text": "

I have previously proposed that if we ever run HTTP/3 over \"WebTransport over HTTP/1\" to substitute HTTP/2, we should call it \"HTTP averaging\"

", "time": "2024-03-20T01:14:27Z"}, {"author": "Jana Iyengar", "text": "

@Victor: lol

", "time": "2024-03-20T01:14:45Z"}, {"author": "Martin Thomson", "text": "

Gorry is sad that the RTT is long. That is what I experience every day. The shoe is on the other foot now.

", "time": "2024-03-20T01:15:04Z"}, {"author": "Zaheduzzaman Sarker", "text": "

Let me share a real-life experience. My corporate network was blocking QUIC traffic for a well used application for communication. Obviously that made some managements and colleague unhappy. It then came to me to explain QUIC and ask what to do. My simple solution was to unblock QUIC traffic. That is now happened . So I am supportive of building useful application over QUIC and argue the network allow should allow for better service.

", "time": "2024-03-20T01:15:25Z"}, {"author": "Jana Iyengar", "text": "

Make Australia Closer Again

", "time": "2024-03-20T01:15:33Z"}, {"author": "Ted Hardie", "text": "

@Jana I think making that call on a per-session performance basis doesn't help the implementation complexity, which I thought was one of the motivations here.

", "time": "2024-03-20T01:15:39Z"}, {"author": "Matt Joras", "text": "

@zahed you can continue to do that even if QUIC on streams exists, because anything on QUIC on streams is going to be worse than native QUIC

", "time": "2024-03-20T01:16:01Z"}, {"author": "Brian Trammell", "text": "

making australia closer is a very attractive proposition, however the complexity of the implementation comes with a lot of probably undesirable side-effects.

", "time": "2024-03-20T01:16:35Z"}, {"author": "Matt Joras", "text": "

I view QUIC on streams as something mostly useful for implementers, not for marketing of QUIC. It doesn't need to be marketed at all :wink:

", "time": "2024-03-20T01:16:44Z"}, {"author": "Brian Trammell", "text": "

matt -> that's a good point

", "time": "2024-03-20T01:17:12Z"}, {"author": "Zaheduzzaman Sarker", "text": "

@matt, I don't thing it would have come to me if quic on streams was used. They block UDP traffic as a general enterprise policy not TCP.

", "time": "2024-03-20T01:17:13Z"}, {"author": "David Schinazi", "text": "

You could run fiber through the Earth's core?

", "time": "2024-03-20T01:17:35Z"}, {"author": "Jana Iyengar", "text": "

@Ted: I meant that as a design time decision for an application. Perhaps it can be done differently, where an app tells the QUIC stack to never use the TCP fallback... but this is API. My point is that an application (say MOQ) can choose to not use the TCP fall back in QUIC. My expectation is that if it's available, most will use it under some cases.

", "time": "2024-03-20T01:17:37Z"}, {"author": "Martin Thomson", "text": "

if QoS does nothing to accelerate the retirement of HTTP/2, all it does is increase pain, not reduce it

", "time": "2024-03-20T01:17:37Z"}, {"author": "Jonathan Lennox", "text": "

They moved Australia to Europe for Eurovision, they should have left it there.

", "time": "2024-03-20T01:17:56Z"}, {"author": "Martin Thomson", "text": "

Jonathan: the Australian entry to Eurovision wasn't that good, was it?

", "time": "2024-03-20T01:18:25Z"}, {"author": "Ted Hardie", "text": "

@Matt I'm more worried that network managers will continue to block QUIC over UDP in order to get access to the TCP path layer. They won't care about the performance to this level of detail (if it still works, they don't get tickets, they get grumbling). But this is tea-leaf reading on my part; I have no data to support that.

", "time": "2024-03-20T01:18:25Z"}, {"author": "Zaheduzzaman Sarker", "text": "

I understand quic on streams will have perhaps have undesirable side effects and that is why it should be understood better.

", "time": "2024-03-20T01:18:50Z"}, {"author": "Lucas Pardue", "text": "

is getting data something people thing is realistic? i.e. is there / are ther esurveys out there? (looking at Brian etc)

", "time": "2024-03-20T01:19:07Z"}, {"author": "Jonathan Lennox", "text": "

Martin: that\u2019s why they need to keep trying

", "time": "2024-03-20T01:19:10Z"}, {"author": "Jana Iyengar", "text": "

We have to stop waiting for the entire Internet to support UDP. I'll be bold and make a prediction: It's not happening in my lifetime. The question is not whether we can reduce the number of networks that don't support UDP -- that will hopefully go down. But hope is not a plan, and I like to plan for what's likely -- that UDP will be blocked in various corners of the Internet for eternity.

", "time": "2024-03-20T01:19:15Z"}, {"author": "Matt Joras", "text": "

@Ted understood, but I don't understand how having QUIC on streams makes them _more likely_ to keep UDP blocked. Because they can pat themselves on the back because it's \"using QUIC\"?

\n

I don't buy it.

", "time": "2024-03-20T01:19:24Z"}, {"author": "Matt Joras", "text": "

From my view it changes nothing in their decision calculus compared to today.

", "time": "2024-03-20T01:19:50Z"}, {"author": "Zaheduzzaman Sarker", "text": "

and we are kind of used to getting artifacts due to TCP.. users will accept the issues unless we can show then what they can get better by running application over quic.

", "time": "2024-03-20T01:20:34Z"}, {"author": "Brian Trammell", "text": "

@lucas it seems like deployability and adoption are less interesting topics for academia now, you should probably ask people closer to the operation of the large networks and fleets of end devices for the taxonomy of the ways this would break

", "time": "2024-03-20T01:20:35Z"}, {"author": "Eric Kinnear", "text": "

Eh, isn't this the same argument we have about ways to keep v4 apps working vs. requiring v6 \"for real\" -- by removing some of the pain, we also remove the motivation that causes change

", "time": "2024-03-20T01:20:46Z"}, {"author": "Lucas Pardue", "text": "

ack

", "time": "2024-03-20T01:20:58Z"}, {"author": "Martin Thomson", "text": "

a disable_careful_resume transport parameter might be ok

", "time": "2024-03-20T01:21:02Z"}, {"author": "Brian Trammell", "text": "

(my university lecture on QUIC mainly uses 2019 deployment data, with one additional data point I got from Ian about Youtube's QUIC proportion in '23)

", "time": "2024-03-20T01:21:17Z"}, {"author": "Jana Iyengar", "text": "

There are plenty of folks blocking QUIC without realizing they're doing it. We have no control over this process. We can only adapt to it.

", "time": "2024-03-20T01:21:20Z"}, {"author": "Alan Frindell", "text": "

at least for HTTP, the tcp fallback has been baked in from the beginning. We don't expect quic on streams to make the tcp fallback any better.
\nThe pain we are removing are from ourselves (protocol designers and implementers).

", "time": "2024-03-20T01:21:25Z"}, {"author": "Christian Huitema", "text": "

+1 Marten

", "time": "2024-03-20T01:21:28Z"}, {"author": "Brian Trammell", "text": "

-> the data on quic blockage probably falls out of the logs of large CDN frontends as a side effect

", "time": "2024-03-20T01:21:54Z"}, {"author": "Ted Hardie", "text": "

@Matt If they don't get tickets sayings \"X doesn't work\", the motiviation to change goes down.

", "time": "2024-03-20T01:22:17Z"}, {"author": "Zaheduzzaman Sarker", "text": "

+1

", "time": "2024-03-20T01:22:29Z"}, {"author": "Matt Joras", "text": "

But the applications work today!

", "time": "2024-03-20T01:22:34Z"}, {"author": "Jana Iyengar", "text": "

@Eric: I was waiting for someone to raise v6 incentives... if there's one lesson there, it is that we didn't and don't understand incentives well.

", "time": "2024-03-20T01:22:39Z"}, {"author": "Matt Joras", "text": "

So nothing changes.

", "time": "2024-03-20T01:22:47Z"}, {"author": "Lucas Pardue", "text": "

can I petition browser engineers to enable Network Error Loggin with better accuracy and granulairy? Then I might get a better idea of how QUCI traffic to my CDN is blocked or not

", "time": "2024-03-20T01:22:50Z"}, {"author": "Brian Trammell", "text": "

\"just SCONE. it's simpler.\"

", "time": "2024-03-20T01:23:09Z"}, {"author": "Alan Frindell", "text": "

scone-protocl

", "time": "2024-03-20T01:23:38Z"}, {"author": "Marten Seemann", "text": "

Are you using SCONE Home Edition or SCONE Pro Edition?

", "time": "2024-03-20T01:23:51Z"}, {"author": "Alan Frindell", "text": "

You don't want amateur scones

", "time": "2024-03-20T01:24:14Z"}, {"author": "Ted Hardie", "text": "

NOT PLUS, WE SWEAR?

", "time": "2024-03-20T01:24:24Z"}, {"author": "Zaheduzzaman Sarker", "text": "

As I said.. for me it is very important that we understand the impact quic on streams will have on QUIC adoption.. I am happy with the discussion so far, even if , it is not conclusive. Please continue the discussion. thanks

", "time": "2024-03-20T01:24:42Z"}, {"author": "Jana Iyengar", "text": "

There's your tagline

", "time": "2024-03-20T01:24:44Z"}, {"author": "Martin Thomson", "text": "

I think that SCONEPRO makes a very strong case for revoking any ability that Matt has to mint acronyms.

", "time": "2024-03-20T01:24:52Z"}, {"author": "Jonathan Lennox", "text": "

But is it scohne or scawne?

", "time": "2024-03-20T01:25:04Z"}, {"author": "Jana Iyengar", "text": "

+1 Martin

", "time": "2024-03-20T01:25:04Z"}, {"author": "Matt Joras", "text": "

It gets engagement so it does its job people

", "time": "2024-03-20T01:25:09Z"}, {"author": "Matt Joras", "text": "

It's like you guys haven't heard of clickbait

", "time": "2024-03-20T01:25:19Z"}, {"author": "Jana Iyengar", "text": "

SADCDN and SCONEPRO are two strikes

", "time": "2024-03-20T01:25:26Z"}, {"author": "Ted Hardie", "text": "

@Matt SAD CDN did too, yet here we are....

", "time": "2024-03-20T01:25:28Z"}, {"author": "Martin Thomson", "text": "

Don't try to claim that it's trolling.

", "time": "2024-03-20T01:25:34Z"}, {"author": "Ian Swett", "text": "

It's good when everyone coming into the BoF already has consensus on something.

", "time": "2024-03-20T01:25:37Z"}, {"author": "Brian Trammell", "text": "

ENRAGE the IETF with this ONE WEIRD TRICK

", "time": "2024-03-20T01:25:39Z"}, {"author": "Jana Iyengar", "text": "

We live in acronyms. It's only fair.

", "time": "2024-03-20T01:26:05Z"}, {"author": "Martin Thomson", "text": "

Brian: that was gold

", "time": "2024-03-20T01:26:07Z"}, {"author": "Brian Trammell", "text": "

coffee's kicking in now :)

", "time": "2024-03-20T01:26:25Z"}, {"author": "Martin Thomson", "text": "

The thing is, I'm not mad, I'm just disappointed.

", "time": "2024-03-20T01:26:34Z"}, {"author": "Jana Iyengar", "text": "

That's cruel Martin. Matt doesn't deserve that.

", "time": "2024-03-20T01:27:06Z"}, {"author": "Jana Iyengar", "text": "

/rename-chat bad-attitude

", "time": "2024-03-20T01:27:31Z"}, {"author": "Martin Thomson", "text": "

Oh, I don't know. If those acronyms were deliberate, he totally deserves it.

", "time": "2024-03-20T01:27:36Z"}, {"author": "Matt Joras", "text": "

SADCDN was 100% deliberately meant to be clickbait.

", "time": "2024-03-20T01:28:40Z"}, {"author": "Jana Iyengar", "text": "

... and I've got people at my place reaching out to whom I have to explain repeatedly why it's not a ding on CDNs

", "time": "2024-03-20T01:29:11Z"}, {"author": "Brian Trammell", "text": "

back to the fallback discussion -- TCP fallback is basically happy-eyeballs. It reduces availability risk at the cost of lowering the adoption ceiling

", "time": "2024-03-20T01:29:39Z"}, {"author": "Martin Thomson", "text": "

Can someone explain why this doesn't use AI, like the new MLCODEC stuff.

", "time": "2024-03-20T01:29:48Z"}, {"author": "Brian Trammell", "text": "

so the more effective your fallback is, the larger the set of networks you get that will never adapt to the new endpoint behavior

", "time": "2024-03-20T01:30:21Z"}, {"author": "Brian Trammell", "text": "

(last time I measured, which was... a long time ago... happy-eyeballs was happily hiding the fact that like 10% of the webservers on the IPv6 Internet were horribly, horribly broken)

", "time": "2024-03-20T01:31:04Z"}, {"author": "Matt Joras", "text": "

@Jana, but at least you _got questions_ about it, which was the point

", "time": "2024-03-20T01:31:18Z"}, {"author": "Jana Iyengar", "text": "

Brian: that logic is broken. It assumes that networks respond to broken endpoints. Networks take a LONG time to adapt. Much longer than the application developer... and users don't care for broken applications.

", "time": "2024-03-20T01:31:22Z"}, {"author": "Martin Thomson", "text": "

so the lesson is: increase the buffer

", "time": "2024-03-20T01:31:24Z"}, {"author": "Brian Trammell", "text": "

I'll note here that there was a Very Well Known cable provider that broke ECN for six years

", "time": "2024-03-20T01:32:02Z"}, {"author": "Gorry Fairhurst", "text": "

It interesting that the Starlink system changes this week have shown significant RTT reductions... part of the problem with FEC is that happens at multiple levels!

", "time": "2024-03-20T01:32:11Z"}, {"author": "Ingemar Johansson", "text": "

Does anybody remember why FEC was dropped
\nIt was there in early QUIC implementations?. I guess FEC does not work that well for burst losses, in which case also interleaving is needed.?

", "time": "2024-03-20T01:32:20Z"}, {"author": "Brian Trammell", "text": "

until two weeks after a major vendor pushed ECN negotiation support

", "time": "2024-03-20T01:32:20Z"}, {"author": "Brian Trammell", "text": "

:D

", "time": "2024-03-20T01:32:21Z"}, {"author": "Fran\u00e7ois Michel", "text": "

Thanks for the slot !

", "time": "2024-03-20T01:32:39Z"}, {"author": "Brian Trammell", "text": "

\\o see y'all in the totally-not-+++ bof tomorrow

", "time": "2024-03-20T01:32:45Z"}, {"author": "Fran\u00e7ois Michel", "text": "

Ingemar: I think it was because it was providing bad results and the extension was too complex for that time while QUIC whas still being standardized

", "time": "2024-03-20T01:33:15Z"}, {"author": "Jana Iyengar", "text": "

The incentives are always for the app developer to build an app that works well. You are not going to find a successful app that remains broken waiting for the network to be fixed.

", "time": "2024-03-20T01:33:19Z"}, {"author": "Gorry Fairhurst", "text": "

... unless you're doing CC work, then see you in ICCRG?

", "time": "2024-03-20T01:33:26Z"}, {"author": "Harald Alvestrand", "text": "

Has QIRL been brought to AVTCORE?

", "time": "2024-03-20T01:33:52Z"}, {"author": "Fran\u00e7ois Michel", "text": "

Nope not yet

", "time": "2024-03-20T01:34:20Z"}]