[{"author": "David Schinazi", "text": "

YOU CALLED?

", "time": "2022-07-27T19:00:25Z"}, {"author": "Lucas Pardue", "text": "

ENTHUSIAT_S_ there must be more that just you ;-)

", "time": "2022-07-27T19:01:17Z"}, {"author": "David Schinazi", "text": "

There are dozens of us

", "time": "2022-07-27T19:01:35Z"}, {"author": "Hang Shi", "text": "

Hi

", "time": "2022-07-27T19:02:11Z"}, {"author": "Jonathan Hoyland", "text": "

Speak for those who are text only

", "time": "2022-07-27T19:02:20Z"}, {"author": "Alex Chernyakhovsky", "text": "

dozens of david schinazis is a terrifying idea

", "time": "2022-07-27T19:03:00Z"}, {"author": "Rolf Sonneveld", "text": "

don't forget to put on your masque :grinning:

", "time": "2022-07-27T19:03:09Z"}, {"author": "Lucas Pardue", "text": "

douze david d\u2019attaque masque

", "time": "2022-07-27T19:06:23Z"}, {"author": "David Schinazi", "text": "

rofl

", "time": "2022-07-27T19:07:19Z"}, {"author": "Juliusz Chroboczek", "text": "

In other words, you've done the first 90%, so there's only the other 90% remaining :-)

", "time": "2022-07-27T19:09:43Z"}, {"author": "Lucas Pardue", "text": "

do it

", "time": "2022-07-27T19:12:19Z"}, {"author": "Martin Thomson", "text": "

https://www.rfc-editor.org/rfc/rfc6570#section-3.2.6 describes {/var}

", "time": "2022-07-27T19:18:07Z"}, {"author": "Lucas Pardue", "text": "

so swap the target and ipproto in the URL?

", "time": "2022-07-27T19:18:11Z"}, {"author": "Martin Thomson", "text": "

that might be what you want here

", "time": "2022-07-27T19:18:11Z"}, {"author": "Magnus Westerlund", "text": "

actually IPPROTO is equally uncertain if you use it. So swapping it in the template.

", "time": "2022-07-27T19:20:28Z"}, {"author": "Magnus Westerlund", "text": "

is not that a good idea.

", "time": "2022-07-27T19:20:41Z"}, {"author": "Lucas Pardue", "text": "

got it, thx

", "time": "2022-07-27T19:20:49Z"}, {"author": "Alex Chernyakhovsky", "text": "

queryparams would be clearer here IMO, but i've expressed that opinion before

", "time": "2022-07-27T19:21:10Z"}, {"author": "Ted Hardie", "text": "

Template's head-spin is boosted by the weather!

", "time": "2022-07-27T19:23:59Z"}, {"author": "Steve Wang", "text": "

Here I was trying to figure out what CenturyLink/Lumen had to do with anything

", "time": "2022-07-27T19:24:21Z"}, {"author": "Martin Thomson", "text": "

template uses .well-known! it grazes

", "time": "2022-07-27T19:25:44Z"}, {"author": "Hang Shi", "text": "

This MTU problem is not unique to MASQUE, right? Many tunnel technique faces the same problem.

", "time": "2022-07-27T19:26:36Z"}, {"author": "Martin Thomson", "text": "

This is PLPMTUD4DT

", "time": "2022-07-27T19:26:54Z"}, {"author": "Steve Wang", "text": "

Hey, we solved the tunnel MTU problem. We just drop packets that are too big to punish violating services..

", "time": "2022-07-27T19:27:23Z"}, {"author": "Magnus Westerlund", "text": "

The issue is the HTTP intermediaries that can exist which results in multiple HTTP/3 hops, where you need to ensure that all hops support minimal IPv6 MTU.

", "time": "2022-07-27T19:28:19Z"}, {"author": "Magnus Westerlund", "text": "

Steve Wang, the issue is what to do when the datagram MTU is < 1280, otherwise one does what you say.

", "time": "2022-07-27T19:28:59Z"}, {"author": "Martin Thomson", "text": "

\"I'm sure you'll work out what to say\" is a great response there

", "time": "2022-07-27T19:29:05Z"}, {"author": "Spencer Dawkins", "text": "

Magnus Westerlund said:

\n
\n

The issue is the HTTP intermediaries that can exist which results in multiple HTTP/3 hops, where you need to ensure that all hops support minimal IPv6 MTU.

\n
\n

I would believe \"The biggest issue\", but I can imagine other reasons that would reduce the MTU size ... probably all of them at once would be possible!

", "time": "2022-07-27T19:29:53Z"}, {"author": "Magnus Westerlund", "text": "

Yes, but for MTU variations that are above 1280 then you can run normal procedures for MTU discovery like dropping packets and sending back PACKET TOO BIG towards sender.

", "time": "2022-07-27T19:31:04Z"}, {"author": "Ted Hardie", "text": "

If you are going to take that attitude, then you can just say (b) and take the lack of compliance there.

", "time": "2022-07-27T19:32:15Z"}, {"author": "Ted Hardie", "text": "

Note: not what I recommend.

", "time": "2022-07-27T19:32:30Z"}, {"author": "Martin Thomson", "text": "

We're going to pad QUIC Initial packets and the PMTU is highly unlikely to drop enough for this to matter.

", "time": "2022-07-27T19:33:44Z"}, {"author": "Gorry Fairhurst", "text": "

The method would generally be considered robust to path changes... So perhaps SHOULD use a PMTU method, and warn that path changes that result in change sof PMTU could lead to non-compliant Ipv6 path

", "time": "2022-07-27T19:36:07Z"}, {"author": "Magnus Westerlund", "text": "

The time that padding of the QUIC Initial don't work is if the HTTP Intermediary that forwards the CONNECT-IP request does not the same padding and only does what is required by the QUIC spec (1200 bytes). Then you could end up in a path where the forwarding of the HTTP datagram by the HTTP intermediary fails the IPv6 spec requirements.

", "time": "2022-07-27T19:38:30Z"}, {"author": "Martin Thomson", "text": "

destination unreachable being generated by the proxy seems fine

", "time": "2022-07-27T19:39:31Z"}, {"author": "Martin Thomson", "text": "

I can imagine packet too big as well, to the previous discussion

", "time": "2022-07-27T19:39:53Z"}, {"author": "Jonathan Lennox", "text": "

So the conclusion is that if you want something, ask for it, rather than just quietly hoping someone gives it to you? Sounds like good advice in general.

", "time": "2022-07-27T19:56:01Z"}, {"author": "Lucas Pardue", "text": "

+1

", "time": "2022-07-27T19:56:10Z"}, {"author": "Antony Antony", "text": "

for text on which ICMP responses should be allowed look at RFC4301 #6 and 6.2 MASQUE use case sound a lot similar. It mention both ICMP and ICMP6

", "time": "2022-07-27T19:56:28Z"}, {"author": "Jonathan Hoyland", "text": "

But if you try sometimes, you just might find, you get what you need.

", "time": "2022-07-27T19:56:28Z"}, {"author": "Christian Huitema", "text": "

Should there be some kind of mechanism linking query and response? Liek a request ID, maybe?

", "time": "2022-07-27T19:58:32Z"}, {"author": "David Schinazi", "text": "

What would be the benefit of knowing the link?

", "time": "2022-07-27T19:59:29Z"}, {"author": "Christian Huitema", "text": "

Match assign to request, for example

", "time": "2022-07-27T20:02:06Z"}, {"author": "Christian Huitema", "text": "

Also, this discussion of using lots of zeroes in \"request\" to say \"i don't care\" seems a complex way to save 1 \"i don't care\" bit.

", "time": "2022-07-27T20:03:14Z"}, {"author": "Christian Huitema", "text": "

What does IP-Version = 0 means? Don't care either v4 or V6?

", "time": "2022-07-27T20:05:10Z"}, {"author": "Nick Doty", "text": "

a lot of life metaphors in today's session

", "time": "2022-07-27T20:05:26Z"}, {"author": "Christian Huitema", "text": "

+1 Martin

", "time": "2022-07-27T20:05:42Z"}, {"author": "Spencer Dawkins", "text": "

Can we put Tommy's question in the spec? That would be AWESOME.

", "time": "2022-07-27T20:05:49Z"}, {"author": "Juliusz Chroboczek", "text": "

The client-side state automaton is going to be complicated

", "time": "2022-07-27T20:10:03Z"}, {"author": "Juliusz Chroboczek", "text": "

(if you can't distinguish spontaneous from response)

", "time": "2022-07-27T20:10:22Z"}, {"author": "Christian Huitema", "text": "

Clients will be easier to debug is there is a well established request/response pattern, or even request/response/abandon

", "time": "2022-07-27T20:11:02Z"}, {"author": "Magnus Westerlund", "text": "

@Christian Huitema I do agree with you. And we don't even have a consistent error handling that works in all cases. There is either ICMP or closing the request.

", "time": "2022-07-27T20:14:53Z"}, {"author": "Martin Thomson", "text": "

What is wrong with sending with an unspecified source address and expecting the server to pick an address?

", "time": "2022-07-27T20:15:47Z"}, {"author": "David Schinazi", "text": "

It's invalid in the IPv4/6 specs, I'd say if you want to do that, have an extension to this that does this special thing

", "time": "2022-07-27T20:17:19Z"}, {"author": "Christian Huitema", "text": "

@Martin Thomson I did not follow Masque closely, but I think iIP over HTTP would benefit being more like PPP

", "time": "2022-07-27T20:17:54Z"}, {"author": "Martin Thomson", "text": "

@Mirja K\u00fchlewind what if you don't want to assign another address?

", "time": "2022-07-27T20:18:36Z"}, {"author": "Mirja K\u00fchlewind", "text": "

that's fine

", "time": "2022-07-27T20:18:48Z"}, {"author": "Mirja K\u00fchlewind", "text": "

just sending a address_assign without any address doesn't make sense

", "time": "2022-07-27T20:19:09Z"}, {"author": "Martin Thomson", "text": "

So if you ask for two and you get one, how do you know if the server saw your request and answered it?

", "time": "2022-07-27T20:19:24Z"}, {"author": "Benjamin Schwartz", "text": "

Stochastic packet loss is of course always fine, but always silently losing the first packet and then waiting for a retransmission timeout is not fine

", "time": "2022-07-27T20:19:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "

MT, doesn't matter; you might get another one but you can only use what you got

", "time": "2022-07-27T20:20:10Z"}, {"author": "Martin Thomson", "text": "

@Mirja K\u00fchlewind it does matter, because the client asked for something and it can't tell if it should keep waiting or not

", "time": "2022-07-27T20:20:43Z"}, {"author": "Martin Thomson", "text": "

was the one spontaneous or in response to its request?

", "time": "2022-07-27T20:21:00Z"}, {"author": "Mirja K\u00fchlewind", "text": "

if you got an address that is usable for you, you should use it. If that address is not useable for you, you need to wait

", "time": "2022-07-27T20:21:50Z"}, {"author": "Alex Chernyakhovsky", "text": "

how would a client end up in a situation where it is assigned an unusable address?

", "time": "2022-07-27T20:23:10Z"}, {"author": "Mirja K\u00fchlewind", "text": "

you asked for v4 and got v6....?

", "time": "2022-07-27T20:23:42Z"}, {"author": "Alex Chernyakhovsky", "text": "

that's not allowed in the current scheme

", "time": "2022-07-27T20:23:50Z"}, {"author": "Martin Thomson", "text": "

https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/73

", "time": "2022-07-27T20:23:57Z"}, {"author": "Alex Chernyakhovsky", "text": "

if you ask for 0.0.0.0/32 you can only be assigned an IPv4 and if that's not satisfiable we assign nothing

", "time": "2022-07-27T20:24:21Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky that seems perfectly doable in the current design. The v6 you got might be spontaneous.

", "time": "2022-07-27T20:24:23Z"}, {"author": "Martin Thomson", "text": "

and the v4 request might be rejected

", "time": "2022-07-27T20:24:33Z"}, {"author": "Alex Chernyakhovsky", "text": "

that's true

", "time": "2022-07-27T20:24:35Z"}, {"author": "Alex Chernyakhovsky", "text": "

that is a consequence of the cumlative

", "time": "2022-07-27T20:24:46Z"}, {"author": "Martin Thomson", "text": "

yeah, it's not a great consequence

", "time": "2022-07-27T20:24:54Z"}, {"author": "Mirja K\u00fchlewind", "text": "

yes, should not happen. All I'm saying is that if you have an address just use it. If you don't have the right address for whatever reason you simply cannot use it.

", "time": "2022-07-27T20:25:01Z"}, {"author": "Alex Chernyakhovsky", "text": "

I wouldn't expect most servers to support unsolicited assignment, though

", "time": "2022-07-27T20:25:03Z"}, {"author": "Alex Chernyakhovsky", "text": "

so in practice I would expect the flow I described

", "time": "2022-07-27T20:25:10Z"}, {"author": "Martin Thomson", "text": "

@Mirja K\u00fchlewind that is not acceptable

", "time": "2022-07-27T20:25:20Z"}, {"author": "Mirja K\u00fchlewind", "text": "

why?

", "time": "2022-07-27T20:25:31Z"}, {"author": "Jonathan Lennox", "text": "

Alex: That would tend to imply weird bugs for clients when they get unsolicited assignments, then, if they don't see them very often.

", "time": "2022-07-27T20:25:55Z"}, {"author": "Alex Chernyakhovsky", "text": "

I'm sure someone will GREASE the connect-ip capsule protocol

", "time": "2022-07-27T20:26:18Z"}, {"author": "Alex Chernyakhovsky", "text": "

and should, for client impls

", "time": "2022-07-27T20:26:22Z"}, {"author": "Mirja K\u00fchlewind", "text": "

if you don't get the right address, you can wait and then either ask again or close

", "time": "2022-07-27T20:26:23Z"}, {"author": "Martin Thomson", "text": "

because as a client, I want an IP address. I need to know if my request is being considered or if it was rejected and this design doesn't allow for me to learn that

", "time": "2022-07-27T20:26:27Z"}, {"author": "Alex Chernyakhovsky", "text": "

I'm just commenting on what I expect real-world deployment behavior to look like

", "time": "2022-07-27T20:26:34Z"}, {"author": "Alex Chernyakhovsky", "text": "

Martin, what if we added an UNSOLICITED bit to distingish?

", "time": "2022-07-27T20:27:06Z"}, {"author": "Alex Chernyakhovsky", "text": "

it's not a full request id but it should at least make it possible to distinguish in this caes

", "time": "2022-07-27T20:27:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "

you request is reliably delivered but if you didn't get an IP address assign for whatever reason, you simply cannot send.

", "time": "2022-07-27T20:27:43Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky you need to have some indication, I don't care what it is, but it's not clear whether an unsolicited bit is what you want, because the unsolicited address might be sufficient for me

", "time": "2022-07-27T20:27:56Z"}, {"author": "Jonathan Lennox", "text": "

Assuming one doesn't want to have multiple ADDRESS_REQUESTs in flight at once I guess?

", "time": "2022-07-27T20:28:03Z"}, {"author": "Martin Thomson", "text": "

What I want to know is whether my request has been seen and answered.

", "time": "2022-07-27T20:28:10Z"}, {"author": "Martin Thomson", "text": "

@Mirja K\u00fchlewind that is not a good basis for a client-server protocol.

", "time": "2022-07-27T20:28:35Z"}, {"author": "Alex Chernyakhovsky", "text": "

I've previously advocated for request id / response pairs and the other folks were not happy about it

", "time": "2022-07-27T20:28:36Z"}, {"author": "Christian Huitema", "text": "

Also, what happens if a client asks for /56 but the server is only willingto delegate a /64?

", "time": "2022-07-27T20:29:02Z"}, {"author": "Martin Thomson", "text": "

The assignment could just count the number of requests that have been seen, for example.

", "time": "2022-07-27T20:29:14Z"}, {"author": "Alex Chernyakhovsky", "text": "

it's tempting to expect serialization on the reliable stream, but with unsolicited being allowed I am thinking request id is starting to be needed

", "time": "2022-07-27T20:29:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "

your request is always seen but I don't think there is anything that we can do to guarantee that you will always get a reply

", "time": "2022-07-27T20:29:32Z"}, {"author": "Martin Thomson", "text": "

@Mirja K\u00fchlewind I don't think that you can just assume that the request is seen unless there is a synchronization marker.

", "time": "2022-07-27T20:29:55Z"}, {"author": "Mirja K\u00fchlewind", "text": "

if you the other end would be required to ack, you still need an timer to give up if there is no ack

", "time": "2022-07-27T20:31:00Z"}, {"author": "Christian Huitema", "text": "

Looking from 10,000ft, the Masque-IP design seems as an example of early optimization: try to save bits early, rather than making the state and the requests explicit

", "time": "2022-07-27T20:31:10Z"}, {"author": "Mirja K\u00fchlewind", "text": "

not sure what the ack would change in your behavior

", "time": "2022-07-27T20:32:14Z"}, {"author": "Martin Thomson", "text": "

An ack would, in most cases, allow the timer to be cancelled. Running a timer to expiration should be rare. The proposed design forces the timer to run always.

", "time": "2022-07-27T20:33:27Z"}, {"author": "Mirja K\u00fchlewind", "text": "

yes, getting an unsolicited assign should also be rare

", "time": "2022-07-27T20:35:02Z"}, {"author": "Juliusz Chroboczek", "text": "

David is frightening, sometimes.

", "time": "2022-07-27T20:36:35Z"}, {"author": "Juliusz Chroboczek", "text": "

Especially when wearing a mask.

", "time": "2022-07-27T20:36:48Z"}, {"author": "David Schinazi", "text": "

What did I do this time?

", "time": "2022-07-27T20:38:20Z"}, {"author": "Lucas Pardue", "text": "

is this PAC?

", "time": "2022-07-27T20:38:40Z"}, {"author": "Juliusz Chroboczek", "text": "

You looked really stern while speaking very slowly in a deep voice.

", "time": "2022-07-27T20:38:44Z"}, {"author": "David Schinazi", "text": "

Ah. Oops

", "time": "2022-07-27T20:39:10Z"}, {"author": "Jonathan Lennox", "text": "

It's dual to PAC, I think? Since it's describing what the proxy does rather than what proxy to use? But I also thought of the similarity.

", "time": "2022-07-27T20:39:35Z"}, {"author": "Jonathan Lennox", "text": "

I don't think we want it to be executable Javascript, though.

", "time": "2022-07-27T20:39:45Z"}, {"author": "Juliusz Chroboczek", "text": "

Webassembly?

", "time": "2022-07-27T20:39:59Z"}, {"author": "Martin Thomson", "text": "

Oh, fff.... PAC.

", "time": "2022-07-27T20:40:00Z"}, {"author": "Lucas Pardue", "text": "

let's call it Pasque

", "time": "2022-07-27T20:40:22Z"}, {"author": "Martin Thomson", "text": "

pacmasque?

", "time": "2022-07-27T20:40:55Z"}, {"author": "Lucas Pardue", "text": "

and Microsoft's impl would be called MsPacmasque

", "time": "2022-07-27T20:43:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

oh no spooky ghosts

", "time": "2022-07-27T20:43:20Z"}, {"author": "Tommy Jensen", "text": "

Not true Lucas, we'd go for MS-PACMASQUE-EX

", "time": "2022-07-27T20:43:35Z"}, {"author": "Juliusz Chroboczek", "text": "

What's Chrome's Privacy Proxy?

", "time": "2022-07-27T20:45:32Z"}, {"author": "Ted Hardie", "text": "

When the first use cases people come up with are evil, it might be a bad sign.

", "time": "2022-07-27T20:46:40Z"}, {"author": "Jonathan Lennox", "text": "

Technically mine was second

", "time": "2022-07-27T20:46:55Z"}, {"author": "Ted Hardie", "text": "

whew

", "time": "2022-07-27T20:47:06Z"}, {"author": "Ted Hardie", "text": "

Speaking as RTCWEB chair (not dead yet!), please send this to the mailing list and see if there are issues raised there.

", "time": "2022-07-27T20:47:53Z"}, {"author": "Christian Huitema", "text": "

I think there is a use case for hiding QUIc servers behind a proxy. Like, say, servers behind a load balancer.

", "time": "2022-07-27T20:48:21Z"}, {"author": "Christian Huitema", "text": "

But then, they all want to use port 443...

", "time": "2022-07-27T20:48:56Z"}, {"author": "Christian Huitema", "text": "

Is there actually anything that is not in the Chrome browser?

", "time": "2022-07-27T20:51:19Z"}, {"author": "Jonathan Lennox", "text": "

I think you can do this entirely in userspace, whereas connect-IP you can't (witness the tunnel interface headaches from the hackathon).

", "time": "2022-07-27T20:51:37Z"}, {"author": "Lucas Pardue", "text": "

no multicast in browser :)

", "time": "2022-07-27T20:51:58Z"}, {"author": "Christian Huitema", "text": "

My deployment constraint would be, can I deploy the proxy in a standard VM on e.g. AWS?

", "time": "2022-07-27T20:52:25Z"}, {"author": "Mirja K\u00fchlewind", "text": "

you don't need an IP stack for connect-IP; you only need to create an IP header

", "time": "2022-07-27T20:52:51Z"}, {"author": "Alex Chernyakhovsky", "text": "

you may need a TCP stack

", "time": "2022-07-27T20:53:03Z"}, {"author": "Erik Nygren", "text": "

We can do MASQUE-over-TLS-Minion and go full circle back to the precursors of QUIC.

", "time": "2022-07-27T20:53:32Z"}, {"author": "Lucas Pardue", "text": "

+1 timebox

", "time": "2022-07-27T20:59:57Z"}, {"author": "Mirja K\u00fchlewind", "text": "

some groups have a time for re-chartering but often this doesn't really have an impact...

", "time": "2022-07-27T21:00:29Z"}, {"author": "Christopher Wood", "text": "

Thanks, Eric, for running the show!

", "time": "2022-07-27T21:04:58Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho: Adjourned

", "time": "2022-07-27T21:05:00Z"}, {"author": "Lucas Pardue", "text": "

thanks all

", "time": "2022-07-27T21:05:05Z"}]