[{"author": "Benjamin Schwartz", "text": "

Does this require using Connection IDs in a situation where they would normally be zero-length?

", "time": "2023-03-29T00:36:08Z"}, {"author": "Alex Chernyakhovsky", "text": "

Where would a connection id be 0-length?

", "time": "2023-03-29T00:36:43Z"}, {"author": "Benjamin Schwartz", "text": "

I'm a bit fuzzy on QUIC, but my recollection was that Server or Client Connection ID can be 0-length if it's not needed (e.g. if the other endpoint doesn't use mobility).

", "time": "2023-03-29T00:37:38Z"}, {"author": "Alex Chernyakhovsky", "text": "

Situation where it's not needed are very, very rare. A QUIC connection is defined by the connection ID and not the 5-tuple in almost all cases.

", "time": "2023-03-29T00:38:06Z"}, {"author": "Benjamin Schwartz", "text": "

But which connection ID? Do you really need both all the time?

", "time": "2023-03-29T00:38:33Z"}, {"author": "Martin Duke", "text": "

Aren't non-migrating client conn IDs often zero-length?

", "time": "2023-03-29T00:39:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

RFC9000 says \"A zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint. However, multiplexing connections on the same local IP address and port while using zero-length connection IDs will cause failures in the presence of peer connection migration, NAT rebinding, and client port reuse\"

", "time": "2023-03-29T00:39:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

So it seems like a not-great idea for normal connections.

", "time": "2023-03-29T00:39:37Z"}, {"author": "Benjamin Schwartz", "text": "

Thanks Alex. I'm still not 100% clear on the \"usage profiles\" of CIDs in QUIC, but I'm mostly trying to figure out if there's a hidden MTU cost here due to making CIDs longer.

", "time": "2023-03-29T00:40:37Z"}, {"author": "Alex Chernyakhovsky", "text": "

I believe that this draft requires >0 length CIDs, but it doesn't make existing implementations have to use longer CIDs in most cases.

", "time": "2023-03-29T00:41:12Z"}, {"author": "David Schinazi", "text": "

@Alex in IETF QUIC we have CIDs in both directions. zero-length CIDs are very common in the server->client direction

", "time": "2023-03-29T00:41:23Z"}, {"author": "David Schinazi", "text": "

@Ben this is guaranteed to make MTU better because it allows you to skip the 16 byte auth tag

", "time": "2023-03-29T00:42:03Z"}, {"author": "Christian Huitema", "text": "

That means keeping track of how many clients use the same remote peer, and then opening extra UDP sockets if they use zero length CID...

", "time": "2023-03-29T00:43:12Z"}, {"author": "Benjamin Schwartz", "text": "

Yes, it's definitely lower overhead than CONNECT-UDP. I'm just trying to figure out if it's actually zero.

", "time": "2023-03-29T00:43:15Z"}, {"author": "Christian Huitema", "text": "

But then, if they use 1-byte CID, then there is a 1/256 chance of collision...

", "time": "2023-03-29T00:43:38Z"}, {"author": "Christian Huitema", "text": "

What about header protection?

", "time": "2023-03-29T00:44:32Z"}, {"author": "Martin Thomson", "text": "

keys are almost easy here: exporters provide us with a good way to get keying material

", "time": "2023-03-29T00:44:36Z"}, {"author": "Alex Chernyakhovsky", "text": "

Does the encryption here potentially preclude hardware offload? AIUI that was one of the desired properties?

", "time": "2023-03-29T00:45:40Z"}, {"author": "Lucas Pardue", "text": "

do the MASQUE, the monster MASQUE

", "time": "2023-03-29T00:46:58Z"}, {"author": "David Schinazi", "text": "

Oh, and BTW I support adoption

", "time": "2023-03-29T00:48:06Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky I think that as long as we cleave closely to how QUIC does things, it will be possible

", "time": "2023-03-29T00:48:41Z"}, {"author": "David Schinazi", "text": "

@Alex we already need to tell the NIC the CID-CID mapping, so putting a key in there is possible

", "time": "2023-03-29T00:48:52Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Martin Thomson Hopefully! But my understanding is that NIC QUIC offload is still very early days. I haven't seen a working implementation yet, my understanding is e.g., Mellanox CX6 TLS offload is bulk-cipher and has a TLS1.3-capable cipher now, but it's not clear if the NIC is flexible enough to work with QUIC packet framing

", "time": "2023-03-29T00:50:52Z"}, {"author": "Alex Chernyakhovsky", "text": "

So it might require another generation of hardware?

", "time": "2023-03-29T00:51:24Z"}, {"author": "Martin Thomson", "text": "

I'm not going to trivialize the effort required to protect QUIC packets, but this should be possible

", "time": "2023-03-29T00:51:32Z"}, {"author": "David Schinazi", "text": "

Yeah it'll be hard but the closer we are to header protection the happier the hardware will be

", "time": "2023-03-29T00:52:00Z"}, {"author": "Martin Thomson", "text": "

@Martin Duke I think that you probably need to think of the move to this forwarding path as a change in path (with all that entails)

", "time": "2023-03-29T00:52:29Z"}, {"author": "Martin Thomson", "text": "

Cipher agility will need to be worked out as well, but we can probably copy the cipher from the host connection (that is hard from a specification perspective perhaps, but ...)

", "time": "2023-03-29T00:53:22Z"}, {"author": "Christian Huitema", "text": "

Martin Duke has a good point: whoever has the shortest RTT through the bottleneck gets faster.

", "time": "2023-03-29T00:53:40Z"}, {"author": "David Schinazi", "text": "

Yeah re: cipher agility we'll need to cross layers, but we'll need to do that to get the key exporter anyway

", "time": "2023-03-29T00:54:27Z"}, {"author": "Bob Briscoe", "text": "

@martin, On the RTT bias point, a long RTT doesn't go slower than a short RTT unless they are competing in the same bottleneck.

", "time": "2023-03-29T00:54:30Z"}, {"author": "Christian Huitema", "text": "

.. which is exactly the scenario

", "time": "2023-03-29T00:55:00Z"}, {"author": "Kazuho Oku", "text": "

So if I understand correctly, the threat model would be different from traditional masque, even though we use AES-CTR.Because without having nonce generated by the masque server, a active attacker can inject two packets that are identical and figure out to where two identical packets would be sent ... That way, an active attacker can determine the client.

", "time": "2023-03-29T00:55:15Z"}, {"author": "Bob Briscoe", "text": "

@Christian, No. They're usually bottlenecked in each user's access network.

", "time": "2023-03-29T00:55:42Z"}, {"author": "Christian Huitema", "text": "

If the proxy is the bottleneck?

", "time": "2023-03-29T00:56:04Z"}, {"author": "Benjamin Schwartz", "text": "

Note that single-pass length-preserving encryption like header protection is mutable, with pretty weird results. For example, an attacker might be able to flip bits in the connection ID and watch for forwarded packets to determine which flow a packet belongs to.

", "time": "2023-03-29T00:56:07Z"}, {"author": "Martin Thomson", "text": "

Regarding encryption, I have an idea for padding also. But we'll need to steal a bit. Does anyone have an issue with stealing either the short/long bit or the QUIC bit?

", "time": "2023-03-29T00:56:53Z"}, {"author": "Benjamin Schwartz", "text": "

Basically, the encryption threat model is very subtle, and depends a lot on how active the attacker can be

", "time": "2023-03-29T00:57:00Z"}, {"author": "Bob Briscoe", "text": "

@Christian, One would hope the proxy would not be.the b'neck.

", "time": "2023-03-29T00:57:08Z"}, {"author": "Christian Huitema", "text": "

I would ned to study the draft, but the idea of removing encryption for better perf does give me strange feelings...

", "time": "2023-03-29T00:57:17Z"}, {"author": "Christian Huitema", "text": "

@Bob, hope, the well known congestion algorithm...

", "time": "2023-03-29T00:57:45Z"}, {"author": "Martin Duke", "text": "

if the bottleneck is anywhere between client and proxy, I believe my observation applies

", "time": "2023-03-29T00:57:58Z"}, {"author": "Kazuho Oku", "text": "

By remove encryption, masque becomes essentially a routing protocol :-)

", "time": "2023-03-29T00:58:13Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Duke There are _three_ congestion controllers here, so who knows...

", "time": "2023-03-29T00:58:23Z"}, {"author": "Martin Thomson", "text": "

@Kazuho Oku isn't that already a problem when it comes to connection IDs?

", "time": "2023-03-29T00:58:43Z"}, {"author": "Martin Thomson", "text": "

That is, the bit where the routing can be probed.

", "time": "2023-03-29T00:59:31Z"}, {"author": "Peter Thatcher", "text": "

It's not enough to pin the IP. You also need to pin the port.

", "time": "2023-03-29T01:00:07Z"}, {"author": "Kazuho Oku", "text": "

@MT I'm not sure I follow, how would you do that with traditional masque where the entire UDP packet is encrypted?

", "time": "2023-03-29T01:00:29Z"}, {"author": "Bob Briscoe", "text": "

@Martin, A flow can fill your local link whatever its RTT. Yes, there might be common bottlenecks, so indeed, who knows. But network operators normally design their networks to keep the bottleneck at one \"edge\" node.

", "time": "2023-03-29T01:00:38Z"}, {"author": "Christian Huitema", "text": "

@Bob the differences are in the dynamics, not in the asymptotes

", "time": "2023-03-29T01:01:20Z"}, {"author": "Bob Briscoe", "text": "

Yes, but then the differences are less marked.

", "time": "2023-03-29T01:01:47Z"}, {"author": "Christian Huitema", "text": "

capsule!

", "time": "2023-03-29T01:02:35Z"}, {"author": "Christian Huitema", "text": "

Why WebRTC? Why not MoQ?

", "time": "2023-03-29T01:07:30Z"}, {"author": "David Schinazi", "text": "

Sure MoQ as well. We started with what already exists

", "time": "2023-03-29T01:08:22Z"}, {"author": "Peter Thatcher", "text": "

This basically makes MASQUE act like TURN, which could work for anything, not just ICE. SO theoretically it might work for MoQ as well.

", "time": "2023-03-29T01:08:25Z"}, {"author": "Eric Orth", "text": "

I feel like that got hijacked and the queue was ignored.

", "time": "2023-03-29T01:09:32Z"}, {"author": "Peter Thatcher", "text": "

I think ekr's idea of \"only allow in after you allow out\" is also a good approach.

", "time": "2023-03-29T01:10:27Z"}, {"author": "Martin Duke", "text": "

Because I have a one-track mind, I noticed that gluing together this and Tommy's draft, you have a different solution to the QUIC-LB problem with a minimal amount of work

", "time": "2023-03-29T01:10:28Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

I feel like we spent too much time concentrating on the STUN server in the example and not enough time thinking about the \"hey, proxy, can I listen on a UDP port\" side of things.

", "time": "2023-03-29T01:10:29Z"}, {"author": "Alex Chernyakhovsky", "text": "

Martin, how does this solve the QUIC-LB problem?

", "time": "2023-03-29T01:11:27Z"}, {"author": "Eric Orth", "text": "

@Alejandro Sede\u00f1o Isn't the non-stun side of things the whole part about getting the ip/port from the proxy where it is listening?

", "time": "2023-03-29T01:11:59Z"}, {"author": "Alex Chernyakhovsky", "text": "

If I understood ekr correctly the ip/port messaging is the easy part, the hard part is figuring out policy?

", "time": "2023-03-29T01:12:29Z"}, {"author": "Martin Duke", "text": "

All the \"clients\" listen on the VIP port, and use Tommy's capsules to communicate connection IDs to the \"proxy\" (which is the load balancer)

", "time": "2023-03-29T01:12:38Z"}, {"author": "Martin Duke", "text": "

you need some logic to route Initials with no state, but other than that I think it works?

", "time": "2023-03-29T01:12:57Z"}, {"author": "Christian Huitema", "text": "

+1, yes, we want to support that!

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

@Martin Duke you're proposing a quic-specific maglev-like-thing?

", "time": "2023-03-29T01:13:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

Route all IP over QUIC?

", "time": "2023-03-29T01:13:32Z"}, {"author": "Alex Chernyakhovsky", "text": "

Overlay network for the internet?

", "time": "2023-03-29T01:13:40Z"}, {"author": "Lucas Pardue", "text": "

the year is 2030 and every runs on port 443

", "time": "2023-03-29T01:14:01Z"}, {"author": "Eric Orth", "text": "

So I think the real question that needs to be answered before adoption then is whether the protocol will be designed to directly enforce or only support some policy, or if it will just allow everything and leave a note in the draft that a good proxy server should take some steps to set and enforce a reasonable policy.

", "time": "2023-03-29T01:14:41Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

@Eric Orth, yes. I just feel like we spent too much time talking about not needing the STUN server, which sure, but it was just a detail in the specific example. Not needing the STUN server once this capability is in place is great, but we don't need to spend all that time discussing that the example's STUN server is unnecessary.

", "time": "2023-03-29T01:15:04Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Lucas Pardue the year is 2023 and that's already true :)

", "time": "2023-03-29T01:15:09Z"}, {"author": "Lucas Pardue", "text": "

connect and connect-udp effectivaly have similar notes

", "time": "2023-03-29T01:15:13Z"}, {"author": "Christian Huitema", "text": "

The paranoidsfirewals are going to MITM QUIC. For everyone else, the features should be there!

", "time": "2023-03-29T01:15:16Z"}, {"author": "Ted Hardie", "text": "

@chairs the network in-room is somewhat flakey for me, which is making it hard to raise your hand in the tool. You may want to keep that in mind if people get up without it.

", "time": "2023-03-29T01:15:34Z"}, {"author": "Benjamin Schwartz", "text": "

The funny thing is that the TURN _protocol_ doesn't provide this guarantee at all. The network administrator just has to take it on faith that anyone who implements TURN actually enforces this policy.

", "time": "2023-03-29T01:15:43Z"}, {"author": "Martin Duke", "text": "

@Alex let's chat on this offline

", "time": "2023-03-29T01:16:11Z"}, {"author": "Hang Shi", "text": "

SD-WAN over QUIC?

", "time": "2023-03-29T01:18:09Z"}, {"author": "Martin Thomson", "text": "

Kazuho Oku said:

\n
\n

@MT I'm not sure I follow, how would you do that with traditional masque where the entire UDP packet is encrypted?

\n
\n

I see where you are getting. Yes, the tunneled version ensures that the proxy validates an auth tag. Clearly I was wrong there :)

", "time": "2023-03-29T01:18:59Z"}, {"author": "Ted Hardie", "text": "

I'm seriously confused about why hybrid arq and friends aren't doing this for the cellular network that looks like the driving use case here.

", "time": "2023-03-29T01:21:13Z"}, {"author": "Martin Thomson", "text": "

The amount of ASCII art on slides is too high.

", "time": "2023-03-29T01:21:16Z"}, {"author": "Lucas Pardue", "text": "

would you rather a bitmap of an SVG rendering?

", "time": "2023-03-29T01:21:51Z"}, {"author": "Martin Thomson", "text": "

until we get vector displays, I'll settle for that

", "time": "2023-03-29T01:22:33Z"}, {"author": "Alex Chernyakhovsky", "text": "

You mean until we get vector displays again?

", "time": "2023-03-29T01:22:43Z"}, {"author": "Hang Shi", "text": "

If it is set to RTT2/RTT1, you do not need to negotiation the limit, right? Proxy can determine it by itself

", "time": "2023-03-29T01:22:57Z"}, {"author": "Eric Rescorla", "text": "

How about ASCII art of a bitmap of SVG rendering

", "time": "2023-03-29T01:23:08Z"}, {"author": "Benjamin Schwartz", "text": "

@Hang Shi The proxy doesn't know RTT2 unless the client tells it somehow.

", "time": "2023-03-29T01:23:23Z"}, {"author": "Christian Huitema", "text": "

We use to have vector displays, back in the 80's. Huge things with large fluorescent tubes...

", "time": "2023-03-29T01:23:36Z"}, {"author": "Hang Shi", "text": "

Oh. I see

", "time": "2023-03-29T01:23:40Z"}, {"author": "Christian Huitema", "text": "

(Back in the 70's actually)

", "time": "2023-03-29T01:23:50Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz why would the proxy not know the RTT on the connections it terminates (on either end)?

", "time": "2023-03-29T01:25:10Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Thomson This is CONNECT-UDP, so the proxy does not terminate any connection to the target.

", "time": "2023-03-29T01:25:37Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Ted Hardie for mobile network we are discussing a bit if we could disable HARQ and use a higher layer machismo instead where the client can decide to use it or not in order to reduce delays for unreliable transmission

", "time": "2023-03-29T01:26:06Z"}, {"author": "Eric Rescorla", "text": "

Well, most of those things in the 80s were actually raster displays with a sort-of-vector CRT

", "time": "2023-03-29T01:26:16Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz I guess it can only guess.

", "time": "2023-03-29T01:26:18Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Thomson It can use the spin bit...

", "time": "2023-03-29T01:26:32Z"}, {"author": "Eric Rescorla", "text": "

But of course there used to be actual non-raster displays. Like Evans and Sutherland IIRC

", "time": "2023-03-29T01:26:34Z"}, {"author": "Lucas Pardue", "text": "

the whole monitoring characterisitics of UDP thing is not great for proxy

", "time": "2023-03-29T01:26:38Z"}, {"author": "Lucas Pardue", "text": "

easy to design bad heuristics that upset the members of the EDM

", "time": "2023-03-29T01:27:06Z"}, {"author": "Eric Rescorla", "text": "

If you divide the RTTs by each other, you get a dimensionless value :)

", "time": "2023-03-29T01:27:16Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz my point exactly. Or it can do the thing that was suggested that didn't need spin

", "time": "2023-03-29T01:27:18Z"}, {"author": "Eric Orth", "text": "

I'm having trouble imagining the scenarios where it is desirable for the client to have this kind of control over what seems to me to be a matter between the proxy and the target. But maybe I just don't understand the relevant usecases since I'm mostly dealing with cases where there is significant offline coordination between client and proxy(ies).

", "time": "2023-03-29T01:29:51Z"}, {"author": "Christian Huitema", "text": "

+1 Eric. For what it is worth, I actually implement a selective datagram retransmission mechanism in picoquic a year ago.

", "time": "2023-03-29T01:31:52Z"}, {"author": "Alex Chernyakhovsky", "text": "

Out of curiosity, @Christian Huitema for what purpose?

", "time": "2023-03-29T01:32:14Z"}, {"author": "Martin Thomson", "text": "

What is most interesting here is that networks do this sort of thing already, based on an understanding of radio performance. Why that would be replicated at this layer escapes me. Though the idea that this might be brought under endpoint control is interesting.

", "time": "2023-03-29T01:32:22Z"}, {"author": "Christian Huitema", "text": "

There is an alternative: send the IP packet in a unidir stream by itself -- reliability, no head-of-queue issue.

", "time": "2023-03-29T01:33:37Z"}, {"author": "Benjamin Schwartz", "text": "

It's a very tricky 3 (4?) party problem, between the client, mobile network, proxy, and target, each of whom has different relevant knowledge. I don't think \"retransmission\" is the right hammer for this very wiggly problem.

", "time": "2023-03-29T01:33:42Z"}, {"author": "Benjamin Schwartz", "text": "

Also let's not forget about the possibility of implementing an accelerator that works great because it's stealing bandwidth from other flows.

", "time": "2023-03-29T01:36:27Z"}, {"author": "Bob Briscoe", "text": "

@Ted, a para from the L4S architecture [RFC9330]:A combination of Recent Acknowledgement (RACK) [RFC8985], L4S, and link retransmission without resequencing could repair transmission errors without the head of line blocking delay usually associated with link-layer retransmission [UnorderedLTE] [RFC9331]

", "time": "2023-03-29T01:39:30Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Ted Hardie we were actually more interested in the case where we use ARQ but without re-ordering but we also discussed to disable ARQ completely because there is actually another reliability layer underneath, so even without ARQ the loss is not that high

", "time": "2023-03-29T01:42:02Z"}, {"author": "Ted Hardie", "text": "

@Bob are you suggesting a similar mechanism at this layer? Or pointing out that that RLP is a data reference (which is certainly true, and I recognize that things have moved on).

", "time": "2023-03-29T01:42:34Z"}, {"author": "Bob Briscoe", "text": "

Sry, don't undewrstand 'data reference question?

", "time": "2023-03-29T01:43:22Z"}, {"author": "Bob Briscoe", "text": "

Can you rephrase?

", "time": "2023-03-29T01:44:07Z"}, {"author": "Ted Hardie", "text": "

@Mirja disabling ARQ because you have an existing mechanism makes some sense, when the UE is aware of it, but that's essentially what I was pointing out--if this is intended to create increased reliability, it is doing so in the presence of an existing reliability layer (to wit HARQ and friends)

", "time": "2023-03-29T01:44:14Z"}, {"author": "Lucas Pardue", "text": "

Can this draft fix the IETF wifi problems?

", "time": "2023-03-29T01:44:16Z"}, {"author": "Benjamin Schwartz", "text": "

Can this draft keep me connected to MeetEcho?

", "time": "2023-03-29T01:44:45Z"}, {"author": "Eric Rescorla", "text": "

Nothing can fix the IETF WiFi problems

", "time": "2023-03-29T01:44:45Z"}, {"author": "Ted Hardie", "text": "

@Bob I just meant that RLP is an old CDMA term from 1990 for this basic idea, and there are much newer terms (and variants).

", "time": "2023-03-29T01:45:00Z"}, {"author": "Bob Briscoe", "text": "

I guess my main point is to encourage local repair over any lossy part of a network, but not resequencing - leave that right until as late as poss in the receiver. And the widespread deployment of RACK now allows this to happen.

", "time": "2023-03-29T01:47:29Z"}, {"author": "Bob Briscoe", "text": "

where receiver = app endpoint

", "time": "2023-03-29T01:48:12Z"}, {"author": "Ted Hardie", "text": "

@Bob I see, thanks for the clarification.

", "time": "2023-03-29T01:48:24Z"}, {"author": "Martin Thomson", "text": "

FEC by duplication is a tried and true method

", "time": "2023-03-29T01:48:53Z"}, {"author": "Marten Seemann", "text": "

It's also very inefficient

", "time": "2023-03-29T01:49:31Z"}, {"author": "Bob Briscoe", "text": "

Yup

", "time": "2023-03-29T01:49:35Z"}, {"author": "Matt Joras", "text": "

fwiw I agree with everything Marten said. Doing this for end to end QUIC in particular would be simply harmful to the endpoints' ability to understand and adapt to network conditions.

", "time": "2023-03-29T01:50:43Z"}, {"author": "Bob Briscoe", "text": "

Sending a dup is really good for short flows, initial packets, etc. Local loss repair complements it for all the other bulk of packets.

", "time": "2023-03-29T01:50:49Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz the idea is that the same datagram is sent on two paths using different QUIC packets.

", "time": "2023-03-29T01:50:50Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Thomson The HTTP Datagram? The QUIC Datagram? The UDP payload datagram?

", "time": "2023-03-29T01:51:43Z"}, {"author": "Peter Thatcher", "text": "

Could this be done with connect-udp where you send a UDP with multiple destination addresses?

", "time": "2023-03-29T01:51:44Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz there are two UDP datagrams on different paths containing different QUIC packets that contain different QUIC DATAGRAM frames that contain the same tunneled data.

", "time": "2023-03-29T01:52:47Z"}, {"author": "Lucas Pardue", "text": "

why does the draft need an ever increasing sequence number?

", "time": "2023-03-29T01:53:15Z"}, {"author": "Christian Huitema", "text": "

There are a bunch of differences between MP_QUIC and MP_TCP...

", "time": "2023-03-29T01:53:26Z"}, {"author": "Martin Thomson", "text": "

@Lucas Pardue I think that the requirement is to express both uniqueness and sequencing

", "time": "2023-03-29T01:53:39Z"}, {"author": "Eric Kinnear", "text": "

@Christian Huitema, you were in the queue before it closed if you want to rejoin

", "time": "2023-03-29T01:54:03Z"}, {"author": "Martin Thomson", "text": "

some applications only need the uniqueness, but others care about sequencing (the non-modern stack that isn't doing QUIC)

", "time": "2023-03-29T01:54:11Z"}, {"author": "Benjamin Schwartz", "text": "

I'm pretty sure QUIC Datagrams still have unique IVs that identify them, and at least in principle could be used for deduplication by the receiver.

", "time": "2023-03-29T01:54:22Z"}, {"author": "Lucas Pardue", "text": "

but seems like you could play similar packet number tircks here

", "time": "2023-03-29T01:54:29Z"}, {"author": "Giridhar Mandyam", "text": "

Re: disabling HARQ. Approx. 20 years ago when we introduced HARQ into cellular, the concern was core network latency due to rtx. HARQ was all contained within Physical Layer, so CN latency did not come into play. Maybe this is less of an issue with 5G CN, but benchmarking over real networks would be desirable. Ref: https://www.researchgate.net/publication/2389619_Fast_ARQ_in_high_speed_downlink_packet_access_for_WCDMA_systems

", "time": "2023-03-29T01:54:53Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz not an IV, but the encryption might be distinguishing, yes

", "time": "2023-03-29T01:54:57Z"}, {"author": "Eric Rescorla", "text": "

Well, the datagrams might not be 1:1 with packets, no?

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

@Eric Rescorla that too, yes

", "time": "2023-03-29T01:55:49Z"}, {"author": "Martin Thomson", "text": "

This is @Lucas Pardue's natural time zone.

", "time": "2023-03-29T01:56:49Z"}, {"author": "Eric Kinnear", "text": "

Sorry Ben, you're next

", "time": "2023-03-29T02:06:58Z"}, {"author": "Martin Duke", "text": "

I feel like we just stripped a ton of complexity out of the HTTP/2 priority scheme, and now we're putting it back in

", "time": "2023-03-29T02:09:11Z"}, {"author": "Martin Duke", "text": "

the minimum solution here would be that the sender knows which stream the datagram belongs to, and can use the stream-level priority

", "time": "2023-03-29T02:10:07Z"}, {"author": "Christian Huitema", "text": "

This is very simiar to the discussions happening in MoQ!

", "time": "2023-03-29T02:10:14Z"}, {"author": "Eric Rescorla", "text": "

Martin Duke said:

\n
\n

I feel like we just stripped a ton of complexity out of the HTTP/2 priority scheme, and now we're putting it back in

\n
\n

That complexity has to go somewhere. Otherwise we might be able to stop working on these protocols

", "time": "2023-03-29T02:12:17Z"}, {"author": "David Schinazi", "text": "

Our thoughts back when we were working on 9297 was that we should wait until we have deployment experience with priorities before we publish it, to avoid a repeat of h2 priorities

", "time": "2023-03-29T02:12:19Z"}, {"author": "Eric Rescorla", "text": "

@David Schinazi I agree, can we get some measurements here.

", "time": "2023-03-29T02:12:37Z"}, {"author": "David Schinazi", "text": "

+1, I'd like to see measurement before we decide to move forward on priorities

", "time": "2023-03-29T02:13:19Z"}, {"author": "Martin Duke", "text": "

+1

", "time": "2023-03-29T02:13:51Z"}, {"author": "Martin Duke", "text": "

(no hats)

", "time": "2023-03-29T02:13:56Z"}, {"author": "Alan Frindell", "text": "

Martin Duke said:

\n
\n

the minimum solution here would be that the sender knows which stream the datagram belongs to, and can use the stream-level priority

\n
\n

I think this is the minimum thing we ought to say. This would make the datagram and datagram capsule cases work more or less the same.

", "time": "2023-03-29T02:14:45Z"}, {"author": "Alex Chernyakhovsky", "text": "

\"Split dns\" is what I usually think of as \"split horizon dns\"?

", "time": "2023-03-29T02:16:34Z"}, {"author": "Hang Shi", "text": "

+1 to datagram belongs to stream

", "time": "2023-03-29T02:17:09Z"}, {"author": "Benjamin Schwartz", "text": "

I would call this kind of Split DNS the \"Intranet Access Proxy\" arrangement.

", "time": "2023-03-29T02:17:14Z"}, {"author": "Eric Rescorla", "text": "

Please let us not do \"PAC scripts\"

", "time": "2023-03-29T02:17:30Z"}, {"author": "Hang Shi", "text": "

+1 to No PAC

", "time": "2023-03-29T02:18:38Z"}, {"author": "Erik Nygren", "text": "

I'm wondering how this relates to Provisioning Domains (PvDs), at least for a subset of the issues.

", "time": "2023-03-29T02:18:43Z"}, {"author": "Lucas Pardue", "text": "

So inheriting the stream's priority is a good default. That's the default in https://datatracker.ietf.org/doc/html/draft-pardue-masque-dgram-priority. But you need to consider the cases, like WebTransport, where a single HTTP stream is used to manage multiple flows underneath it.

", "time": "2023-03-29T02:18:54Z"}, {"author": "Hang Shi", "text": "

So you want more fine grained priority inside the same stream

", "time": "2023-03-29T02:19:36Z"}, {"author": "Lucas Pardue", "text": "

or where multiple contexts are used (as an extension point) where certain contexts are more important than others

", "time": "2023-03-29T02:19:39Z"}, {"author": "Lucas Pardue", "text": "

they are all different streams or logical datagram flows Hang

", "time": "2023-03-29T02:20:10Z"}, {"author": "Hang Shi", "text": "

Right, like a packet set

", "time": "2023-03-29T02:21:26Z"}, {"author": "Martin Thomson", "text": "

The problem with PAC is not that it is a script (though that is a problem) it is that we had clients allow an arbitrary network (attacker|entity) dictate aspects of behaviour in a way that is not appropriate

", "time": "2023-03-29T02:22:56Z"}, {"author": "David Schinazi", "text": "

@MT: Using a PAC script over HTTPS makes sense, WPAD does not

", "time": "2023-03-29T02:24:33Z"}, {"author": "David Schinazi", "text": "

In that as a user you have the agency to pick your PAC URL, whereas WPAD does not involve user agency

", "time": "2023-03-29T02:24:55Z"}, {"author": "David Schinazi", "text": "

@Alex from memory Apple's corporate VPN would say \"send me *.apple.com and 17.0.0.0/8 but do everything else outside of the VPN\"

", "time": "2023-03-29T02:25:49Z"}, {"author": "Alex Chernyakhovsky", "text": "

@David Schinazi I find this surprising but good data :)

", "time": "2023-03-29T02:27:05Z"}, {"author": "Martin Thomson", "text": "

There is value in saying that the proxy would accept some addresses (which you might want to intersect with what you are willing to send it).

", "time": "2023-03-29T02:28:08Z"}, {"author": "Eric Rescorla", "text": "

@Martin Thomson yes, I agree with that

", "time": "2023-03-29T02:29:26Z"}, {"author": "Eric Rescorla", "text": "

I'm just saying that that doesn't let the proxy sink all this data

", "time": "2023-03-29T02:29:43Z"}]