I'm stuck waiting for an elevator down. This would be less problematic if I weren't early on the agenda
", "time": "2022-11-09T09:31:57Z"}, {"author": "Eric Kinnear", "text": "No worries, Alex, we'll start in a minute or two, elevators have been fun for everyone
", "time": "2022-11-09T09:32:25Z"}, {"author": "Martin Thomson", "text": "also, taking your mask off while talking is one of the worst times to do that
", "time": "2022-11-09T09:37:36Z"}, {"author": "Tommy Pauly", "text": "Indeed. While it is allowed, it shouldn't likely be encouraged.
", "time": "2022-11-09T09:38:38Z"}, {"author": "David Schinazi", "text": "It makes sense at the chair desk / presenter stand since that's far from folks, but yeah keeping masks on in mic line is encouraged
", "time": "2022-11-09T09:39:25Z"}, {"author": "Eric Kinnear", "text": "Yeah, that's what got published, but :-\\
", "time": "2022-11-09T09:39:54Z"}, {"author": "David Schinazi", "text": "And they're not crashing anymore either!
", "time": "2022-11-09T09:39:54Z"}, {"author": "Alan Frindell", "text": "Which capsules is chrome sending on webtransport? I've been trying wt interop this week and confused about what chrome is sending on the body.
", "time": "2022-11-09T09:55:50Z"}, {"author": "Luke Curley", "text": "I think it's just the CLOSE_WEBTRANSPORT_SESSION capsule, which I actually haven't implemented yet
", "time": "2022-11-09T09:58:43Z"}, {"author": "David Schinazi", "text": "Chrome was using the old REGISTER_DATAGRAM capsules from earlier HTTP Datagram drafts
", "time": "2022-11-09T09:59:35Z"}, {"author": "Martin Thomson", "text": "NAT at the tunnel endpoint is a great design choice for several reasons
", "time": "2022-11-09T10:00:04Z"}, {"author": "Martin Thomson", "text": "I would like to be able to request NAT, even if it weren't the default
", "time": "2022-11-09T10:00:31Z"}, {"author": "David Schinazi", "text": "Meetecho: it looks like the meetecho queue screen in the room isn't updating right now
", "time": "2022-11-09T10:01:07Z"}, {"author": "David Schinazi", "text": "Meetecho: We're also not seeing the remote speaker in the room
", "time": "2022-11-09T10:02:22Z"}, {"author": "Lorenzo Miniero", "text": "Laptop on the chair desk is frozen, coming
", "time": "2022-11-09T10:02:43Z"}, {"author": "Benjamin Schwartz", "text": "This is not actually how STUN works but it's OK
", "time": "2022-11-09T10:03:28Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz yup
", "time": "2022-11-09T10:03:42Z"}, {"author": "Martin Thomson", "text": "I'm not sure why this is about STUN rather than TURN
", "time": "2022-11-09T10:03:58Z"}, {"author": "Benjamin Schwartz", "text": "@Martin Thomson TURN is already working. This is about STUN.
", "time": "2022-11-09T10:04:25Z"}, {"author": "Tommy Pauly", "text": "Yeah the details aren't quite right, but the need for the CONNECT-UDP layer being able to \"listen\" still stands for the WebRTC use case
", "time": "2022-11-09T10:04:44Z"}, {"author": "Martin Thomson", "text": "Yeah, I don't think that the accuracy of the slides has any bearing on the outcome.
", "time": "2022-11-09T10:05:06Z"}, {"author": "Tommy Pauly", "text": "Quite so
", "time": "2022-11-09T10:05:11Z"}, {"author": "Martin Thomson", "text": "Why not use a capsule to request this capability?
", "time": "2022-11-09T10:06:05Z"}, {"author": "David Schinazi", "text": "I'll take responsibility for that, my understanding of STUN is quite approximate
", "time": "2022-11-09T10:06:11Z"}, {"author": "Alan Frindell", "text": "Doesn't having multiple connect-udp streams on the same connection between client and proxy solve the problem about landing on the same server?
", "time": "2022-11-09T10:06:17Z"}, {"author": "David Schinazi", "text": "@Alan it doesn't because intermediaries
", "time": "2022-11-09T10:06:32Z"}, {"author": "Tommy Pauly", "text": "What would a capsule do?
", "time": "2022-11-09T10:06:37Z"}, {"author": "Martin Thomson", "text": "@Alan Frindell Maybe not if there are layers to the server infrastructure
", "time": "2022-11-09T10:06:47Z"}, {"author": "Alan Frindell", "text": "Got it thanks
", "time": "2022-11-09T10:06:58Z"}, {"author": "Martin Thomson", "text": "@David Schinazi probably want to put \"-masque-\" in the draft name
", "time": "2022-11-09T10:07:45Z"}, {"author": "Randell Jesup", "text": "+1 to useful.
", "time": "2022-11-09T10:07:45Z"}, {"author": "Eric Orth", "text": "+1 as useful and appropriate to fit into a recharter of this WG. I have some ideas for further expansions/improvements of this draft, but nothing blocking that can't wait for adoption.
", "time": "2022-11-09T10:10:06Z"}, {"author": "Martin Thomson", "text": "This time zone is better than European time zones...
", "time": "2022-11-09T10:10:52Z"}, {"author": "Randell Jesup", "text": "+1 for recharter as well
", "time": "2022-11-09T10:17:10Z"}, {"author": "Ian Swett", "text": "+1 to reconsidering the 1:1 mapping of VCIDs to CIDs
", "time": "2022-11-09T10:26:50Z"}, {"author": "Benjamin Schwartz", "text": "I wish we could model this as, like, a REST API controlling a TURN server, instead of a wacky layer-crossing thing on the HTTP/3 UDP association.
", "time": "2022-11-09T10:26:52Z"}, {"author": "Kazuho Oku", "text": "I think there's chance taht this proposal actually ossifies QUIC, because it assumes that an intermediary can generate CIDs.
", "time": "2022-11-09T10:26:59Z"}, {"author": "David Schinazi", "text": "CIDs are part of the invariants though
", "time": "2022-11-09T10:27:21Z"}, {"author": "Alex Chernyakhovsky", "text": "@Benjamin Schwartz I don't think you can get the performance demonstrated without a layer-crossing thing
", "time": "2022-11-09T10:27:33Z"}, {"author": "Martin Thomson", "text": "CC might be managed by doing some accounting, even if there is no control loop involved
", "time": "2022-11-09T10:27:36Z"}, {"author": "Kazuho Oku", "text": "It is my understanding that QUIC Invariants assume that CID can be generated in a version specific way that the endpoints agree.
", "time": "2022-11-09T10:27:38Z"}, {"author": "Ian Swett", "text": "You could use a zero-length VCID if you didn't need a CID.
", "time": "2022-11-09T10:27:50Z"}, {"author": "Martin Thomson", "text": "That's right Kazuho
", "time": "2022-11-09T10:27:50Z"}, {"author": "Tommy Pauly", "text": "What ossification would there be, if the CIDs follow the invariants?
", "time": "2022-11-09T10:28:13Z"}, {"author": "Kazuho Oku", "text": "An extreme example would be a QUIC version using different CID for each packet being sent.
", "time": "2022-11-09T10:28:34Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky I think you can, by just running the forwarder as a separate thing from the HTTP origin. The only issue I see is the handling of long-header packets.
", "time": "2022-11-09T10:28:51Z"}, {"author": "Tommy Pauly", "text": "I see. The client could theoretically have capsules for each new CID =) but that could get out of hand.
", "time": "2022-11-09T10:29:02Z"}, {"author": "Alex Chernyakhovsky", "text": "@Benjamin Schwartz I don't see how that's possible here; isn't part of the win bypassing the outer connection's cryptography?
", "time": "2022-11-09T10:29:24Z"}, {"author": "Martin Thomson", "text": "@Kazuho Oku I think that what this really needs is an API where the client can request new CIDs from the proxy, which would allow this to work...mostly
", "time": "2022-11-09T10:29:25Z"}, {"author": "Tommy Pauly", "text": "Yeah, the register capsules are effectively ways to request a new CID from the proxy today, but happy to get that tweaked
", "time": "2022-11-09T10:29:56Z"}, {"author": "Alex Chernyakhovsky", "text": "The draft abstract says
\n\n", "time": "2022-11-09T10:30:01Z"}, {"author": "Benjamin Schwartz", "text": "packets can be forwarded using an HTTP/3 proxy rather than being re-encapsulated and re-encrypted
\n
@Alex Chernyakhovsky Yes, the forwarder is just a \"QUIC CID translator\". My point is to remove the assumption that this forwarding function lives on the same UDP association as an HTTP/3 connection. It's more like a separate network service that you happen to be controlling using an HTTP API.
", "time": "2022-11-09T10:30:39Z"}, {"author": "Alex Chernyakhovsky", "text": "At that point, why not just encapsulate using GUE...? Use H3 as the control channel and use an actual encapsulation protocol
", "time": "2022-11-09T10:31:20Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky Because GUE has nonzero MTU overhead. But yes, that's my mental model.
", "time": "2022-11-09T10:31:51Z"}, {"author": "Alex Chernyakhovsky", "text": "QUIC-as-encap also has nonzero MTU overhead here
", "time": "2022-11-09T10:32:05Z"}, {"author": "Benjamin Schwartz", "text": "Also then you don't have to use HTTP/3 as the control channel; you can use HTTP/1.1.
", "time": "2022-11-09T10:32:07Z"}, {"author": "Tommy Pauly", "text": "@Ben part of this is that the network observer sees just one QUIC connection from the client to the proxy
", "time": "2022-11-09T10:32:11Z"}, {"author": "Benjamin Schwartz", "text": "@Tommy Pauly I don't see why that matters. The observer presumably knows you are using this forwarder.
", "time": "2022-11-09T10:32:46Z"}, {"author": "Tommy Pauly", "text": "@Martin there are use cases that don't require re-encryption and don't mind the traffic analysis. For example, if the proxy isn't about privacy, but is a remote access VPN, forwarding onto an internal network works fine.
", "time": "2022-11-09T10:33:30Z"}, {"author": "Alex Chernyakhovsky", "text": "@Tommy Pauly has anyone thought about the security considerations around this effectively turning any implementing proxy into (effectively) a UDP open relay?
", "time": "2022-11-09T10:33:31Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky Does it? I believe there is no \"encapsulation\" here, and there is zero per-packet overhead.
", "time": "2022-11-09T10:33:42Z"}, {"author": "Martin Thomson", "text": "Also, I find the presentation of this draft very difficult to use.
", "time": "2022-11-09T10:33:45Z"}, {"author": "Benjamin Schwartz", "text": "Maybe it adds overhead if the CIDs get longer...
", "time": "2022-11-09T10:34:12Z"}, {"author": "Martin Thomson", "text": "It talks about proxy state, but doesn't talk about what happens (i.e., Eric's slide)
", "time": "2022-11-09T10:34:12Z"}, {"author": "Alex Chernyakhovsky", "text": "@Benjamin Schwartz Unless I am grossly misunderstanding this draft, there's still an outer QUIC header from client->proxy
", "time": "2022-11-09T10:34:15Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky Not in forwarder mode, no. Just a CID<->VCID mapping table.
", "time": "2022-11-09T10:34:38Z"}, {"author": "Tommy Pauly", "text": "@Alex there isn't any extra outer header
", "time": "2022-11-09T10:34:39Z"}, {"author": "Martin Thomson", "text": "@Tommy Pauly that might be fine, but people make similar arguments about integrity-only TLS all the time
", "time": "2022-11-09T10:35:00Z"}, {"author": "Kazuho Oku", "text": "@Tommy I think one way of fixing the invariants issue might be to change this proposal to a UDP forwarding mechanism, that routes UDP packets as they are, with added prefix used for identifying connections.
", "time": "2022-11-09T10:35:44Z"}, {"author": "Kazuho Oku", "text": "All we need is a identifier, I am not sure if there is a reason to rewrite CID field of QUIC when we can achieve the same thing by prepending an ID to a UDP packet
", "time": "2022-11-09T10:36:25Z"}, {"author": "Tommy Pauly", "text": "@Martin I agree that integrity-only TLS isn't good. But if from a security and traffic analysis perspective, you are OK with whatever your end to end QUIC connection already has (with TLS 1.3 and QUIC encryption, etc) and you just want to bounce through a relay on the way in order to have access to some resources, or to swap your IPs, then this mode is useful. If that's not the case, just don't use the mode.
", "time": "2022-11-09T10:36:46Z"}, {"author": "Tommy Pauly", "text": "@Kazuho yeah, I like that \u2014 just append a proxy-chosen ID it can use for load balancing rather than replacing the target CID?
", "time": "2022-11-09T10:37:28Z"}, {"author": "Kazuho Oku", "text": "@Tommy exactly
", "time": "2022-11-09T10:37:41Z"}, {"author": "Martin Thomson", "text": "I'm not thrilled with the idea of an append-only ID - it creates linkability.
", "time": "2022-11-09T10:37:52Z"}, {"author": "Martin Thomson", "text": "Maybe that is OK in some contexts, but it shouldn't be the default
", "time": "2022-11-09T10:38:01Z"}, {"author": "Tommy Jensen", "text": "Hey Ben, if this is your UI, take as the most nit-picky bug report ever that IPsec is supposed to be IPsec, not IPSec (much to the chagrin of my autocorrect on anything with only two initial captial letters)
", "time": "2022-11-09T10:38:07Z"}, {"author": "Tommy Pauly", "text": "Ah the IPsec capitalization issues... we had to fix the Apple style guide on that a few years ago
", "time": "2022-11-09T10:38:39Z"}, {"author": "Martin Thomson", "text": "ah, so..., centralization ?
", "time": "2022-11-09T10:38:52Z"}, {"author": "Kazuho Oku", "text": "@Martin I think I get the concern but we are talking about forwarding packets without reencryption, so I'm not sure if that actually matters.
", "time": "2022-11-09T10:38:55Z"}, {"author": "Martin Thomson", "text": "@Kazuho Oku like I said, I don't think that should be a default
", "time": "2022-11-09T10:39:20Z"}, {"author": "Kazuho Oku", "text": "Yeah maybe it's better to phrase that the linkability problem of this protocol depends on how the proxy generates and retires CIDs.
", "time": "2022-11-09T10:40:52Z"}, {"author": "Martin Thomson", "text": "DISPATCH
", "time": "2022-11-09T10:42:41Z"}, {"author": "Eric Orth", "text": "+1 for DISPATCH. Yes, I should have thought of that.
", "time": "2022-11-09T10:43:53Z"}, {"author": "Tommy Jensen", "text": "the masque:: scheme seems like a good idea for click-through UX, but I hope even if that is included that https:: is still supported for clients who don't implement right away (config can also be headless via remote management)
", "time": "2022-11-09T10:45:46Z"}, {"author": "Randell Jesup", "text": "+1 to DISPATCH too
", "time": "2022-11-09T10:46:18Z"}, {"author": "Tommy Pauly", "text": "But we can have a separate app that just configures the URIs
", "time": "2022-11-09T10:46:46Z"}, {"author": "Tommy Jensen", "text": "(it still makes to me to consolidate config as this draft proposes even if the UI is never used, as remote ocnfig being simplified is still a good thing
", "time": "2022-11-09T10:46:50Z"}, {"author": "Tommy Jensen", "text": "If nothing else, easier to deploy (changes can be made at service endpoint without requiring endpoint updates)
", "time": "2022-11-09T10:47:09Z"}, {"author": "Tommy Pauly", "text": "Right, we should be able to have many, many relay configs
", "time": "2022-11-09T10:48:05Z"}, {"author": "Tommy Jensen", "text": "Hmm, many configs per key does make sense. Still lets single config per key exist anyway.
", "time": "2022-11-09T10:49:18Z"}, {"author": "Martin Thomson", "text": "I'm not really that concerned about CNAME cloaking in a world where we have state partitioning.
", "time": "2022-11-09T10:53:12Z"}, {"author": "Martin Thomson", "text": "I'm more concerned about getting ECH
", "time": "2022-11-09T10:53:30Z"}, {"author": "Martin Thomson", "text": "for which you really do need to have the client doing the name resolution
", "time": "2022-11-09T10:53:59Z"}, {"author": "Alex Chernyakhovsky", "text": "Why do we need the client doing the name resolution there? Are you worried about the proxy blocking the DNS queries for ECH keys?
", "time": "2022-11-09T10:54:57Z"}, {"author": "Martin Thomson", "text": "This seems like an extraordinarily narrow solution
", "time": "2022-11-09T10:55:28Z"}, {"author": "Martin Thomson", "text": "@Alex Chernyakhovsky I'm just talking about ensuring that the client has ECH configs before it establishes a connection.
", "time": "2022-11-09T10:55:59Z"}, {"author": "Alex Chernyakhovsky", "text": "So would you prefer to see, e.g., masque proxies letting you tunnel DNS or DoT/DoH and the client do that?
", "time": "2022-11-09T10:56:28Z"}, {"author": "Martin Thomson", "text": "Why not just provide a DoH service and maybe put RRsets in some capsules.
", "time": "2022-11-09T10:56:52Z"}, {"author": "Eric Orth", "text": "I'd much rather the client did its own DNS and sent the DNS queries through the proxy. If only we had a nifty new proxyish solution optimized for the privacy needs of DNS. (For those unaware, I'm talking about OHTTP.)
", "time": "2022-11-09T10:57:04Z"}, {"author": "Alex Chernyakhovsky", "text": "I think that would make plenty of sense, even if the DoH server is just forwarding the queries to the proxy's local resolver.
", "time": "2022-11-09T10:57:23Z"}, {"author": "James Gruessing", "text": "Mapping all potential proxy status codes to DNS error (and non-error \"task failed successfully\") type answers would need to be explicitly defined right?
", "time": "2022-11-09T10:57:26Z"}, {"author": "Martin Thomson", "text": "CONNECT-UDP to example.com and also make HTTPS query using DoH about example.com; you can't send the Initial until you have the ECH config
", "time": "2022-11-09T10:57:33Z"}, {"author": "Peter Thatcher", "text": "Some late input on \"Proxying Listener UDP\" and TURN (sorry... it's pretty early in the morning for me): TURN has a concept of \"permissions\" where only specific remote IP addresses are allowed to send packets into the local client (See RFC 5576 sections 2.3 and 8). If such a mechanism were added to \"Proxying Listener UDP\", then I believe it could replace TURN. WebRTC would be able use HTTP proxies that support \"Proxying Listener UDP\" where it currently uses TURN, which would be very interesting since it will likely be easier and more common to deploy HTTP servers with \"Proxying Listener UDP\" than TURN servers. I can add this comment to this list if this is the wrong place/time to bring it up.
", "time": "2022-11-09T10:58:14Z"}, {"author": "Tommy Jensen", "text": "ADD WG would be a tough sell MT; the charter there is trying to be narrowed to \"server properties\" I'm not sure they would see this as in scope
", "time": "2022-11-09T11:00:25Z"}, {"author": "Tommy Jensen", "text": "Agree a wider solution scope should be considered tho
", "time": "2022-11-09T11:00:39Z"}, {"author": "Martin Thomson", "text": "@Tommy Jensen yeah, DNSOP perhaps
", "time": "2022-11-09T11:00:58Z"}, {"author": "Lucas Pardue", "text": "Now-see-me-now-you-cname
", "time": "2022-11-09T11:01:08Z"}, {"author": "Martin Thomson", "text": "I have no interest in a narrow design that doesn't do ECH. CNAME cloaking isn't worth a bespoke design when we have a real need for ECH configs.
", "time": "2022-11-09T11:01:41Z"}, {"author": "Tommy Pauly", "text": "Part of my concern with the broader DNS records is that it gets quite complex quite quickly, and I think it will take a lot of time and work to get it right. We should do it, but it will take time.
", "time": "2022-11-09T11:02:05Z"}, {"author": "Benjamin Schwartz", "text": "@Tommy Pauly Can we just put the IP in next-hop instead? Mixing IPs and names in this list strikes me as less than ideal.
@Ben, sure we could put the IP in next-hop and have the new parameter be CNAME only
", "time": "2022-11-09T11:02:36Z"}, {"author": "Martin Thomson", "text": "All standardization takes time
", "time": "2022-11-09T11:02:40Z"}, {"author": "Martin Thomson", "text": "Oh, no.
", "time": "2022-11-09T11:03:50Z"}, {"author": "Tommy Jensen", "text": "Agreed, this is not something we should rush. Anything DNS in 2022+ that only works for A/AAAA/CNAME is lacking. +1 to dnsop
", "time": "2022-11-09T11:04:18Z"}, {"author": "Kazuho Oku", "text": "packet numbers in cleartext!
", "time": "2022-11-09T11:05:45Z"}, {"author": "Alex Chernyakhovsky", "text": "@Tommy Pauly Is there a performance reason to have the server do the DNS resolution rather than exposing a DoH endpoint or something?
", "time": "2022-11-09T11:05:45Z"}, {"author": "Tommy Pauly", "text": "@Alex, yes absolutely.
", "time": "2022-11-09T11:06:18Z"}, {"author": "Benjamin Schwartz", "text": "In general, it's better for the proxy to do the final name->IP resolution, whereas it's better for the client to do the HTTPS/SVCB lookup.
", "time": "2022-11-09T11:06:33Z"}, {"author": "Alex Chernyakhovsky", "text": "Neither of those is obvious to me.
", "time": "2022-11-09T11:07:18Z"}, {"author": "Benjamin Schwartz", "text": "(In my view, we have a solution for the ECHConfigs problem in MASQUE: DoH!)
", "time": "2022-11-09T11:07:30Z"}, {"author": "Martin Thomson", "text": "Maybe this can be taken to the PANRG as a counterexample: of path ignorant networking
", "time": "2022-11-09T11:08:00Z"}, {"author": "Alex Chernyakhovsky", "text": "Having the client do HTTPS/SVCB lookups directly could leak information they may not want to share; having the proxy lookup IP is useful mostly from the proxy's network address perspective, which is why I asked about it offering a Doh endpoint
", "time": "2022-11-09T11:08:17Z"}, {"author": "Tommy Pauly", "text": "@Ben, yes the remote IP should be selected by the proxy
", "time": "2022-11-09T11:08:20Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky Yes, that's why you want a DoH server affiliated with the proxy.
", "time": "2022-11-09T11:09:04Z"}, {"author": "Martin Thomson", "text": "@Tommy Pauly yes, the proxy needs to choose which RR from the RRset to act on when it comes to establishing the flow, but the client needs to receive all the RRs (what about DNSSEC?)
", "time": "2022-11-09T11:09:27Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz I don't think that DoH is necessarily the right answer here, the more I think about it.
", "time": "2022-11-09T11:09:55Z"}, {"author": "Benjamin Schwartz", "text": "@Martin Thomson The DNSSEC question seems like a good example of why we shouldn't be trying to pass bits of DNS info back from the proxy to the client, and should just use DoH.
", "time": "2022-11-09T11:10:16Z"}, {"author": "Tommy Pauly", "text": "@Martin Yeah, giving the client the RRs would be good. I think that's the right solution for getting the full info the client, while the proxy still sets up TCP/UDP sockets
", "time": "2022-11-09T11:10:59Z"}, {"author": "Benjamin Schwartz", "text": "I don't think the client has any use for RRs that it's not using.
", "time": "2022-11-09T11:11:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "@Kazuho Oku the sequence number is not exposed. It\u2019s added to the Quic tunnel between the client and proxy. Thanks inside that R2-D2 connnection
", "time": "2022-11-09T11:11:38Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz I think that I might disagree about DoH there. The proxy needs to be involved in decision-making when it comes to setting up flows.
", "time": "2022-11-09T11:12:54Z"}, {"author": "Mirja K\u00fchlewind", "text": "@David Schinazi I would assume that any number you have reorder packet belong to different flows. That\u2019s a problem because of head of line blocking. That\u2019s not a problem hear because you have different datagram \u201cstream\u201d
", "time": "2022-11-09T11:13:26Z"}, {"author": "Benjamin Schwartz", "text": "Yes. That's why the client should give the final TargetName to the proxy for connection establishment, rather than fully resolving to A/AAAA.
", "time": "2022-11-09T11:13:30Z"}, {"author": "Mirja K\u00fchlewind", "text": "also you can always use streams for reordering which will be the alternative for 3GPP
", "time": "2022-11-09T11:13:57Z"}, {"author": "Martin Thomson", "text": "That might work. Maybe.
", "time": "2022-11-09T11:13:59Z"}, {"author": "Kazuho Oku", "text": "@Mirja my point is that this goes against the reasoning behind us agreeing that PN should not be exposed, because intermediaries trying to \"correct\" ordering actually decreases performance sometimes.
", "time": "2022-11-09T11:14:00Z"}, {"author": "Benjamin Schwartz", "text": "This is specified in the HTTPS/SVCB draft: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-11#section-3.2
", "time": "2022-11-09T11:14:17Z"}, {"author": "Tommy Jensen", "text": "HTTP history has given me an allergy to the work \"prioritization\". Do we have data showing the improvement to real-world flows?
", "time": "2022-11-09T11:14:42Z"}, {"author": "Kazuho Oku", "text": "+1 to inside masque
", "time": "2022-11-09T11:15:51Z"}, {"author": "Mirja K\u00fchlewind", "text": "@kazuho but it doesn't expose anything. it's what you do within the tunnel connection. As I just say you can also just use stream and do the same reordering.
", "time": "2022-11-09T11:16:02Z"}, {"author": "Alan Frindell", "text": "Meta uses H3 prioritization and has seen real world wins
", "time": "2022-11-09T11:16:06Z"}, {"author": "David Schinazi", "text": "@Ben the queue is in the browser between the JavaScript process and the QUIC stack
", "time": "2022-11-09T11:16:36Z"}, {"author": "Martin Thomson", "text": "@David Schinazi isn't that just local?
", "time": "2022-11-09T11:16:47Z"}, {"author": "Tommy Jensen", "text": "@Alan Frindell would be useful to see this shared here (if you have and I've missed it, would appreciate a pointer)
", "time": "2022-11-09T11:17:07Z"}, {"author": "Randell Jesup", "text": "Priorities are certainly something WebTransport cares about; W3 will have an ask to IETF about priorities in the WebTransport WG meeting.
", "time": "2022-11-09T11:18:15Z"}, {"author": "Michael Welzl", "text": "Sorry, just trying to understand this: this is about the client telling the server about priorities, right? And not within a very specific application, where this signaling could be a part of the app itself, but for \"general\" HTTP use. So ... what are these \"general HTTP\" cases where a client knows better than the server?
", "time": "2022-11-09T11:19:09Z"}, {"author": "Alan Frindell", "text": "@Tommy Jensen : Some results were shared publicly last year, we've seen more wins internally since then.
\nhttps://lists.w3.org/Archives/Public/ietf-http-wg/2021AprJun/0068.html
inside MASQUE, I can understand, BTW, as one might want to multiplex a bunch of various things... perhaps even separate applications
", "time": "2022-11-09T11:20:09Z"}, {"author": "David Schinazi", "text": "@MT yeah that queue's local. I think there's another queue in intermediaries too when present
", "time": "2022-11-09T11:20:18Z"}, {"author": "Kazuho Oku", "text": "@Mirja The question is if we think it is a good idea for intermediaries to withhold packets to fix reordering?My recollection is that we did not think that is the case when we designed QUIC, and the question is if we should encourage middleboxes do that for UDP (mostly QUIC).
", "time": "2022-11-09T11:20:26Z"}, {"author": "Martin Thomson", "text": "+1 to concentrating on CONNECT-TCP
", "time": "2022-11-09T11:20:50Z"}, {"author": "Tommy Pauly", "text": "useability -> usability ?
", "time": "2022-11-09T11:21:43Z"}, {"author": "Michael Welzl", "text": "@Alan Frindell the example you link to is specific to Instagram. I don't understand why you couldn't use an Instagram-specific signal (app layer) for this?
", "time": "2022-11-09T11:23:17Z"}, {"author": "Benjamin Schwartz", "text": "@Tommy Pauly @Martin Thomson FWIW the templated \"HTTP request proxy\" thing is principally motivated by enabling standardized/interchangeable OHTTP relays. Right now, OHTTP relays effectively have to be hardcoded into the client implementation due to a lack of standardized URL mapping.
", "time": "2022-11-09T11:23:20Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz I deliberately didn't do that in OHTTP...
", "time": "2022-11-09T11:24:04Z"}, {"author": "Benjamin Schwartz", "text": "@Martin Thomson You want to talk about consolidation pressure ... there is literally no way for the user to change the OHTTP relay without this.
", "time": "2022-11-09T11:24:33Z"}, {"author": "Martin Thomson", "text": "+1 to narrowing scope to avoid taking on all the work of the IETF
", "time": "2022-11-09T11:24:45Z"}, {"author": "Marcus Ihlar", "text": "@Kazuho Oku This is a fair point. One note though is that Masque already allows you to encode datagrams over QUIC streams which could lead to packets being withheld as long as the capsule stream has gaps.
", "time": "2022-11-09T11:25:29Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz why? One relay per gateway is not so bad.
", "time": "2022-11-09T11:25:38Z"}, {"author": "Martin Thomson", "text": "It's a pair of resources, likely a pair of servers.
", "time": "2022-11-09T11:25:54Z"}, {"author": "Alan Frindell", "text": "@Michael Welzl : we could have used our own proprietary prioritization scheme and signaling mechanism I suppose. The data was shared to validate the urgency/incremental model was one that can be effective. I have a lot of thoughts on prioritization, and including that capturing the intent from the application is one of the most challenging bits. Having a common and easy to explain API to product people, as well as a simple implementation you can live with in your transport stack are important to getting wins.
", "time": "2022-11-09T11:26:17Z"}, {"author": "Benjamin Schwartz", "text": "@Martin Thomson Why can't I choose Mullvad as my OHTTP Relay?
", "time": "2022-11-09T11:26:33Z"}, {"author": "Martin Thomson", "text": "Because the Gateway needs to have a very specific relationship with the relay.
", "time": "2022-11-09T11:27:12Z"}, {"author": "Benjamin Schwartz", "text": "I think OHTTP's non-collusion guarantee is much stronger if the relay and gateway aren't affiliated
", "time": "2022-11-09T11:27:37Z"}, {"author": "Martin Thomson", "text": "You are entitled to think that, yes.
", "time": "2022-11-09T11:27:49Z"}, {"author": "Benjamin Schwartz", "text": "Not without a configuration mechanism!
", "time": "2022-11-09T11:28:04Z"}, {"author": "Michael Welzl", "text": "@Alan Frindell fair enough, I suppose; thanks for clarifying (I was only trying to understand).
", "time": "2022-11-09T11:29:15Z"}, {"author": "Tommy Jensen", "text": "I'm a simple IETFer: I see a proposal to let a service which collects no PII for account setup act as a relay party, I upvote.
", "time": "2022-11-09T11:29:21Z"}, {"author": "Alan Frindell", "text": "@Michael Welzl : I'm a priority enthusiast. Come find me anytime to discuss :)
", "time": "2022-11-09T11:29:51Z"}, {"author": "Lucas Pardue", "text": "Regarding priorities: I didn't do a good job of clearly articulating that IMO the problem is around scheduling competing flows of data when there is a bandwidth bottleneck. Assume a proxy has a fast upstream to targets and a slower downstream to clients. The bottleneck will be reflected in the congestion controller, which affects stream and datagrams equally. Multiple CONNECT-UDP streams will contend for that shared window and right now we don't have a common language for how to express the relative priorities of those things, such that sending over the bottleneck can be used most effectively.
", "time": "2022-11-09T11:30:04Z"}, {"author": "Kazuho Oku", "text": "@Marcus Middleboxes can certainly guess the sent order of packets and trying to recover them. There's nothing that stops them for doing that. The question is if we want to encourage such behavior (when we decided to not in QUIC v1).
", "time": "2022-11-09T11:31:01Z"}, {"author": "Lucas Pardue", "text": "The sender is always in control of this, and can do clever stuff. But if all it sees is opaque CONNECT information flows, its very restricted in its decision making - worse than a conventional H3 server.
", "time": "2022-11-09T11:31:40Z"}, {"author": "Hang Shi", "text": "What is the transparent modification of the proxies content?
", "time": "2022-11-09T11:32:55Z"}, {"author": "Martin Thomson", "text": "A proxy can (and should) just drop datagrams that don't fit into a narrow pipe.
", "time": "2022-11-09T11:32:59Z"}, {"author": "Benjamin Schwartz", "text": "@Lucas Pardue I don't think your draft addresses that use case. The client is the one that knows the relative priorities, but the proxy is the one that has to decide how to mark each datagram. Also, this is another \"local\" case where the proxy is talking to itself.
", "time": "2022-11-09T11:33:01Z"}, {"author": "Chris Box", "text": "+1 to an informational document that describes a MASQUE proxy. Best to do it inside the working group.
", "time": "2022-11-09T11:34:00Z"}, {"author": "Lucas Pardue", "text": "The other thing that sprang to mind is, since its about scheduling, we could also accomodate QUIC-aware forwarding and push down dispatch behaviour into layers below QUIC (like bpf, kernel or NIC queues etc)
", "time": "2022-11-09T11:34:00Z"}, {"author": "Benjamin Schwartz", "text": "Also, the inner congestion controller(s) should solve this problem anyway.
", "time": "2022-11-09T11:34:14Z"}, {"author": "Alan Frindell", "text": "@Martin Thomson : what about a sending endpoint with no CWND?
", "time": "2022-11-09T11:34:28Z"}]