i can do backup notes
", "time": "2024-03-19T05:35:56Z"}, {"author": "Brian Trammell", "text": "(remote though)
", "time": "2024-03-19T05:35:58Z"}, {"author": "Brian Trammell", "text": "wait, did y'all just port TAPS framers into MASQUE? neat.
", "time": "2024-03-19T05:43:51Z"}, {"author": "Benjamin Schwartz", "text": "What is a TAPS framer?
", "time": "2024-03-19T05:44:30Z"}, {"author": "Brian Trammell", "text": "basically a transform, but shimmed between the API and the wire.
", "time": "2024-03-19T05:45:20Z"}, {"author": "Alex Chernyakhovsky", "text": "TAPS as in https://datatracker.ietf.org/wg/taps/ or is this a name conflict?
", "time": "2024-03-19T05:47:36Z"}, {"author": "Jana Iyengar", "text": "@Brian Trammelll -- coming to you over AM radio
", "time": "2024-03-19T05:47:49Z"}, {"author": "Brian Trammell", "text": "yes that taps
", "time": "2024-03-19T05:48:21Z"}, {"author": "Brian Trammell", "text": "(disregard the taps refs though, I'm mainly just trolling David. :) )
", "time": "2024-03-19T05:48:35Z"}, {"author": "David Schinazi", "text": "Brian that's too much TAPS
", "time": "2024-03-19T05:48:39Z"}, {"author": "David Schinazi", "text": "lol
", "time": "2024-03-19T05:48:43Z"}, {"author": "Brian Trammell", "text": "mission accomplished :D
", "time": "2024-03-19T05:48:48Z"}, {"author": "Martin Thomson", "text": "what happens if I specify transform=identity.identity,identity,identity,identity,identity,identity,identity,identity ?
Can you repeat transforms?
", "time": "2024-03-19T05:49:20Z"}, {"author": "Alex Chernyakhovsky", "text": "you get back buffalo,buffalo,buffalo,buffalo,buffalo,buffalo,buffalo,buffalo,
", "time": "2024-03-19T05:49:24Z"}, {"author": "Antoine Fressancourt", "text": "You can think of composed transform
", "time": "2024-03-19T05:50:42Z"}, {"author": "Jonathan Hoyland", "text": "ROT-13 twice?
", "time": "2024-03-19T05:51:05Z"}, {"author": "Dennis Jackson", "text": "If we learned anything from TLS ciphersuites, we learned to keep the menu of sensible options small.
", "time": "2024-03-19T05:51:33Z"}, {"author": "Alex Chernyakhovsky", "text": "These are bytes, so we'd have to rot-128
", "time": "2024-03-19T05:51:35Z"}, {"author": "Antoine Fressancourt", "text": "(But the security aspect of the composition is not something we commit to)
", "time": "2024-03-19T05:51:58Z"}, {"author": "Jana Iyengar", "text": "Maybe rename \"null\" transform to \"passive-aggressive-compression\", as in, \"I don't think there's any new information anyway\"
", "time": "2024-03-19T05:52:16Z"}, {"author": "Antoine Fressancourt", "text": "It is now an identity transform anyway
", "time": "2024-03-19T05:52:50Z"}, {"author": "Brian Trammell", "text": "(AM radio: switching to the pandemic-era podcast rig now. was on headphones to let the family sleep but it's morning now)
", "time": "2024-03-19T05:53:59Z"}, {"author": "Lucas Pardue", "text": "tossed-salad-and-scrambled
", "time": "2024-03-19T05:54:31Z"}, {"author": "Antoine Fressancourt", "text": "(Still morning for 30 minutes here)
", "time": "2024-03-19T05:54:48Z"}, {"author": "Jana Iyengar", "text": "@Brian -- turn on the speakers, maybe we can collectively wake them up
", "time": "2024-03-19T05:55:39Z"}, {"author": "Benjamin Schwartz", "text": "BTW, there are some great bikeshed questions about which transforms, if any, are MTI (for either party), and whether there is a default.
", "time": "2024-03-19T05:56:09Z"}, {"author": "Jana Iyengar", "text": "Are transforms required to be supported?
", "time": "2024-03-19T05:56:28Z"}, {"author": "Martin Thomson", "text": "transform=scramble should be the default
", "time": "2024-03-19T05:56:53Z"}, {"author": "Martin Thomson", "text": "MTI
", "time": "2024-03-19T05:56:58Z"}, {"author": "Antoine Fressancourt", "text": "I agree with Martin on this
", "time": "2024-03-19T05:57:14Z"}, {"author": "Brian Trammell", "text": "+1
", "time": "2024-03-19T05:57:35Z"}, {"author": "Benjamin Schwartz", "text": "There is currently no default. https://github.com/ietf-wg-masque/draft-ietf-masque-quic-proxy/pull/99/files#diff-15989da260773d143aa26dfcede63dff650a8d3c2f684cd01cc97adf9e9cf53cR474
", "time": "2024-03-19T05:57:41Z"}, {"author": "Antoine Fressancourt", "text": "Identity should also be MTI but I agree Scramble should be default
", "time": "2024-03-19T05:58:01Z"}, {"author": "Martin Thomson", "text": "Isn't \"identity\" an implied default if you don't specify one?
", "time": "2024-03-19T05:58:03Z"}, {"author": "Ted Hardie", "text": "I agree that there should be at least one MTI.
", "time": "2024-03-19T05:58:09Z"}, {"author": "Martin Thomson", "text": "+1 Antoine
", "time": "2024-03-19T05:58:11Z"}, {"author": "Martin Thomson", "text": "Oh, let me reconsider: if we require scramble, then we don't need to have identity as MTI
", "time": "2024-03-19T05:58:32Z"}, {"author": "Ted Hardie", "text": "And it seems like scramble (and identity) make sense.
", "time": "2024-03-19T05:58:35Z"}, {"author": "Benjamin Schwartz", "text": "Martin Thomson said:
\n\n\nIsn't \"identity\" an implied default if you don't specify one?
\n
Nope, not specifying one is (implicitly) a protocol error.
", "time": "2024-03-19T05:58:43Z"}, {"author": "Martin Thomson", "text": "Then, if you want identity, both client and proxy have to support and advertise (and maybe prefer) identity.
", "time": "2024-03-19T05:59:02Z"}, {"author": "Antoine Fressancourt", "text": "I think Identity should be MTI if, for some reason, we have proxies that are weak and can't handle scramble for some reason, even if I am convinced the scramble transform does not put a strong computing burden
", "time": "2024-03-19T06:00:10Z"}, {"author": "Martin Thomson", "text": "That smells like a MTI HTTP (not HTTPS) argument.
", "time": "2024-03-19T06:00:44Z"}, {"author": "Antoine Fressancourt", "text": "@Martin Indeed, the difference being that the packet content's confidentiality is protected by the proxied QUIC connection
", "time": "2024-03-19T06:02:01Z"}, {"author": "Antoine Fressancourt", "text": "But I agree it makes a downgrade that harms privacy MTI
", "time": "2024-03-19T06:02:37Z"}, {"author": "Jonathan Lennox", "text": "Is there any more detail about what crypto mode scramble is?
", "time": "2024-03-19T06:05:07Z"}, {"author": "Martin Thomson", "text": "basically ctr
", "time": "2024-03-19T06:05:38Z"}, {"author": "Martin Thomson", "text": "maybe fix the problem properly then?
", "time": "2024-03-19T06:06:13Z"}, {"author": "Martin Thomson", "text": "this is all very troubling
", "time": "2024-03-19T06:06:39Z"}, {"author": "Martin Thomson", "text": "and all because we wanted to save some extra RTTs to the proxy
", "time": "2024-03-19T06:06:50Z"}, {"author": "Dennis Jackson", "text": "Design team output: https://github.com/ietf-wg-masque/draft-ietf-masque-quic-proxy/pull/99/files
", "time": "2024-03-19T06:06:52Z"}, {"author": "Benjamin Schwartz", "text": "Would it help to let the proxy choose the client CIDs as sent to the target?
", "time": "2024-03-19T06:08:11Z"}, {"author": "Christian Huitema", "text": "Infinite is just 2^64 now?
", "time": "2024-03-19T06:10:19Z"}, {"author": "Brian Trammell", "text": "practically infinite
", "time": "2024-03-19T06:10:51Z"}, {"author": "Brian Trammell", "text": "you get one infinity per locally-routable v6 prefix, seems legit
", "time": "2024-03-19T06:11:10Z"}, {"author": "Martin Thomson", "text": "2^62
", "time": "2024-03-19T06:11:11Z"}, {"author": "Alex Chernyakhovsky", "text": "Just like how our computers are not real turing machines (no infinite tape), effectively infinite rules our world :)
", "time": "2024-03-19T06:11:25Z"}, {"author": "Martin Thomson", "text": "2^62 == Infinity
", "time": "2024-03-19T06:11:34Z"}, {"author": "Brian Trammell", "text": "#define MIN_INFINITY 2**62
\n#define MAX_INFINITY
\n2**64
The captioning seems to think I am Abhi.
", "time": "2024-03-19T06:14:09Z"}, {"author": "Benjamin Schwartz", "text": "Nobody needs more than 64^k of memory (k = 10)
", "time": "2024-03-19T06:14:14Z"}, {"author": "Eric Kinnear", "text": "You're an imposter!
", "time": "2024-03-19T06:14:26Z"}, {"author": "Martin Thomson", "text": "MAX_INFINITY needs to be (1<<64) - 1
", "time": "2024-03-19T06:14:50Z"}, {"author": "Alex Chernyakhovsky", "text": "but what about SIGNED_INFINITY?
", "time": "2024-03-19T06:15:12Z"}, {"author": "Alejandro Sede\u00f1o", "text": "Or should I say that Abhi is me?
", "time": "2024-03-19T06:15:16Z"}, {"author": "Kazuho Oku", "text": "@Tommy Pauly but isn't it the origin that is sending this header field?
", "time": "2024-03-19T06:15:47Z"}, {"author": "Kazuho Oku", "text": "maybe that comment applies to other parameters of proxy-status, though
", "time": "2024-03-19T06:16:28Z"}, {"author": "Martin Thomson", "text": "A completely new address is not useful. You get more privacy if you get an address that has already been used.
", "time": "2024-03-19T06:16:30Z"}, {"author": "Alex Chernyakhovsky", "text": "Why sf-dict and not just sf-list? That way you can have as many or few v4/v6 addresses?
", "time": "2024-03-19T06:17:34Z"}, {"author": "Martin Thomson", "text": "send links to PR here?
", "time": "2024-03-19T06:18:01Z"}, {"author": "Kazuho Oku", "text": "+1 to sf-list; you do not want to handle the case of type being \"v6\" and the address being v4 or vice versa
", "time": "2024-03-19T06:18:19Z"}, {"author": "Christian Huitema", "text": "That setup enables running a server from the home, and other similar scenarios. If you want to do that scenario and use private addresses, you will need quite a bit of work
", "time": "2024-03-19T06:18:36Z"}, {"author": "Eric Kinnear", "text": "https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-listen/pull/18
", "time": "2024-03-19T06:18:49Z"}, {"author": "Alex Chernyakhovsky", "text": "Looks like https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-listen/pull/18
", "time": "2024-03-19T06:18:51Z"}, {"author": "Lucas Pardue", "text": "I'm attending the meeting to learn what's going on, so if the slides don't contain links to the PRs that makes it hard to follow
", "time": "2024-03-19T06:18:59Z"}, {"author": "Alex Chernyakhovsky", "text": "and compression (currently being discussed) is https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-listen/pull/19
", "time": "2024-03-19T06:19:48Z"}, {"author": "Martin Thomson", "text": "Can I add a QUIC connection ID to that list?
", "time": "2024-03-19T06:19:55Z"}, {"author": "Martin Thomson", "text": "Thanks Alex
", "time": "2024-03-19T06:20:05Z"}, {"author": "Martin Thomson", "text": "It would be really nice if I could compress out a QUIC cid for outbound packets.
", "time": "2024-03-19T06:20:20Z"}, {"author": "Christian Huitema", "text": "I wonder whether a name based solution would also work. \"The proxy assigned you proxy.example.net:3456\"
David Schinazi: do you have a cap on the number of contexts?
", "time": "2024-03-19T06:28:05Z"}, {"author": "David Schinazi", "text": "You can open as many as you want but you can't use them until the other side accepts it
", "time": "2024-03-19T06:28:37Z"}, {"author": "David Schinazi", "text": "So one side can decide to not spend resources
", "time": "2024-03-19T06:28:50Z"}, {"author": "Martin Thomson", "text": "So you can close before you accept?
", "time": "2024-03-19T06:28:59Z"}, {"author": "David Schinazi", "text": "yeah
", "time": "2024-03-19T06:29:07Z"}, {"author": "Jonathan Lennox", "text": "Queue is closed so I\u2019ll say it here: I don\u2019t love COMPRESSION_CLOSE meaning three different things depending on context. Are capsule numbers scarce?
", "time": "2024-03-19T06:29:14Z"}, {"author": "Benjamin Schwartz", "text": "In general capsules' error handling is woefully underspecified and we're just hoping they don't fail
", "time": "2024-03-19T06:29:26Z"}, {"author": "Mike Bishop", "text": "@Ben, I think what you're saying is that you should always be able to re-open the wide-open context?
", "time": "2024-03-19T06:29:38Z"}, {"author": "Alex Chernyakhovsky", "text": "+1 to @Jonathan Lennox , we had that ambiguity in CONNECT-IP and we ended up adding sequence numbers to distinguish request/response capsules, since ADDRESS_ASSIGN could be sent unprompted.
", "time": "2024-03-19T06:30:26Z"}, {"author": "Benjamin Schwartz", "text": "@Mike Bishop Yes, and in general the state machine should be reversible back to any prior state. \"Close means block\" seems like it creates a kind of ratchet that strikes me as undesirable.
", "time": "2024-03-19T06:30:38Z"}, {"author": "Jonathan Lennox", "text": "If you get the logic wrong about which COMPRESSION_CLOSEs you echo, you could end up with an infinite ping-pong of them.
", "time": "2024-03-19T06:32:14Z"}, {"author": "Martin Thomson", "text": "PRO TIP: DO NOT TAKE NOTES IN THE EMBEDDED HEDGEDOC FRAME. Everything moves around all the time.
", "time": "2024-03-19T06:32:29Z"}, {"author": "Benjamin Schwartz", "text": "There are lots of ways to spell this, like maybe a COMPRESSION_SILENCE capsule that reversibly silences a context.
", "time": "2024-03-19T06:32:43Z"}, {"author": "David Schinazi", "text": "The design with just two capsules was intended to try to make the smallest possible solution. If we find cases that can't be handled then it makes sense to add more fields or capsules
", "time": "2024-03-19T06:33:29Z"}, {"author": "Alex Chernyakhovsky", "text": "We didn't really design capsules to have fields added to them later, though?
", "time": "2024-03-19T06:33:53Z"}, {"author": "David Schinazi", "text": "no I meant in this PR
", "time": "2024-03-19T06:34:04Z"}, {"author": "Alex Chernyakhovsky", "text": "Ah, that makes more sense.
", "time": "2024-03-19T06:34:13Z"}, {"author": "Mike Bishop", "text": "@Ben, I'm not sure I agree that the ratchet is bad. If you've closed yourself down to incoming packets, you can just make a new CONNECT request to start listening again. The main drawback is that you're not guaranteed to get the same remote port as you did previously.
", "time": "2024-03-19T06:35:42Z"}, {"author": "Jonathan Lennox", "text": "I\u2019d say in fact you\u2019re guaranteed not to, I hope?
", "time": "2024-03-19T06:36:28Z"}, {"author": "Benjamin Schwartz", "text": "@Mike Bishop Imagine a long-lived WebRTC connection where my peer is regularly moving, and I open a compression context for each new peer IP. If I don't close the compression contexts, I build up an unbounded number of contexts. If I do close them, I kill the connection if the peer ever returns to a prior address. This is bad.
", "time": "2024-03-19T06:37:27Z"}, {"author": "Martin Thomson", "text": "Doesn't switching to streams create weird performance discontinuities?
", "time": "2024-03-19T06:39:52Z"}, {"author": "Mike Bishop", "text": "@Ben, how are you discovering that the peer has moved? It seems that supporting that scenario entails leaving the wide-open context open for the lifetime of the session.
", "time": "2024-03-19T06:40:35Z"}, {"author": "Ziyang Xing", "text": "what will happen in non-IP /ICN
", "time": "2024-03-19T06:41:03Z"}, {"author": "Mike Bishop", "text": "(In which case, nothing fails, it just comes in uncompressed.)
", "time": "2024-03-19T06:41:05Z"}, {"author": "Benjamin Schwartz", "text": "@Mike Bishop Correct, the wide-open context is always open in this case. But IIUC this PR imagines that you can leave that context open while imposing targeted blocks by closing specific contexts.
", "time": "2024-03-19T06:42:09Z"}, {"author": "Martin Thomson", "text": "I'd be happier dropping the proposal than the packet :p
", "time": "2024-03-19T06:42:26Z"}, {"author": "Mike Bishop", "text": "No, I think the proposal is the reverse -- once you've opened specific contexts and you've received all the incoming connections you were expecting, you can close the wide one and only receive from addresses you have contexts for.
", "time": "2024-03-19T06:43:09Z"}, {"author": "Martin Thomson", "text": "Christian: but that is fragmentation and reassembly!
", "time": "2024-03-19T06:43:48Z"}, {"author": "Mike Bishop", "text": "Christian, that seems like we'd be saying put it as a capsule on the stream (enforces ordering) or create a way to stick each big packet on a unidirectional stream.
", "time": "2024-03-19T06:44:54Z"}, {"author": "David Schinazi", "text": "Nah we could make it work with unidirectional streams. Not a great idea though
", "time": "2024-03-19T06:45:42Z"}, {"author": "Mike Bishop", "text": "You can define unidirectional stream types in HTTP/3, it's just an interface pain.
", "time": "2024-03-19T06:46:02Z"}, {"author": "Mike Bishop", "text": "Not really any worse than adding Datagrams, though?
", "time": "2024-03-19T06:46:11Z"}, {"author": "Eduard V", "text": "all modern routers support bigger MTU. You could just assume that tunnel could accommodate overhead.
", "time": "2024-03-19T06:46:39Z"}, {"author": "David Schinazi", "text": "Yeah I've been toying with the idea of a unidirectional stream type that means DATAGRAM. (Or uplevel one layer and have it mean CAPSULE)
", "time": "2024-03-19T06:47:01Z"}, {"author": "Alex Chernyakhovsky", "text": "The problem is not the ethernet MTU on the routers; the problem is you may not control the MTU of the destination network you are connecting to.
", "time": "2024-03-19T06:47:21Z"}, {"author": "Martin Thomson", "text": "I disagree somewhat with Yaroslav: we have privacy requirements on MAC allocation
", "time": "2024-03-19T06:47:55Z"}, {"author": "Christian Huitema", "text": "Given that discussion, I am tempted to do \"Masque over web transport\"...
", "time": "2024-03-19T06:48:03Z"}, {"author": "Eduard V", "text": "it is the same problem when you try to bridge 2 802.3 broadcast domains. IMHO: it is not your problem. Configuration error.
", "time": "2024-03-19T06:48:33Z"}, {"author": "Benjamin Schwartz", "text": "Mike Bishop said:
\n\n\nNo, I think the proposal is the reverse -- once you've opened specific contexts and you've received all the incoming connections you were expecting, you can close the wide one and only receive from addresses you have contexts for.
\n
That doesn't match what I heard in the presentation, but it does seem to match the PR. I must have misunderstood the presentation. The PR doesn't seem to support targeted blocks. That's fine with me and avoids the ratchet issue.
", "time": "2024-03-19T06:48:55Z"}, {"author": "Alex Chernyakhovsky", "text": "@Eduard V yes, by definition, that is what we are trying to do. But the goal is to not have a forced-error in the default mode where everyone's configuration is sad. Consider the typical home network, which could be a CONNECT-ETHERNET target. Are you going to lower the ethernet MTU of all connected devices to account for CONNECT-ETHERNET encapsulation overhead?
", "time": "2024-03-19T06:49:54Z"}, {"author": "Christian Huitema", "text": "@Martin Thomson the issue in MoQ are pretty similar: pass media frames of various sizes, maintain low latency. The solutions do entail resetting unidir streams that have waited too long. or datagrams, but only if the whole frame fits in a datagram.
", "time": "2024-03-19T06:50:17Z"}, {"author": "Lucas Pardue", "text": "maybe we need a QUIC JUMBOGRAM frame?
", "time": "2024-03-19T06:50:55Z"}, {"author": "Martin Thomson", "text": "Christian: MoQ has a pretty clear understanding of the application domain (even if it is big). That doesn't apply here.
", "time": "2024-03-19T06:51:34Z"}, {"author": "Eduard V", "text": "@Alex, this is invented problem. It does not exist in reality. Every home has 1500B but every DC has 9000B. So what? Any bridging would not work.
", "time": "2024-03-19T06:51:38Z"}, {"author": "Alex Chernyakhovsky", "text": "Every DC has 9000B, and MSS clamps when egressing to the outside world. This is not an invented problem.
", "time": "2024-03-19T06:52:01Z"}, {"author": "Jonathan Lennox", "text": "Lucas: How is that different from a stream that\u2019s immediately reset?
", "time": "2024-03-19T06:52:06Z"}, {"author": "Eduard V", "text": "@Alex, tunneling would not make this problem worser.
", "time": "2024-03-19T06:52:30Z"}, {"author": "Benjamin Schwartz", "text": "@Alex Chernyakhovsky The time has come for an MSS clamping RFC :grimacing:
", "time": "2024-03-19T06:52:51Z"}, {"author": "Lucas Pardue", "text": "it would provide an interface to apps to send a message and ignore any matters to do with streams, including flow control and reset timings
", "time": "2024-03-19T06:52:56Z"}, {"author": "Eduard V", "text": "If 2 segments is not possible to connect because of MTU then it does not matter: direct connenction, VxLAN, or any other tunneling.
", "time": "2024-03-19T06:54:07Z"}, {"author": "Eduard V", "text": "Do not try to solve all problems in the Universe.
", "time": "2024-03-19T06:54:27Z"}, {"author": "Alex Chernyakhovsky", "text": "@Eduard V tunneling necessitates a solution, either with every other participant of the broadcast domain clamping, or the tunnel endpoint being \"smart\", or us being OK with dropping on MTU mismatch.
", "time": "2024-03-19T06:54:28Z"}, {"author": "Martin Thomson", "text": "Link: </dns>; rel=doh
", "time": "2024-03-19T06:54:46Z"}, {"author": "Alex Chernyakhovsky", "text": "@Benjamin Schwartz perhaps? What would we say? What wg would we take it to?
", "time": "2024-03-19T06:55:15Z"}, {"author": "Benjamin Schwartz", "text": "Probably TSVWG. It would say \"MSS clamping is a thing and it's OK\".
", "time": "2024-03-19T06:56:00Z"}, {"author": "Alex Chernyakhovsky", "text": "I would be in support of that. It's basically an open secret everyone does it.
", "time": "2024-03-19T06:56:18Z"}, {"author": "Eric Kinnear", "text": "Closing the queue momentarily
", "time": "2024-03-19T06:57:21Z"}, {"author": "Brian Trammell", "text": "bye all
", "time": "2024-03-19T07:01:36Z"}]