[{"author": "Mike Bishop", "text": "

Might want to pass that along to the Masque WG....

", "time": "2024-03-21T23:37:37Z"}, {"author": "Martin Thomson", "text": "

I would have been happier with \"host\", and \"port\"

", "time": "2024-03-21T23:38:53Z"}, {"author": "Martin Thomson", "text": "

Also, we have 405.

", "time": "2024-03-21T23:39:00Z"}, {"author": "Martin Thomson", "text": "

And OPTIONS (though no one has standardized a response form that would allow that)

", "time": "2024-03-21T23:39:22Z"}, {"author": "Martin Thomson", "text": "

I'm definitely on the \"one target host per connect\" train.

", "time": "2024-03-21T23:43:31Z"}, {"author": "Jonathan Hoyland", "text": "

This seems like the kind of place where you'd pass a URL to the server, and let it handle happy eyeballs, DNS, etc.

", "time": "2024-03-21T23:43:31Z"}, {"author": "Tommy Jensen", "text": "

+1 Jonathan, seems more productive / less resource hogging than the client doing it

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

I don't think that capsules will help for this, but I will observe that we can solve this later with a different mechanism, whether that be header fields or something else.

", "time": "2024-03-21T23:44:34Z"}, {"author": "Tommy Jensen", "text": "

Everything x5, :+1:

", "time": "2024-03-21T23:45:22Z"}, {"author": "Ted Hardie", "text": "

Note that the answers the proxy gets from the DNS and the client would get are not necessarily the same.

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

I prefer not to do capsules.

", "time": "2024-03-21T23:45:45Z"}, {"author": "Martin Thomson", "text": "

My overriding concern here is that this whole thing is just too complicated.

", "time": "2024-03-21T23:46:15Z"}, {"author": "Jonathan Hoyland", "text": "

@Ted Hardie but isn't that the point? DNS is not the same in different places for a reason

", "time": "2024-03-21T23:46:17Z"}, {"author": "David Benjamin", "text": "

Possibly dumb question: if you're doing proxy + client driving DNS, why isn't the solution to Happy Eyeballs simply the client opening multiple CONNECT streams and doing the Happy Eyeballs thing?

", "time": "2024-03-21T23:46:22Z"}, {"author": "Tommy Jensen", "text": "

@Ted that's a good point. Off the top of my head, I want to say that's a good thing (example: geolocation to the client isn't going to help if we're using the proxy anyway), but we should be deliberate about the choice

", "time": "2024-03-21T23:46:56Z"}, {"author": "Alan Frindell", "text": "

We need elephant transfer protocol

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

@Jonathan. The question is what you are getting as targets for happy eyeballs. If you don't care, then any set of IPv4 and IPv6 addresses can be the happy eyeball targets. But you may, and in those cases the more complex case where the client drives is required.

", "time": "2024-03-21T23:47:33Z"}, {"author": "Chris Lemmons", "text": "

Obviously, It's Elephant Protocol over Avian Carrier.

", "time": "2024-03-21T23:47:55Z"}, {"author": "Jonathan Lennox", "text": "

Alan: that\u2019d be for MASQUE not here

", "time": "2024-03-21T23:48:01Z"}, {"author": "Jonathan Hoyland", "text": "

So that seems like you should be falling back to client driving the TCP connections, no?

", "time": "2024-03-21T23:48:18Z"}, {"author": "Alan Frindell", "text": "

CONNECT-ELEPHANT. 4/1 is just a few days away

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

@Jonathan. in that case you have to. But there are cases where you might not, and the question may be whether it is worth supporting both.

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

The only part that bothers me there is that a packet isn't enough to hold an entire elephant.

", "time": "2024-03-21T23:49:29Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

How big a Mammoth Transmission Unit would you need?

", "time": "2024-03-21T23:50:08Z"}, {"author": "Erik Nygren", "text": "

Note that the client doesn't know if the proxy is IPv4-only, IPv6-only, or dual-stack. But it's generally much better to use DNS names so the proxy gets properly mapped by CDNs. RFC 9460 has guidance here on using DNS and which DNS names to use (ie, the TargetName): https://www.rfc-editor.org/rfc/rfc9460.html#name-clients-using-a-proxy

", "time": "2024-03-21T23:50:14Z"}, {"author": "Tommy Pauly", "text": "

+1 Erik

", "time": "2024-03-21T23:50:47Z"}, {"author": "Alan Frindell", "text": "

How much H1 Upgrade is there left out there? I probably don't want to hear the answer

", "time": "2024-03-21T23:51:29Z"}, {"author": "Mike Bishop", "text": "

But only if HTTP/1.1, right?

", "time": "2024-03-21T23:51:29Z"}, {"author": "Tommy Pauly", "text": "

@Martin aw man that means we need to fragment the elephant? That gets messy...

", "time": "2024-03-21T23:51:38Z"}, {"author": "Mirja K\u00fchlewind", "text": "

as there was a question about use cases: the sconepro use case (in case we also would want to address tcp) could be a use case for capsules in connect-tcp

", "time": "2024-03-21T23:52:19Z"}, {"author": "Jonathan Lennox", "text": "

Jumbo grams!

", "time": "2024-03-21T23:52:21Z"}, {"author": "Ted Hardie", "text": "

Dumbo grams!

", "time": "2024-03-21T23:52:31Z"}, {"author": "Mike Bishop", "text": "

@Alan, for WebSockets, a LOT. Other than WebSockets, I'm not aware of much.

", "time": "2024-03-21T23:52:36Z"}, {"author": "Alan Frindell", "text": "

I will admit to having an h2c implementation. But we don't use it anymore and let't get rid of this

", "time": "2024-03-21T23:52:55Z"}, {"author": "Erik Nygren", "text": "

Might we ever need to control NAGLE/NO_DELAY/PUSH in TCP proxying? I don't see anything about that in draft-ietf-httpbis-connect-tcp-02
\nWould that be a future use of capsules?

", "time": "2024-03-21T23:54:16Z"}, {"author": "David Benjamin", "text": "

@Erik Nygren My impression was that the Happy Eyeballs discussion was specifically for the case when the client wants to drive DNS. There are tradeoffs here (CDN mapping as you say, but the client may also not trust the proxy with the DNS names in some context), so I don't think we can assume either one is universal.

", "time": "2024-03-21T23:54:45Z"}, {"author": "Alan Frindell", "text": "

As I recall, handing the upgrade when the first request was a POST was a huge pain

", "time": "2024-03-21T23:54:47Z"}, {"author": "Lucas Pardue", "text": "

Doc seems on track to me, keep cranking

", "time": "2024-03-21T23:55:21Z"}, {"author": "Alan Frindell", "text": "

\"lightly parked\" a new state for drafts

", "time": "2024-03-21T23:56:19Z"}, {"author": "Tommy Pauly", "text": "

You can't get out of the car but you can wait in the loading zone

", "time": "2024-03-21T23:56:40Z"}, {"author": "Lucas Pardue", "text": "

It's too early to chat DSLs

", "time": "2024-03-21T23:56:54Z"}, {"author": "Benjamin Schwartz", "text": "

Erik Nygren said:

\n
\n

Might we ever need to control NAGLE/NO_DELAY/PUSH in TCP proxying? I don't see anything about that in draft-ietf-httpbis-connect-tcp-02
\nWould that be a future use of capsules?

\n
\n

NAGLE/NO_DELAY is usually set at connection time AFAIK, so it could be done with headers. PUSH would need capsules. Maybe another example would be classical PMTUD. I haven't heard any demand for those capabilities though.

", "time": "2024-03-22T00:01:45Z"}, {"author": "Benjamin Schwartz", "text": "

I guess PMTUD through the proxy would be pretty futile.

", "time": "2024-03-22T00:02:06Z"}, {"author": "Mirja K\u00fchlewind", "text": "

thinking about it more adding capsules means it add an extensibility mechanism that enables to send additional control data during the connection which I think is generally useful and good protocol design. I mean connect is a bit of a weird http method because it transforms a http connection basically into something else, so adding some machinery to be able maintain the connection makes sense to me.

", "time": "2024-03-22T00:05:38Z"}, {"author": "Kazuho Oku", "text": "

Nagle/NO_DELAY/PUSH is interesting, though we might argue that if the client delays sending some bytes, they will arrive late alongside other bytes that have pushed (or triggered a packet emission). To paraphrase, a proxy is forwarding packets that carry data that have already delayed and coalesced. So the question would be: do we need to add more delay / coalescing at the proxy?

", "time": "2024-03-22T00:06:42Z"}, {"author": "Benjamin Schwartz", "text": "

David Benjamin said:

\n
\n

Possibly dumb question: if you're doing proxy + client driving DNS, why isn't the solution to Happy Eyeballs simply the client opening multiple CONNECT streams and doing the Happy Eyeballs thing?

\n
\n

It's a performance optimization, mostly. Consider the case of putting a TLS ClientHello in the \"optimistic\" connect-tcp content (in the request's flight). With client-side happy eyeballs, the client ends up sending two ClientHellos to the proxy because it doesn't know which one will succeed, and the proxy establishes two complete TCP connections and elicits two ServerHellos before the client discovers which one worked and tears down the other one. It's a big waste.

", "time": "2024-03-22T00:08:48Z"}, {"author": "Benjamin Schwartz", "text": "

@Mirja K\u00fchlewind Note that connect-tcp does not take over the connection in H2 or H3. It is contained to a single request+response.

", "time": "2024-03-22T00:11:01Z"}, {"author": "Tommy Pauly", "text": "

@Ben I think we need to weight that against the cases where the client would actually do this and not send a CONNECT by hostname. Opening multiple CONNECTs for the cases where we would insist on resolving locally (which is usually a bad idea since we don't know if the proxy would have the same view of address results) is not that bad in practice for efficiency, since you shouldn't ever kick off happy eyeballs attempts at exactly the same time, but staggered. So you only have inefficiency if there is failure between the proxy and the target.

", "time": "2024-03-22T00:11:30Z"}, {"author": "Benjamin Schwartz", "text": "

@Tommy Pauly If an iOS app specifies \"requiresDNSSECValidation\", I think that forces the resolution to happen locally, resulting in this situation.

", "time": "2024-03-22T00:13:58Z"}, {"author": "Tommy Pauly", "text": "

Indeed, which is a more niche case currently. But still it isn't overall much of a problem to just connect by a normal IP address and in the unlikely case that the proxy has a busted IPv6 connectivity, fail over to the next CONNECT attempt... anyhow, this kind of use case by trying to optimize at the proxy seems quite experimental at this point

", "time": "2024-03-22T00:15:22Z"}, {"author": "Benjamin Schwartz", "text": "

Re: failures, if the proxy is IPv4-only then in principle you could see a 50% failure rate (all v6 connections fail).

", "time": "2024-03-22T00:15:30Z"}, {"author": "Tommy Pauly", "text": "

Yeah, very sad about a v4-only proxy...

", "time": "2024-03-22T00:15:57Z"}, {"author": "Jonathan Lennox", "text": "

I feel like clever programming could implement a multi-output pattern matcher?

", "time": "2024-03-22T00:16:51Z"}, {"author": "Benjamin Schwartz", "text": "

We could add text about using Proxy-Status to determine that the proxy is v4-only and remembering that for (mumble) minutes. :zany_face:

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

Jonathan: too clever

", "time": "2024-03-22T00:17:08Z"}, {"author": "David Benjamin", "text": "

Is there a pointer to where in the spec the linear search comes from? (I'm also curious/concerned.)

", "time": "2024-03-22T00:17:22Z"}, {"author": "Martin Thomson", "text": "

For each URL that you are fetching from a given origin, you need to determine whether it matches a dictionary.

", "time": "2024-03-22T00:17:56Z"}, {"author": "Patrick Meenan", "text": "

Here is the matching part of the spec: https://www.ietf.org/archive/id/draft-ietf-httpbis-compression-dictionary-03.html#name-dictionary-url-matching

", "time": "2024-03-22T00:18:17Z"}, {"author": "Martin Thomson", "text": "

If your match patterns are very broad, you might have multiple dictionaries that match. So your only recourse is to list all of the ones that match, testing each beforehand.

", "time": "2024-03-22T00:18:50Z"}, {"author": "Mike Bishop", "text": "

@David, because the match is a pattern and not a prefix, you have to look at all patterns for potential dictionaries you have on hand. If, for example, the pages are so similar that they can all be dictionaries for each other....

", "time": "2024-03-22T00:19:05Z"}, {"author": "Patrick Meenan", "text": "

It isn't explicit that it ends up being a linear search (and there are probably ways to optimize it) but the match pattern is a \"URLPattern\" which allows for wildcards

", "time": "2024-03-22T00:19:11Z"}, {"author": "Martin Thomson", "text": "

If matches have a fixed component, it might be possible to filter some out easily, but that isn't assured because URLPattern is very flexible.

", "time": "2024-03-22T00:19:32Z"}, {"author": "David Benjamin", "text": "

Hmm. Sounds like we need the client to cap to O(10) saved dictionaries per origin and toss the rest.

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

A cap seems advisable, yes.

", "time": "2024-03-22T00:20:12Z"}, {"author": "David Benjamin", "text": "

Or replace this with a less DoS-on-a-hair-trigger design. :-)

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

I might actually cap the number of saved URLPatterns. In the pathological situation of lots of cross-usable resources, they'll all have the same URLPattern.

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

The sconepro statement that 2% terrible is still terrible is echoing in my head as Lucas talks about the acceptable rate of degraded connections.

", "time": "2024-03-22T00:20:51Z"}, {"author": "Patrick Meenan", "text": "

Implementation optimization could take the prefix part of the URLPatterns and group them by prefix pats as a tree but there's a fair bit of flexibility for people to make it complicated

", "time": "2024-03-22T00:20:53Z"}, {"author": "Felix Handte", "text": "

A challenge is that a common case you want to use this for is to delta every JS/CSS file on your site.

", "time": "2024-03-22T00:20:55Z"}, {"author": "Tommy Jensen", "text": "

And that's now recorded on YouTube forever

", "time": "2024-03-22T00:20:55Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Benjamin Schwartz connect-tcp over h2/h2 doesn't take over the whole connection but one stream and the principle is very similar.

", "time": "2024-03-22T00:21:16Z"}, {"author": "Felix Handte", "text": "

(with its new version when you rebuild)

", "time": "2024-03-22T00:21:27Z"}, {"author": "Mike Bishop", "text": "

Keep the most recently-fetched dictionary for a given URLPattern and toss the old ones.

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

Ted: is that 2% thing really the case here? A TCP fallback might have poor performance, but it is better than not having connectivity at all.

", "time": "2024-03-22T00:21:42Z"}, {"author": "Mirja K\u00fchlewind", "text": "

actually the use case for masque to have capsules is using H3 datagrams. I guess that's a good use case here as well?

", "time": "2024-03-22T00:21:46Z"}, {"author": "Patrick Meenan", "text": "

For exact matches of patterns you can replace.

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

@Martin the current TCP fallback isn't terrible, except to the implementer. I think he's arguing that we can make the implmentation easier, even if the results are a little bit pessimal for the user. But that may be my misunderstanding.

", "time": "2024-03-22T00:23:06Z"}, {"author": "Benjamin Schwartz", "text": "

@Mirja K\u00fchlewind Not exactly. It lives within the DATA frames, so other frame types can still run on that stream.

", "time": "2024-03-22T00:24:23Z"}, {"author": "Ted Hardie", "text": "

Note that I think that if this work is going to have a benefit anywhere, I think it is here, because the HTTP semantics are well aligned across substrates. But the echo in my head hasn't quite stopped.

", "time": "2024-03-22T00:24:42Z"}, {"author": "Martin Thomson", "text": "

@Ted I see this more as an efficiency of implementation and specification. That is, we'll be doing TCP fallback anyway for those cases, but with this we might do so more cheaply and with more consistency.

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

It's not guaranteed it would be worse. I think we don't know that yet.

", "time": "2024-03-22T00:24:55Z"}, {"author": "David Benjamin", "text": "

We've done and likely will continue to do work that dips slightly below the HTTP semantics layer, like all the things they listed on the slide.

", "time": "2024-03-22T00:25:17Z"}, {"author": "Alan Frindell", "text": "

Been waiting to see Mark's face when someone proposed an H2 dot version. #worthit

", "time": "2024-03-22T00:25:51Z"}, {"author": "Ted Hardie", "text": "

Having gone through remodels where this \"you might as well change this while you've got the wall open\" logic resulted in years of pain, this is making my scars throb.

", "time": "2024-03-22T00:26:12Z"}, {"author": "Spencer Dawkins", "text": "

The best part is that the summary list is off the bottom of the slide ...

", "time": "2024-03-22T00:26:17Z"}, {"author": "Mike Bishop", "text": "

Now I'm curious what he felt needed to be hidden below the edge.

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

This would be HTTP/4

", "time": "2024-03-22T00:26:34Z"}, {"author": "Alan Frindell", "text": "

HTTP/e

", "time": "2024-03-22T00:26:44Z"}, {"author": "Tommy Jensen", "text": "

Ok, removing priorities catches my attention... not enough to want a 4th protocol tho

", "time": "2024-03-22T00:26:50Z"}, {"author": "Ted Hardie", "text": "

So 3 falls back to 4? Neat.

", "time": "2024-03-22T00:26:53Z"}, {"author": "Tommy Jensen", "text": "

Failing upward

", "time": "2024-03-22T00:27:16Z"}, {"author": "Ted Hardie", "text": "

HTTP is totally a middle-aged white guy. They always fail up.

", "time": "2024-03-22T00:27:38Z"}, {"author": "Benjamin Schwartz", "text": "

AFAICT /2.1 only helps implementations that can actually drop support for /2. Which might be possible, given the existence of /1.1, but it's pretty ambitious.

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

Ben Schwartz ++

", "time": "2024-03-22T00:28:03Z"}, {"author": "Spencer Dawkins", "text": "

Ted and Tommy are my heroes for this IETF 119 session ...

", "time": "2024-03-22T00:28:21Z"}, {"author": "Tommy Jensen", "text": "

+1 to Ben, I do not think we'll be able to replace HTTP/2 with <this> (I refuse to give it a number name)

", "time": "2024-03-22T00:28:57Z"}, {"author": "Tommy Pauly", "text": "

I think the point of the slides is to show that we don't want to do that version, but just use h3

", "time": "2024-03-22T00:29:22Z"}, {"author": "David Benjamin", "text": "

I don't think success means replacing HTTP/2. I think success means freezing HTTP/2 so that we stop having to backport new extensions to it.

", "time": "2024-03-22T00:29:42Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Now it's proposed and in people's heads...

", "time": "2024-03-22T00:29:55Z"}, {"author": "Tommy Jensen", "text": "
\n

I think success means freezing HTTP/2 so that we stop having to backport new extensions to it.

\n
", "time": "2024-03-22T00:30:15Z"}, {"author": "Alan Frindell", "text": "

I think the biggest problem with QUIC on streams is the name. It's a very useful protocol that we have use cases for. It's just not QUIC.

", "time": "2024-03-22T00:30:16Z"}, {"author": "Tommy Pauly", "text": "

Or put another way, success means that if we want to use h3 always, we can (as opposed to not being able to sometimes)

", "time": "2024-03-22T00:30:18Z"}, {"author": "Spencer Dawkins", "text": "

Tommy Pauly said:

\n
\n

Or put another way, success means that if we want to use h3 always, we can (as opposed to not being able to sometimes)

\n
\n

So much yes. ^^^^

", "time": "2024-03-22T00:31:05Z"}, {"author": "Jana Iyengar", "text": "

@davidbenjamin, but that requires us to acknowledge that /3 is better than /2. In which case we should want to support tcp under /3, since that fallback isn\u2019t going away

", "time": "2024-03-22T00:31:11Z"}, {"author": "Tommy Jensen", "text": "
\n

I think success means freezing HTTP/2 so that we stop having to backport new extensions to it.

\n
\n

Except I'm not convinced we can move everyone to <this> which means now we have to patch/fix two protocols instead

", "time": "2024-03-22T00:31:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Tommy Jensen like we froze IPv4?

", "time": "2024-03-22T00:31:16Z"}, {"author": "David Benjamin", "text": "

Jana Iyengar said:

\n
\n

@davidbenjamin, but that requires us to acknowledge that /3 is better than /2. In which case we should want to support tcp under /3, since that fallback isn\u2019t going away

\n
\n

Right, I think we're agreeing. I'm saying that success for h3 over ... over TCP is that we stop needing to extend h2.

", "time": "2024-03-22T00:31:47Z"}, {"author": "Tommy Jensen", "text": "

Exactly, Mirja :) (I hit enter too quickly and only quoted Tommy without responding)

", "time": "2024-03-22T00:31:50Z"}, {"author": "Jana Iyengar", "text": "

Agreed @davidben

", "time": "2024-03-22T00:32:16Z"}, {"author": "Spencer Dawkins", "text": "

At some point, blocking UDP/QUIC either will be too painful (so stop doing it) or not (so stop backporting to HTTP/2). At least, that seems like what I'm hearing.

", "time": "2024-03-22T00:32:29Z"}, {"author": "Mike Bishop", "text": "

This reminds me of SCTP/UDP, even though it's totally not.

", "time": "2024-03-22T00:32:40Z"}, {"author": "Mirja K\u00fchlewind", "text": "

ah right - so broadcast to all Tommys then

", "time": "2024-03-22T00:32:46Z"}, {"author": "Tommy Pauly", "text": "

@Tommy J I wasn't the one suggesting to freeze

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

@spencer that assumes that those blocking UDP are near the user or the developer enough to care about their pain

", "time": "2024-03-22T00:33:08Z"}, {"author": "David Benjamin", "text": "

Right, I don't think we can bank on that happening.

", "time": "2024-03-22T00:33:24Z"}, {"author": "Tommy Jensen", "text": "

And if we want to do a v4/v6 comparison, I'd point out we already have MASQUE/WT so this seems like a weird subset to target

", "time": "2024-03-22T00:33:27Z"}, {"author": "Ted Hardie", "text": "

So if you ran H/3 over this: https://pkg.go.dev/github.com/justlovediaodiao/udp-over-tcp#section-readme is that worse than this?

", "time": "2024-03-22T00:33:33Z"}, {"author": "David Schinazi", "text": "

I could have helped with <insert bikeshed here>

", "time": "2024-03-22T00:33:36Z"}, {"author": "Tommy Jensen", "text": "
\n

I wasn't the one suggesting to freeze

\n
\n

My bad

", "time": "2024-03-22T00:33:36Z"}, {"author": "Tommy Pauly", "text": "

No worries

", "time": "2024-03-22T00:33:50Z"}, {"author": "David Benjamin", "text": "

Ted Hardie said:

\n
\n

So if you ran H/3 over this: https://pkg.go.dev/github.com/justlovediaodiao/udp-over-tcp#section-readme is that worse than this?

\n
\n

I think that will be worse. You want the thing atop TCP to know it shouldn't do rexmits and ACKs because TCP will be doing it.

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

@Ted yes because nested loss recovery / retransmission

", "time": "2024-03-22T00:34:09Z"}, {"author": "Benjamin Schwartz", "text": "

I'm pretty doubtful about the possibility of freezing HTTP/2, because resources and services need to exist independent of HTTP version.

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

what David said

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

Also, as. long as you have TCP, you have a different path layer than QUIC, with more leakage than QUIC permits. At the very least, that needs security analysis.

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

Http version is not the thing that\u2019s going to change the internet ecosystem on UDP blocking.

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

@David how is this avoiding that?

", "time": "2024-03-22T00:34:40Z"}, {"author": "Alex Chernyakhovsky", "text": "

resources and services need to exiset independent of an HTTP version, but that doesn't mean we have to backport every feature to every http version

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

@ted \u2014 this leaves retransmissions to tcp

", "time": "2024-03-22T00:35:09Z"}, {"author": "David Benjamin", "text": "

@Ted AIUI, they are implementing a TCP-based protocol that provides the QUIC interface (multiplexed streams).

", "time": "2024-03-22T00:35:12Z"}, {"author": "Spencer Dawkins", "text": "

I thought I heard Lucas say that he wasn't trying to make a proposal for fallback that wouldn't have performance penalties.

", "time": "2024-03-22T00:35:16Z"}, {"author": "David Benjamin", "text": "

The way to think about this is that gQUIC was cut down the middle into QUIC, a UDP protocol that provides a multiple streams interface, and then h3, a protocol that sits atop those streams.

\n

This is simply repeating that exercise for h2 and making the interfaces match.

", "time": "2024-03-22T00:35:52Z"}, {"author": "Ted Hardie", "text": "

I thought this was still retransmitting QUIC data, rather than packets. Perhaps I misread it, but I think if that is the case, you haven't avoided the problem.

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

There's lots of cool native QUIC stuff that this proposal strictly does not support

", "time": "2024-03-22T00:36:21Z"}, {"author": "Tommy Jensen", "text": "

@David except that where HTTP/3 was created to map to a new transport, we're now defining a third way to map HTTP onto TCP

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

@Ted TCP handles the loss detection and recovery in theis proposal

", "time": "2024-03-22T00:36:56Z"}, {"author": "Ted Hardie", "text": "

@Lucas Thanks for correcting my misunderstanding.

", "time": "2024-03-22T00:37:21Z"}, {"author": "Jana Iyengar", "text": "

It doesn\u2019t do retransmissions. There\u2019s a natural line in all impls between the steam handling and the packet handling. This prooosal splits quic at that line and moves the top onto tcp

", "time": "2024-03-22T00:38:24Z"}, {"author": "Ted Hardie", "text": "

I think Lucas's point reinforces Alan's point that this cannot be considered QUIC, but a different thing, which means the APIs will still be different between QUIC and X on streams. So I think this doesn't get you across the finish line, even if X on streams is less painful for you. You still have 2, (and very likely 3), but a different 2.

", "time": "2024-03-22T00:38:45Z"}, {"author": "Chris Box", "text": "

https://radar.cloudflare.com/adoption-and-usage?dateRange=52w shows the proportion of HTTP/3 has declined over the last month. Adoption is going more slowly than I had expected.

", "time": "2024-03-22T00:39:31Z"}, {"author": "Benjamin Schwartz", "text": "

We can call that layer Streaming Link Overlay

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

Yeah, I don't think we should call this QUIC.

", "time": "2024-03-22T00:39:39Z"}, {"author": "Mirja K\u00fchlewind", "text": "

without retransmissions in TCP it would be TCP minions which has deployment problems.

", "time": "2024-03-22T00:39:49Z"}, {"author": "Tommy Jensen", "text": "

Wait, so we are still going to iterate on HTTP/2? That really does undermine this value (trying to replace, not append, to the HTTP list supported)

", "time": "2024-03-22T00:40:15Z"}, {"author": "David Benjamin", "text": "

I think the way to do this is to take the QUIC interface, implement it over TCP, taking inspiration from the QUIC protocol where applicable, and then rebasing h3 on top of this.

", "time": "2024-03-22T00:40:19Z"}, {"author": "Jana Iyengar", "text": "

TCP minion doesn\u2019t change retransmissions in tcp. That said, what I meant was this (quic streams) doesn\u2019t retransmit on its own, it relies on tcp to do it

", "time": "2024-03-22T00:40:50Z"}, {"author": "Ted Hardie", "text": "

@David The underlying capabilities of the substrates are different. Unifying the API does not help in that case, because you either have case statements for the two different substrates anyway or you lose anything that is not common to the two. That would damage QUIC.

", "time": "2024-03-22T00:41:14Z"}, {"author": "Thomas Eizinger", "text": "

That is basically what this proposal is. Extract the multiplexing from QUIC, call it QMUX or something and just put that on top of TCP.

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

+1 davidben

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

@David, I think that's effectively what's being done here.

", "time": "2024-03-22T00:41:32Z"}, {"author": "Spencer Dawkins", "text": "

Jana Iyengar said:

\n
\n

@spencer that assumes that those blocking UDP are near the user or the developer enough to care about their pain

\n
\n

Jana, I understand, but is that saying that there are people causing this problem who don't have a relationship with senders or receivers and can't be routed around?

\n

I understood why we assumed TCP fallback when we chartered QUIC, but that's been a while, and doing whatever we need to do to make sure that keeps working is just depressing!

", "time": "2024-03-22T00:41:40Z"}, {"author": "David Benjamin", "text": "

Right, I'm agreeing with the proposal.

", "time": "2024-03-22T00:41:47Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Mike Bishop I believe David's point is some of the conversation so far has been assuming we're doing something more like QUIC-over-TCP

", "time": "2024-03-22T00:42:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Ah right tcp minion only removed ordering? I thought there was also an option to not have retransmissions... anyway would be a rather big change to TCP which I'm not sure would deploy well.

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

So run connect UDP to a proxy resident on the same box as the native QUIC stack?

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

I think we may want to reframe. We should first agree if the problem of running a single h3 for apps is worthwhile, so that apps don\u2019t have to build to both. We can then figure out what the best way to do that is \u2014 this proposal, Tommy\u2019s proposal, etc.

", "time": "2024-03-22T00:43:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Thomas Eizinger Isn't multiplexing over tcp already exactly the thing that H2 gives you?

", "time": "2024-03-22T00:43:32Z"}, {"author": "Jana Iyengar", "text": "

@spencer \u2014 the fallback was never short term in my mind

", "time": "2024-03-22T00:43:52Z"}, {"author": "Tommy Jensen", "text": "

+1 Jana, with specific goals/non-goals called out (are we trying to provide HTTP/3 only for both transports to devs, or also saying we want to avoid maintaining HTTP/2 as well)

", "time": "2024-03-22T00:44:06Z"}, {"author": "Tommy Pauly", "text": "

@Ted, yes have the proxy be resident on the same server host itself, and then optimize from there. The baseline (which is inefficient but works) doesn't require any new protocol work

", "time": "2024-03-22T00:44:33Z"}, {"author": "Alan Frindell", "text": "

is rapid reset a reason to upgrade

", "time": "2024-03-22T00:44:36Z"}, {"author": "Ted Hardie", "text": "

@Tommy that seems like a much lower friction deployment approach. It still won't work well for MoQ or non H3 deployments, but I think that's ok.

", "time": "2024-03-22T00:45:24Z"}, {"author": "David Benjamin", "text": "

I don't think we should start from proxying QUIC-over-UDP-over-TCP. That will double rexmit and then we'll spend forever basically undoing all the bits of QUIC-the-transport... ultimately getting to a completely different protocol. Let's just figure out the interface that all our various works need and start from there. Just take inspiration on the wire format from QUIC where it makes sense.

", "time": "2024-03-22T00:45:26Z"}, {"author": "Spencer Dawkins", "text": "

Mirja K\u00fchlewind said:

\n
\n

Ah right tcp minion only removed ordering? I thought there was also an option to not have retransmissions... anyway would be a rather big change to TCP which I'm not sure would deploy well.

\n
\n

If we're also talking about paths with ossified TCP middleboxes, the outermost TCP will need to look a lot like standard TCP. This reminds me of middleboxes that reset connections when they see ack gaps that aren't retransmitted, for example.

", "time": "2024-03-22T00:45:28Z"}, {"author": "Yaroslav Rosomakho", "text": "

To be reasonably available form the public internet today HTTP stacks have to offer three stacks: HTTP/1.1, HTTP/2 and HTTP/3. It seems to me that this will add up to complexity as yet another stack to support. I don't think it will accelerate removal of a previous HTTP versions...

", "time": "2024-03-22T00:45:54Z"}, {"author": "Tommy Jensen", "text": "
\n

is rapid reset a reason to upgrade

\n
\n

A reason, but not observed to be a universally compelling reason

", "time": "2024-03-22T00:45:56Z"}, {"author": "David Benjamin", "text": "

From there, whether we call the interface \"QUIC\" and the two implementations \"QUIC-UDP\" or \"QUIC-TCP\", or whether we call the interface \"QMUX\" and the implementations \"QUIC\" vs \"QMUX-TCP\", that's just naming.

", "time": "2024-03-22T00:46:01Z"}, {"author": "Tommy Pauly", "text": "

@Ted agreed that it won't work well for MoQ but I'm not sure the other approaches really work very well either. So yes, trying to make something that is lower friction.

", "time": "2024-03-22T00:46:09Z"}, {"author": "Tommy Jensen", "text": "

+0xff to Yaroslav

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

@mnot - I agree, but for a single customer, they still need to serve on both /3 and /2. This proposal changes that. And importantly, moving off /2 might happen in my lifetime, but UDP blocking won\u2019t.

", "time": "2024-03-22T00:46:19Z"}, {"author": "Ted Hardie", "text": "

I am supposed to be backing Eric up in writing the minutes, but he has pre-populated his remarks there, saving me work. Thanks @Eric!

", "time": "2024-03-22T00:46:21Z"}, {"author": "Thomas Eizinger", "text": "

@Mirja Yes but it is broken in several ways as Lucas outlined. I think for HTTP, it actually doesn't offer as much benefit because within a browser, an app developer already gets multiplexing and can't tell the difference. But for anybody who wants multiplexing over TCP, they could use that.

", "time": "2024-03-22T00:46:22Z"}, {"author": "Spencer Dawkins", "text": "

Jana Iyengar said:

\n
\n

@spencer \u2014 the fallback was never short term in my mind

\n
\n

Nor in my mind. I was hoping that preserving TCP fallback wouldn't be a priority for years/decades.

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

Not something I want as a priority @spencer, just my response to reality

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

There are multiplexers over TCP but they are also not great. For example: https://github.com/hashicorp/yamux.

", "time": "2024-03-22T00:47:55Z"}, {"author": "Tommy Jensen", "text": "

So, a transport topic and not an HTTP specific topic basically

", "time": "2024-03-22T00:48:15Z"}, {"author": "Jana Iyengar", "text": "

I think this entire effort should be in QUIC btw

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

Tommy Jensen +1

", "time": "2024-03-22T00:49:11Z"}, {"author": "Zaheduzzaman Sarker", "text": "

@allan. If there are lots of usecases of multiplexing over TCP, then why can't those be done over QUIC. isn't that was one of the benefit of having QUIC?

", "time": "2024-03-22T00:49:32Z"}, {"author": "Jana Iyengar", "text": "

There\u2019s more of the future than the past @mt :)

", "time": "2024-03-22T00:50:00Z"}, {"author": "Alan Frindell", "text": "

QUIC is not the best choice everywhere. I don't think anyone is using QUIC in DC right now due to cost. Maybe that comes down over time.

", "time": "2024-03-22T00:50:31Z"}, {"author": "Jana Iyengar", "text": "

Webtransport wants fallback too, they\u2019re just doing it by implementing it on top of both /3 and /2

", "time": "2024-03-22T00:50:51Z"}, {"author": "Alan Frindell", "text": "

120 Hackathon

", "time": "2024-03-22T00:51:24Z"}, {"author": "Jonathan Lennox", "text": "

Well, defining it. Is anyone implementing WT over H2?

", "time": "2024-03-22T00:51:40Z"}, {"author": "Zaheduzzaman Sarker", "text": "

but it is not used then we dont have problem :-)

", "time": "2024-03-22T00:52:38Z"}, {"author": "Thomas Eizinger", "text": "

Why would a browser need to keep H2? Are there servers out there that _only_ support H2 and don't have an H1 fallback or can already do H3? Probably :(

", "time": "2024-03-22T00:52:57Z"}, {"author": "Alan Frindell", "text": "

Great question: ^ There's one implementation right now I think? I'd be more excited about implementing WT over H3 over QoS than WT over H2. And I'm an Author

", "time": "2024-03-22T00:53:00Z"}, {"author": "Benjamin Schwartz", "text": "

I think there's a numerical question here: what percent of counterparts (users, servers) would you be comfortable dropping from H2 to HTTP/1.1 in pursuit of maintenance simplicity?

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

It\u2019s got to perform at least as well as /2. The incentive here would be that my customers (apps) that are currently running on /3 and /2 would run on just one version

", "time": "2024-03-22T00:53:40Z"}, {"author": "Tommy Jensen", "text": "

@Thomas or would regress by falling back to 1.1 and have UDP blocked on the path in some situations

", "time": "2024-03-22T00:53:54Z"}, {"author": "Tommy Jensen", "text": "

+1 to Ben, exactly

", "time": "2024-03-22T00:54:19Z"}, {"author": "Erik Nygren", "text": "

Having a DoQ that worked over TCP might be useful as well (but we also have DoT there so maybe we don't need it).

", "time": "2024-03-22T00:54:30Z"}, {"author": "Jana Iyengar", "text": "

I\u2019m amused that people thjng /2 will be around forever, but UDP blocking might go away.

", "time": "2024-03-22T00:54:41Z"}, {"author": "Alex Chernyakhovsky", "text": "

+1 to Jana

", "time": "2024-03-22T00:54:53Z"}, {"author": "Thomas Eizinger", "text": "

@Ben. Would be nice to get some numbers from the big companies and browsers here.

", "time": "2024-03-22T00:55:05Z"}, {"author": "Tommy Jensen", "text": "

/2 will be around as long as some subset of customers prefer the throughput/latency trade-off in that direction

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

I will eat my hat and my shoes if UDP blocking goes away

", "time": "2024-03-22T00:55:37Z"}, {"author": "Tommy Jensen", "text": "

No bet, Jana, not saying that it will

", "time": "2024-03-22T00:55:53Z"}, {"author": "Thomas Eizinger", "text": "

What I like about this proposal is that it gives app developers a choice to upgrade their stack, independent of network operators.

", "time": "2024-03-22T00:55:58Z"}, {"author": "Mirja K\u00fchlewind", "text": "

/2 deployment has a long tale of things that you can't update. UDP blocking could always be turned off if there is a real effort. Not saying it will every happen but it's a different story.

", "time": "2024-03-22T00:56:24Z"}, {"author": "Tommy Jensen", "text": "

@erik I mean, potentially, but DoQoTCP does seem like DoT but with extra steps when DoT is already widely deployed

", "time": "2024-03-22T00:57:14Z"}, {"author": "Erik Nygren", "text": "

This could be a classic case of https://xkcd.com/927/ if trying to put HTTP over this.

", "time": "2024-03-22T00:57:34Z"}, {"author": "Tommy Jensen", "text": "

^^^

", "time": "2024-03-22T00:58:07Z"}, {"author": "Zaheduzzaman Sarker", "text": "

fun fact: we have TAPS :-)....

", "time": "2024-03-22T00:58:28Z"}, {"author": "Tommy Jensen", "text": "

So there's an interesting way to combine Ted's point with Alan's: is QUIC over TCP giving us something that QUIC over CONNECT-IP/TCP does not?

", "time": "2024-03-22T00:59:12Z"}, {"author": "Tommy Jensen", "text": "

(transport Q, not an HTTP Q)

", "time": "2024-03-22T00:59:30Z"}, {"author": "Jonathan Lennox", "text": "

Avoiding double crypto and double cc/loss recovery

", "time": "2024-03-22T01:00:02Z"}, {"author": "Tommy Pauly", "text": "

I think it would be QUIC over CONNECT-UDP/TCP to be most efficient. And the main delta is the extra acks and extra encryption. But that's solvable if you really care, which I'm not sure you do...

", "time": "2024-03-22T01:00:05Z"}, {"author": "Tommy Pauly", "text": "

@Jonathan yup you beat me to it

", "time": "2024-03-22T01:00:18Z"}, {"author": "Benjamin Schwartz", "text": "

Tommy Jensen said:

\n
\n

So there's an interesting way to combine Ted's point with Alan's: is QUIC over TCP giving us something that QUIC over CONNECT-IP/TCP does not?

\n
\n

Yes, they're very different. QUIC over CONNECT-UDP over TCP gives you multiple layers of congestion control, acking, retransmission, etc.

", "time": "2024-03-22T01:00:33Z"}, {"author": "Yaroslav Rosomakho", "text": "

UDP blocking will eventually go away - as soon as your favourite internet search engine or a business critical app is no longer operating when UDP is blocked. Websockets over HTTPS were commonly blocked by enterprises when they were introduced. Now you can rely on them and deliver app widely - because certain apps started requiring websockets for their operation.

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

To Ted\u2019s point : don\u2019t run tcp that doesn\u2019t look like tcp on the wire. Doesn\u2019t work. There\u2019s evidence, there\u2019s a paper from UCL which demonstrates this

", "time": "2024-03-22T01:01:01Z"}, {"author": "Tommy Jensen", "text": "

Fair point, though it's also more generalized, but yes thanks for outlining.

", "time": "2024-03-22T01:01:06Z"}, {"author": "Jonathan Lennox", "text": "

One worry is that there are QUIC usages that think they can get useful information from the ACKs (notably RoQ). But arguably this is wrong for other reasons.

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

@yaroslav, when your fav browser stops working, the problem is escalated to said browser that will then promptly fix the problem by having a tcp fallback

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

I think QUIC on Streams should have a different name, and shouldn't go to the quic-wg. It has nothing to do with QUIC. It shares code points for convenience.

", "time": "2024-03-22T01:02:46Z"}, {"author": "Erik Nygren", "text": "

Left the queue since I didn't have anything to add that wasn't already said. I was originally thinking this was a great idea (and perhaps better than H/2.1 if we need that), but MT, David, and Mike Bishop said.
\nThe \"this seems like a good idea to specify, but outside of the HTTP context, and we can revisit later if we'd want to put HTTP on top of it after using it successfully for new protocols starting H3 first\"

", "time": "2024-03-22T01:03:10Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, QoS should probably go to DISPATCH?

", "time": "2024-03-22T01:03:30Z"}, {"author": "Jonathan Lennox", "text": "

(Also needs a new name because of the acronym collision)

", "time": "2024-03-22T01:04:01Z"}, {"author": "Erik Nygren", "text": "

It might be reasonable for QUIC to define QoS (which needs a different acryonym)

", "time": "2024-03-22T01:04:06Z"}, {"author": "Yaroslav Rosomakho", "text": "

@Jana Right... so perhaps browsers would not be the best starting point to sunset TCP-based HTTP - but introduction of exciting new apps that require HTTP/3 for correct operation would. Or at least if they demonstrate HTTP/3 benefits that would be seen by the user.

", "time": "2024-03-22T01:04:12Z"}, {"author": "Kyle Nekritz", "text": "

Another option is QUIC with disabled congestion control over a fake TLS framing layer

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

fake TLS framing layer is already called TLS1.3 :)

", "time": "2024-03-22T01:04:39Z"}, {"author": "Tommy Jensen", "text": "

xD

", "time": "2024-03-22T01:04:53Z"}, {"author": "Kyle Nekritz", "text": "

Right, it\u2019s already proven to work

", "time": "2024-03-22T01:04:59Z"}, {"author": "Francesca Palombini", "text": "

https://datatracker.ietf.org/meeting/119/materials/slides-119-httpbis-reverse-tunnel-00

", "time": "2024-03-22T01:05:43Z"}, {"author": "Francesca Palombini", "text": "

(slides)

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

A completely static image appears to be using 300+Kbps.

", "time": "2024-03-22T01:07:05Z"}, {"author": "Chris Lemmons", "text": "

Yeah, it's a full screen-share instead of just slides.

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

This always annoys me.

", "time": "2024-03-22T01:07:50Z"}, {"author": "Chris Lemmons", "text": "

I had some really fun macro-blocking when it loaded. I was so confused.

", "time": "2024-03-22T01:08:12Z"}, {"author": "Mirja K\u00fchlewind", "text": "

connect is the Swiss knife of http

", "time": "2024-03-22T01:08:29Z"}, {"author": "Jonathan Lennox", "text": "

Does the reverse path HTTP version have to match the forward path version?

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

I agree with Erik. I would like to see an HTTP version on top of it, but I think that can be a later problem to solve

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

(Sorry, phone delays. My point above was for QOS)

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

CONNECT-HTTP

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

CONNECT-HTTP-LISTEN

", "time": "2024-03-22T01:10:48Z"}, {"author": "Alan Frindell", "text": "

CONNECT-HTTP cracks me up

", "time": "2024-03-22T01:11:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

CONNECT-HTTP over H3 over QUIC over TCP

", "time": "2024-03-22T01:13:07Z"}, {"author": "Tommy Jensen", "text": "

If the client is sending response codes to the server, and there's an error, does it send 4xx or 5xx for which peer failing?

", "time": "2024-03-22T01:13:39Z"}, {"author": "Erik Nygren", "text": "

And then run WebTransport over CONNECT-HTTP over H3 over QUIC over TCP

", "time": "2024-03-22T01:14:00Z"}, {"author": "Mike Bishop", "text": "

Kazuho's extension of CONNECT-TCP to parallel CONNECT-UDP-BIND's behavior in Masque is actually the compelling scenario for using capsules with CONNECT-TCP that I was asking about during @Ben's presentation.

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

The UDP and TCP listener connect model is possibly more interesting, but even there I have reservations.

", "time": "2024-03-22T01:15:00Z"}, {"author": "Mike Bishop", "text": "

UDP listening is already being defined in Masque; doing the same thing for TCP is a logical extension of that work.

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

I don't like the idea of having the proxy being able to see and modify the contents of requests and responses.

", "time": "2024-03-22T01:16:16Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Thomson With all these reverse proposals, this is strictly between gateways and backends. Browsers would not be involved at all.

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

The browser comment was not the main one.

", "time": "2024-03-22T01:17:00Z"}, {"author": "Erik Nygren", "text": "

On QUIC-on-Steams: while a bikeshed, using \"h3t\" might not be an awful ALPN if we ever do this.
\nOne thing that might be worth looking for the HTTP side of it would be both client and server resource usage (eg, CPU, etc).
\nIf an \"h3t\" could use enough less CPU (and thus power/energy) than normal h3 over QUIC then it might also be applicable for low-latency/low-loss/high-throughput links where QUIC doesn't add enough value. That could overcome some of the \"why should we do this\" inertia, especially for cases where people want to jump from h2 to h3 because a higher number must always be better.

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

The point being to avoid having your proxy-fronted origin listening on the open Source internet?

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

-source, autocomplete

", "time": "2024-03-22T01:18:18Z"}, {"author": "Benjamin Schwartz", "text": "

Pretty much. Think DDoS protection.

", "time": "2024-03-22T01:18:32Z"}, {"author": "Mike Bishop", "text": "

If it's a bug, should it be an erratum instead of a new RFC?

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

YOU ARE NOT HAVING 128 OF MY MEGS

", "time": "2024-03-22T01:19:32Z"}, {"author": "Felix Handte", "text": "

We looked at filing an erratum but felt it was too substantive.

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

Yeah, this is the right way to do it.

", "time": "2024-03-22T01:19:51Z"}, {"author": "Nidhi Jaju", "text": "

@Mike: We're also updating the meaning of the token in IANA registration, so a new RFC seemed like the right approach

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

Oh man, missing this slide set is a shame.

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

A \"little bit controversial\" is understating it. \"The last year\" is grossly understating it.

", "time": "2024-03-22T01:21:03Z"}, {"author": "Jonathan Lennox", "text": "

I see them in the tracker

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

https://datatracker.ietf.org/meeting/119/materials/slides-119-httpbis-link-local-uri-connectivity

", "time": "2024-03-22T01:21:17Z"}, {"author": "Murray Kucherawy", "text": "

I need this slide deck.

", "time": "2024-03-22T01:23:29Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

(deleted)

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

@erik regarding how much value QUIC provides, I think that is a super important point. There's cases I have where I want multiplexing over existing TLS or intraprocess comes. Doing QUIC packetization adds no value there.

", "time": "2024-03-22T01:24:39Z"}, {"author": "Tommy Jensen", "text": "

\"fancy\"

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

I had not considered if other scenarios where performance is important could also benefit, such IoT. If anyone has examples that might benefit for QoS, I'm all ears.

", "time": "2024-03-22T01:26:45Z"}, {"author": "Murray Kucherawy", "text": "

We need to stop writing RFCs in Klingon.

", "time": "2024-03-22T01:27:08Z"}, {"author": "Benjamin Schwartz", "text": "

Getting in ahead of the deadline: I want to solve this, but this draft's solution is actually even less secure than insecure HTTP. I think we need to do better, which means getting into a much stickier world of TOFU and scary warning dialogs.

", "time": "2024-03-22T01:27:36Z"}, {"author": "Jonathan Lennox", "text": "

We need to start writing RFCs in Klingon.

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

Today is a god day to diediedie

", "time": "2024-03-22T01:27:40Z"}, {"author": "Murray Kucherawy", "text": "

This one is Jarvis vs. Ultron

", "time": "2024-03-22T01:28:02Z"}, {"author": "Tommy Jensen", "text": "

We heard Gemini, let's bis https://www.rfc-editor.org/rfc//rfc647

", "time": "2024-03-22T01:28:27Z"}, {"author": "Murray Kucherawy", "text": "

Which HP printers accept large electrified drill bits as interfaces?

", "time": "2024-03-22T01:29:38Z"}, {"author": "Chris Lemmons", "text": "

All of them, actually. :D

", "time": "2024-03-22T01:30:03Z"}, {"author": "Chris Lemmons", "text": "

(May have some degradation of quality.)

", "time": "2024-03-22T01:30:22Z"}, {"author": "Jonathan Lennox", "text": "

But only once

", "time": "2024-03-22T01:30:23Z"}, {"author": "Eric Kinnear", "text": "

There's a subscription now if you need it to work more than once

", "time": "2024-03-22T01:30:41Z"}, {"author": "Benjamin Schwartz", "text": "

Ah yes, cFJpTnRB, that's my printer.

", "time": "2024-03-22T01:30:42Z"}, {"author": "Tommy Jensen", "text": "

Security is in the eyes of the beholder?

", "time": "2024-03-22T01:30:47Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

The bikesheds return.

", "time": "2024-03-22T01:31:42Z"}, {"author": "Brian Carpenter", "text": "

Be aware that (at least on Linux) it doesn't always \"just work\", because the path from getaddrinfo() to sendmsg() seems to lose the interface number in some cases.

", "time": "2024-03-22T01:33:04Z"}, {"author": "Yaroslav Rosomakho", "text": "

Just use socat to connect IPv6 link local socket to the loopback interface! /s
\nSeriously though, lack of link local addresses support in browsers is a very real issue that would be great to solve.

", "time": "2024-03-22T01:33:31Z"}, {"author": "Francesca Palombini", "text": "

(just FYI, I don't know how long the meetecho room will stay open...)

", "time": "2024-03-22T01:34:17Z"}, {"author": "Brian Carpenter", "text": "

@Yaroslav: https://github.com/becarpenter/misc/blob/main/zelect/README.md

", "time": "2024-03-22T01:34:21Z"}, {"author": "Lorenzo Miniero", "text": "

We won't cut you out, Francesca

", "time": "2024-03-22T01:34:36Z"}, {"author": "Francesca Palombini", "text": "

awesome, thank you! :)

", "time": "2024-03-22T01:34:52Z"}, {"author": "Murray Kucherawy", "text": "

Nice.

", "time": "2024-03-22T01:35:11Z"}, {"author": "Martin D\u00fcrst", "text": "

Meetecho is amaziing. I switched off my PC more than an hour ago, and moved from home to work, and switched on my PC, and things just continued the very second the PC was up!

", "time": "2024-03-22T01:36:35Z"}, {"author": "Murray Kucherawy", "text": "

Charter approved.

", "time": "2024-03-22T01:38:52Z"}, {"author": "Francesca Palombini", "text": "

those in the queue, could you post your comment in the chat?

", "time": "2024-03-22T01:38:59Z"}, {"author": "Francesca Palombini", "text": "

and of course in the mailing list later

", "time": "2024-03-22T01:39:26Z"}, {"author": "Yaroslav Rosomakho", "text": "

+1 Ben

", "time": "2024-03-22T01:39:57Z"}, {"author": "Mike Bishop", "text": "

There was a discussion in ADD yesterday about certificates for private networks. Go talk with those folks.

", "time": "2024-03-22T01:40:22Z"}, {"author": "Kyle Nekritz", "text": "

Put the pubkey in the URL like onion hostnames?

", "time": "2024-03-22T01:40:33Z"}, {"author": "Erik Nygren", "text": "

+1 Ben (which feeds into the discussion in ADD as well on the needs to bring up something like mt's \"HTTPS for Local Domains\" but would likely want its own BOF/WG)

", "time": "2024-03-22T01:41:07Z"}, {"author": "Erik Nygren", "text": "

Martin Thomson's not-even-an-I-D-yet proposal which has an example direction: https://docs.google.com/document/d/170rFC91jqvpFrKIqG4K8Vox8AL4LeQXzfikBQXYPmzU/edit#heading=h.cp9yfs7gg5p7
\n(but yes, pubkey hash in the hostname which has the nice property that the Origin is also bound cryptographically to a local service)

", "time": "2024-03-22T01:42:36Z"}, {"author": "Francesca Palombini", "text": "

thanks all!

", "time": "2024-03-22T01:43:23Z"}]