Session Date/Time: 22 Jul 2026 12:00
[00:02:31] Chairperson: Okay. Good afternoon, everybody, and welcome to MASQUE at IETF one twenty six. So I I hope at this point everybody's familiar with the IETF note well and our policies for conducting meetings and the associated IPR policy. If not, please make yourself aware of it. For the agenda today, we're gonna briefly give an update on the working group status, and the rechartering process, and then we'll have presentations on the active drafts and some drafts in related working groups that folks wanted to present here. Please do join, Meetecho if you're present in the room just to make sure that we get a similarly sized room at our next meeting. I see 29 people currently in Meetecho and quite a few more than 29 people in the room. Does anybody wanna adjust the agenda? Very good. Okay. So the working group status. So since last time, connect Ethernet and UDP listen have been submitted to the IESG. Ethernet's got some minor nets that I think are being resolved if they're not already resolved, and UDP listen is awaiting the next IESG tele chat. Quick proxy has been, fixing a couple of issues, and we think it's ready if or very nearly ready for working group last call.
[00:04:04] Tommy Pauly: Tommy Pauly, Apple. Right. So I I I don't know if Eric Rosenberg is on the call too.
[00:04:13] Eric Kinnear: Probably not.
[00:04:14] Tommy Pauly: But for a bit of the status there so we did a number of updates based on Kazuho and MT's input and had other email discussions, etcetera. I think the one remaining thing that we do plan to do is part of the updates that we did in response to the Kazuho's changes. There's one kinda late response to that of, like, oh, there's an issue with some of the CID management of teardown that we do need to address. So I think there's one issue that was just opened up this week to address that, and so we'll wanna close that issue, rev a version, and then I think we should be good to
[00:04:52] Chairperson: go. Okay. Fantastic. And then with the other drafts, we have connect IP DNS. I believe that's still awaiting a second implementation. That was the status of the last working group meeting. We've adopted oh, go on David.
[00:05:14] David Schinazi: David Schinazi, MASQUE Enthusiast. So, yeah, I mentioned at the last working group meeting that I didn't have time to write an implementation, and I still don't, but Gemini did. So I have one. I'm I didn't have time because I did it last week to interoperate with Yaroslav, but we're gonna try to synchronize, make that happen soon. And if anyone else has a Connect IP implementation that they wanna live-code this in just to make sure that all three AIs produce the same result, then I think we have a good spec.
[00:05:44] Chairperson: Yep. Many agents make light work. Cool. And since then, we've also adopted two new drafts, datagram compression and ECN DSCP, and the MASQUE proxy informational architecture document is still awaiting recharter. So sometime last year, I proposed some text for our recharter to sort of begin closing down the MASQUE working group and to also bring, the informational draft within scope. We got some very polite feedback from some members of the working group that it was far too long as a change, and they did not read it. We now have a much shorter proposal from Martin. So it's a a much smaller diff in the overall text, and this is the entirety of the new text it introduces. We're gonna leave this on screen for a minute or two for folks to just stare at. And if they wanna give us early opinions on this text, that's perfectly fine, but we will not have a substantive discussion today. We will defer that to the mailing list.
[00:06:51] David Schinazi: It's me again. I think overall, this is good. I would complete its adopted documents is probably not gonna fly with the IESG because that's kind of a blank check since you can decide what you adopt. But if you just kinda scratch that and say, we'll complete the following, an extension
[00:07:07] Chairperson: And then you
[00:07:08] David Schinazi: app, I think we're good. It's simple. Ship it. We're
[00:07:11] Chairperson: done. Fantastic.
[00:07:31] Eric Kinnear: Eric, Apple. Not Tommy, though. I think this makes sense. This is essentially what we said all along that we wanted to do. We said a little while ago that we wanted to give out kind of a last call for any additional extensions that wanted to show up. I think we've done some of those. So this this seems entirely consistent with what we've what we've been kind of talking about as a group the whole time. And I think the text reflects that well.
[00:07:57] Chairperson: Thank you.
[00:08:05] Zaheduzzaman Sarker: Okay. Eric, you already talked. I didn't know where overstepped on Eric. Right? So I'm on the queue. So Yes. Eric is Yeah. Yeah. It's okay. I thought, like, Eric is still talking. Yeah. So I I think I like it. This is simple, but I also agree with David like this. It may also add up doesn't will fly with IESG. But I also would like to see, like, if something pops up in future that needs some extension or work in I where it should go.
[00:08:39] Mirja Kühlewind: Okay.
[00:08:39] Zaheduzzaman Sarker: So I think we need you can, like, you can talk with the Edis. Perhaps that's like TSBWG will take it or not or something. You reach out to her. What was the plan? And are we going to keep the mailing list open or not? That those things need to be a bit sorted out.
[00:08:56] Chairperson: Yeah. Mean, we're not closing down the working group at this point. Right? We're just re chartering to not take on new work. So there'll still be a mailing list. We'll still be meeting. Yeah. We'll just be adopting new documents.
[00:09:04] Zaheduzzaman Sarker: So so the thing is, like, we're we're saying, like, we're we're not going to add up any other work. But tomorrow, something popped up, like, we have something broken. Like, some some time ago, Martin Duke was saying, like, hey, you created this loop, and I I deployed the ethernet, connect ethernet. I find some flaw. And that needs some biz work or some new work. I mean, this charter will not be able to do those kind of things. Yeah. If there is, like, critical extension needed to be done, where should it go? So then that's that this text doesn't reflect those out loud.
[00:09:35] Chairperson: No. It doesn't. But this is just a charter for this working group. It doesn't bind another working group.
[00:09:39] Yaroslav Rosomakho: Okay.
[00:09:46] Mirja Kühlewind: Mirja Kühlewind here. You said this is a whole text, so there's not even a paragraph saying MASQUE is something fancy?
[00:09:54] Chairperson: Sorry. What was the question?
[00:09:56] Mirja Kühlewind: Yeah. This is the whole text, so there's not even anything in the charter explaining what MASQUE itself is.
[00:10:01] Chairperson: This is just the the
[00:10:03] Martin Seemann: this is just what we are what we are adding.
[00:10:04] Mirja Kühlewind: Okay. Sorry. And okay. I okay. Then thank you for unconfusing me. But I I think the last sentence is needed. This working group will not adopt any other work. I mean, that's like it cannot because it's not a charter. And, like, when we've done with all the work, we should have a short discussion saying, are we ready to close? And then we close. That's it.
[00:10:26] Martin Duke: Martin Duke, Google. Minus the minor word, specifically, is great. I think it puts us on a clear path to close, which I think where we should go. Regarding, like, stuff that comes up, I think we need a story for where this stuff is gonna live in the long term, whether it be HDBIS or TSVWG or or whatever. I don't know if it has to be in this reach or necessarily. We should think about that and not get distracted by by, like, what if we have other stuff to do? Like, we just need to have a place for that to go and and resist the temptation to stay open to cover these little that come up. Thanks.
[00:11:08] Chairperson: Okay. Thank you, everybody. And so we'll do a further discussion on the mailing list and incorporate some of those changes. And next up, I think we have Yaroslav with the first presentation on datagram compression. Do you want to use the clicker? Hello,
[00:11:39] Yaroslav Rosomakho: everyone. Yaroslav here presenting on behalf of myself and Tommy. We have done a number of updates to the draft. First of all, thanks everyone who participated in the adoption call. Thanks to those who provided reviews and feedback. Please keep reviews and feedback coming. So what we have added? First, we added derived field detailed definitions of the derived fields. Previously, we just listed the fields and left it as an exercise to the reader to figure out where to find definitions of those fields and how to correctly derive them. So we decided that it makes sense to provide more detailed guidance, and that was a little bit more sophisticated endeavor than I suppose we anticipate. So for each derived field, we now have detailed text. What is it? And rare and references where the divide derived field is located. So how do you find it? Specific sender behavior. So if you're a sender and you're deriving something, what do you need to check-in the packet before you can safely derive it, meaning remove it from the packet structure and apply relevant context. Similarly for the receiver. So you received datagram, compressed datagram with field derived. So what should you check how to and how to recompute derived fields? So make sure that you're not generating a corrupted packets. And in the process, we found out several sharp edges that some implementers might not necessarily be intimately familiar with, such as effects of the fragmentation or I p v six jumbo grams. So here's an example, I p v six payload length. So we say in the draft that it is a payload length field located four bytes at at four byte offset from the start of I p v six header, and it is of two bytes length providing relevant reference. And then giving instructions to the sender, so sender needs to check that it is indeed I p v six packet. So that is a header, and it starts with six. And the I p v six payload length is actually equal to number of octets on the wire when it comes to packet, so you don't have this interesting conflict of actually packet having different number of octets than what is specified in the header. So if that's the case, then you really shouldn't be removing packet length. And that payload length is not zero, which is an indication of I p v six jumpogram. Not sure if anybody uses those things, but they do exist. They are specified. So we need we need to take those into considerations. And then similar receiver checks that it is indeed I p v six packet and is the computed well your off payload is greater than zero and is less than six five five three five. So it is indeed a valid I p v six non jumbogram packet. So similarly, guidance provided for all the defined derived fields. We have added one more derived field Ethernet FCS. So perhaps an oversight in the initial version of the draft that connect Ethernet actually requires FCS to be transmitted, which was quite surprising to me, frankly, because I never ever saw any, at
[00:14:59] Tommy Pauly: least,
[00:14:59] Yaroslav Rosomakho: software breach or tap that would give you FCS. Normally, those are stripped away checked and stripped away on the kind of very hardware level of the NIC and recomputed and injected there. So the current connect Ethernet draft says a future extension could introduce a different encoding, and that's where we are. The future arrived with the derived Ethernet FCS field. So if you don't want if you want to do connect ethernet, but you don't want to transmit the FCS field, and I suppose in most cases you don't, then use this extension with datagram compression, specify that you derive that field. And if the other part agrees, then you're free to not transmit that. Right. So few additional guidelines for implementers were added. Avoid MTU oscillations. So make sure that you define broad enough templates that cover reasonably wide sets of packets. Use datagram capsules if necessary. So if you received the one of a kind packet that you did not expect, of course, you can drop it. And the other option, if it doesn't fit in your MTU and cannot be transmitted inside quick datagram, you can use datagram capsule. Of course, you need to be very careful not to incorrectly advise MTU discovery process that your MTU is larger than it is. Listed fields that could be commonly temp we we have listed fields that could be commonly templated as a guidance for implementers and listed some fields that normally should not be templated. So, again, it's up to the use case. So, for example, TOS field is listed as should not be part of the template, should not be templated because it can change over time. But, again, it really depends on implementation use case. If you're transmitting Internet bound traffic and TOS should be set to zero anyway because whatever QS agreement you have with your parties, then maybe it's okay to to template it away or set it to zero anyway if if if that's what you do. So it will be very much implementation specific. We have also defined conflict behavior. So there is one potential well, there are many ways how you can shoot yourself in the foot there, but one of them is you could define check sum offload and check sum derivation at the same time, so don't do that. And if your party does that, then it's a catastrophic mistake, and you should you should not proceed if the other party is misbehaving that way. So as a reminder, checksum offload is providing just a pseudo header checksum that is commonly used together with network interface cards, hardware checksum, LR4 checksum offload. Very convenient thing, very useful for performance. And checksum derivation completely removes the checksum, so you do need to recompute it without any kind of hints. So few examples on how of what valid context chaining could look like. So we specify and thanks, Magnus, for your reviews. We will emphasize a little bit more of that what valid and invalid context chaining look like. So valid context chaining looks like you could have context a that is defined by a template, context b that is defined by derived fields, such as, for example, I p v six length, and context c could be checksum offload, and you can chain them together. That's perfectly legitimate. Or you could have two, such as, for example, derived and the template. So that's all perfectly fine. Invalid would be having the same type of context at the same time. So you have template that is using as the next context derived field, and that is using as the next com context another template that would be incorrect construct. You are supposed to be using one type of context only once in the chain. And similarly, as I already mentioned, you cannot do check some offloading and check some derivation at the same time, that that that chain would be incorrect, mustn't be happening. So our further steps. Right now, we have closed all outstanding issues by the time it was published, and then Magnus gave an excellent review and opened loads of issues, so we will be addressing those. So more reviews, please. We would be very grateful if it's not just Magnus who reads the draft, but many other people in the audience and opens open issues and ask questions. We are planning to work on prototype implementations and interrupt testing. So if anybody have Connect IP or Connect Ethernet implementation and they would like to implement this specification or even part of this specification, that will be great. The early interrupt would potentially uncover some of missing pieces or sharp edges in this specification. And that is it from my side.
[00:20:23] Eric Kinnear: Mike.
[00:20:25] Mike Bishop: Mike Bishop, mostly no hat. Just I appreciate that you added the FCS here because when I was reviewing connect Ethernet, I had had the same question of why would that be. And if you don't have a hardware offload that will recompute it for you, it does make sense to potentially trade off a little extra bandwidth for saving the CPU cost of recomputing it. If you do have a hardware offload, definitely save the flights.
[00:20:56] Yaroslav Rosomakho: Thank you.
[00:20:56] Mike Bishop: Thank you for adding it.
[00:21:03] Gorry Fairhurst: Gori, no hats. Two questions. You said jumbo frames but did you say jumbo frames were not supported?
[00:21:12] Yaroslav Rosomakho: I I was saying that
[00:21:14] Magnus Westerlund: Jumbo grams.
[00:21:15] Yaroslav Rosomakho: Jumbo I p v six jumbo grams. You cannot do you perform derivation operation on certain fields if you have an I p v six jumbo gram.
[00:21:26] Gorry Fairhurst: Do you need to specify jumbogram behavior? How are you going to test it?
[00:21:30] Yaroslav Rosomakho: Jumbograms have I p v six length packet length of zero. Sorry.
[00:21:35] Gorry Fairhurst: Yeah. I know. But what what operating systems support it? I mean, is this a real thing? Just a question.
[00:21:40] Yaroslav Rosomakho: I I'm not aware of any practical user of that, but RFC is there. It's not obsolete. So I suppose it's a good thing to check if your I p v six length is not zero.
[00:21:51] Gorry Fairhurst: We can talk. Okay. Okay. The second
[00:21:53] Yaroslav Rosomakho: thing I'm all for objecting jumpograms. I'm probably not as a part of this draft, but yeah.
[00:21:57] Gorry Fairhurst: Right. UDP length. Are you assuming the last byte of the UDP datagram payload is the last byte of the IP packet? In other words, do you consider UDP options on that dead space that can exist?
[00:22:13] Yaroslav Rosomakho: Sorry, could you repeat the question? Didn't quite catch
[00:22:15] Gorry Fairhurst: Do you assume that the UDP datagram last byte is the last byte of the IP packet? In other words, can there be other data after the end of the UDP datagram?
[00:22:30] Yaroslav Rosomakho: Not sure. I would have to check. I don't think right now we are accounting for UDP options.
[00:22:36] Gautam Akiwate: Okay. Thank you.
[00:22:37] Yaroslav Rosomakho: Good good good call. Thanks.
[00:22:42] Eric Nygren: Eric Niagara, just answering the question at the mic. Yes. UDP datagrams are or jumbo I p v six jumbos are a real thing. They actually work fine in Linux. You just have to be careful with path MT discovery issues, and you need your network to support them. But they are a real thing, and people use them.
[00:22:57] Yaroslav Rosomakho: Okay. So we are not going to deprecate them just yet. Thanks.
[00:23:01] Magnus Westerlund: Magnus Festlen, Ericsson. One of my issues, I think, is to clarify that the reasons to verify very clearly the UDP IP lengths correctly is UDP options. So I I it's on your issue tracker at least to fix.
[00:23:19] Yaroslav Rosomakho: Okay. Yeah. Yeah. And, again, as we were writing it, we discovered lots of things that initially didn't think about. I'm pretty sure there are some other interesting corner cases, so please take a look at the draft and share your feedback. Thank you. Eric? Yep. Okay. Okay. Thank you. Thank you,
[00:23:55] Chairperson: Okay. Next up, we have ECN and DSCP support for HTTPS's Connect-UDP. Yep. Do you want to use the clicker, or do you want us to drive?
[00:24:20] Mirja Kühlewind: It's only so it doesn't matter. Hi. My name is. My coauthors are Magnus, Marcus, and Martin. And we adopted this draft recently, and we already published two new versions. So the the zero zero version is really unchanged, just a working group document as a working group document. The next version, we did some minor fixes. We changed the byte alignment in the context assignment format, and we added some initial security considerations, but those are also work in progress still. And then I just now, like half an hour ago or something, submitted another version where we added a closed capsule. I don't know why I did this in the first place, but now it's there and we can start discuss this if you guys want to. So what do we have? This is to support ECN and DSCP in Connect UDP. And we have made one decision or we made a couple of decisions over the last couple of meetings that we try to go for simplified version because at at the beginning, we had some complex multiple extensions to cover everything. But it's really just like one extension, and when you assign a new diff serve code point, you always also have to assign all four ECN code points and provide context IDs for those. That makes sense because, first of all, we want to enable ECN, and second, you never know which ECN markings you will get, so you should always assign all four of them. The way we do this is that we provide a HTTP header extension, and you can already assign a first set of these context IDs in the in the HTTP header. If you if your usage of diffs of code points is kind of static, then you're done. You don't need to do anything else. But you can also assign new ones later. So if you see that a new code point is used on your flow, then you have to send an assignment capsule and you will get back an egg or a closed capsule, which is not on the slide because I didn't update it correctly. So this is how the capsules look like. I also noticed right now that, like, I added a new closed capsule and I only put the context ID in there that is closed. And, like, for the egg, actually, we have the whole assignment format that's probably not needed, so we can update that. But the idea is similar, and, like, all the other extensions, you receive an assignment, and then you have to send back an egg or a close. In theory, can also use the close to close something later. This might have benefits when you I don't know if you get too many assignments or whatever. But we don't really see a good use case for it because usually if you've got an assignment and you seen a draft serve code point, why would you remove it? It's not clear, but in theory it's there. This is the assignment format. As I said already, you assign always four context IDs to cover all of the ECN fields. Okay. We do have actually three open issues, but I also would like you to review the draft and open more issues. Now it's a working group document. One of them is related to optimistically sending. So we did add, in some of the last versions, the idea that you can, as soon as you send out the assignment, because that's what usually happens. You get a packet, you see a new gist of code point, you send out the assignment, but then you also want to send out the packet immediately, basically. So you can send it out optimistically, but we don't provide enough guidance. Then you will get an egg or a close, so we don't provide enough guidance yet what to do. If you actually receive a close, should you, like, actually store them and resend them with a different sift of code point, or should you close the connection? Also and this is a general question I have also for all the other extensions we did in the past. How long do you actually wait for an egg or close to receive, and when when do you think the you know, you will never receive it and that violates the protocol and you should close the connection? Any thoughts? No.
[00:28:31] Ted Hardie: I need to go back and
[00:28:40] Gorry Fairhurst: I could use the tool, I'm sure. Corey, is it how long or is it when you see more packets afterwards and how many?
[00:28:49] Mirja Kühlewind: Say it again. Sorry.
[00:28:51] Gorry Fairhurst: You say how long do you wait for your clause, but then if you see more things happening afterwards, that might just be the trigger rather than so the time becomes rather insignificant. Yeah?
[00:29:03] Mirja Kühlewind: I mean, you send it you see a new packet with a new diff serve quote point.
[00:29:07] Zaheduzzaman Sarker: Yeah.
[00:29:07] Mirja Kühlewind: You put it into your tunnel and you send an assignment, you send both out to the other end and then at some point you will get an egg back. And in the meantime, you of course receive more packets, probably with the same diff sub point.
[00:29:17] Gorry Fairhurst: So do you count those as a trigger that you've seen so many? Is it time and similarly for the close?
[00:29:23] Mirja Kühlewind: I mean, all depends on how long the other end needs to reply to you. Right? Okay.
[00:29:30] Gorry Fairhurst: Yeah. Yeah.
[00:29:33] Mirja Kühlewind: I mean, on the other hand yeah. Yeah. Go ahead.
[00:29:38] Ted Hardie: Ted Horty. I had a big lunch, and my brain has slowed greatly as a result of the kind of carbo loading. So forgive me if this is a stupid question. If I understand correctly, the question, should you store and retransmit on closed for optimistic ending of datagrams. So the order you're talking about here is you receive a close, and at that point, you retransmit any datagrams that previously have been transmitted and are not act. Is that what you mean?
[00:30:09] Mirja Kühlewind: So you receive a close. That means all the datagrams that you send with the context ID that you tried to assign before and wasn't assigned are probably dropped at the receiver side.
[00:30:21] Ted Hardie: I'm really struggling to figure out why the retransmission would be unexpected behavior here. And
[00:30:29] Mirja Kühlewind: I don't know.
[00:30:31] Ted Hardie: Then let's not.
[00:30:35] Mirja Kühlewind: I mean, I think it I mean, maybe we cannot provide any so, I mean, I think I think that is the case for it. Maybe we cannot provide any guidance because it really depends on your deployment and what you're using those diff serve code points for, right? If you have knowledge that these diff serve code points are serving a purpose where you want to retransmit, then maybe you should retransmit.
[00:30:55] Magnus Westerlund: Magnus Westin. I think this is part of the saying where I do expect normally just to register and tunnel them and let them be gone. And I think this comes into the question, should you have at all kind of is there any reasons to reject a particular different code point at the ingress to the ingress? And what does that mean? Is and I think the context here may be more like, oh, should I then bleach it to zero? Or should I do something else? Just drop it becomes the question. So that's maybe this kind of guidance is maybe more what we need to include here. So
[00:31:37] Mirja Kühlewind: But, I mean, that goes a little bit back to the question if we need close egg and close at all because you send the assignment, you know that the assignment was received. And then if the other end doesn't like your assignment, then it could also close the connection or whatever. I don't know what the right thing is to do.
[00:31:54] David Schinazi: David, it's Kanazi. I think we should just follow what every other MASQUE document is doing, which is saying that you can send optimistically even if you haven't received the ACK yet, knowing that it might get lost. This is UDP. It might get lost 17 different ways, and that's okay. Just keep it that simple. Don't try to innovate here. Lot lots of foot guns in this space.
[00:32:22] Mirja Kühlewind: I mean, I think that there is missing guidance in the other documents as well because they all say you must send an egg or a close, but they don't say when you have to send. I mean, like, you should send it immediately. But, like, what do you do? At some point, if you don't receive anything, what do you do? When do you do it? And that's a general question. So because the point is if you don't send optimistically, you probably have to store the packets as well and have to send them as soon as the assignment is done. Because they are slightly different extensions, right? Sometimes it's just okay to send something without an extension and it doesn't make a big impact. But in this case, you really want to have the diff serve code point, and it's not clear if you want to send it without the diff serve code point.
[00:33:17] Tommy Pauly: Tommy Polly, Apple. So for the close, is the idea that you would send the close instead of the act to say no? Could because this is something we're dealing with in the
[00:33:29] Mirja Kühlewind: Yeah.
[00:33:30] Tommy Pauly: Quick proxy as well. Can you send a close later?
[00:33:34] Mirja Kühlewind: Later than what?
[00:33:35] Tommy Pauly: So do you act? Yes. And then, like, ten minutes later, you're like, now I close this one.
[00:33:40] Mirja Kühlewind: Yeah. I mean, that's that's how we define it now because that's how all the other extension extensions are using it. They say you can either reject it immediately or close it later.
[00:33:48] Martin Thomson: Right.
[00:33:48] Mirja Kühlewind: Not sure if that's useful.
[00:33:50] Martin Thomson: Okay. Because it'd be,
[00:33:52] Tommy Pauly: And I think is referring to this. Was like, do we think anyone is going to close it later? And I almost wonder, like, if instead of closing, it would make sense to have a a way to say that you replace the definition. Like, this pattern now is just defined back to be some other context or if you wanna replace it for some reason.
[00:34:16] Mirja Kühlewind: Yes. So, I mean, there's just a limited number of diffs of code points, so you wouldn't expect too many assignments anyway. But and even if you wanna change it, you could just, like, use have a new assignment for the same difficult code point and and use that. I don't know why you wanna do that, but you could. The whole discussion came actually up when we started working on the security considerations, and we figured out there's actually no way for the receiver to manage the number of assignments. And, like, I don't I don't expect this to be a problem in this case, but
[00:34:42] Tommy Pauly: But it's an it's a possible attack to say, I'm gonna open up
[00:34:46] Mirja Kühlewind: again, this is true, I think, for most or all of the extensions. Mhmm.
[00:34:50] Eric Kinnear: Yeah. State commitment. K. Yeah.
[00:34:55] Mirja Kühlewind: Okay. I'm like, yeah, it looks like we need a little bit more discussion. Please go to the issue. There's one more issue which is on the I have the clicker which is on the next slide, which should be easy. So you have this assignment in the in the initial assignment in the header, and we were just wondering, should we always recommend that you should make an assignment for the code point zero? That's kind of the base one, or does that not even make sense? It just would just be a recommendation. Is that a good recommendation? Or don't we even not talk need to talk about it at all? Okay. You can comment on the issue. It's not like a big thing here. We have a third issue open that I don't have a slide for. Go ahead, Magnus.
[00:35:46] Magnus Westerlund: No, I think it's this the next what you wanted to bring up, which has to do with the extensions, which I think is we don't actually have examples, I think, for Connect-UDP where we have another extension in the working group. However, 3PPP has defined a mechanism. However, they seem to have lost in the process the actual assignment for this Jenkins to work correctly. But we basically should have one other example to point out where you actually have different context IDs. So I think we're we are gonna have to figure out how to connect this to other extensions being used that assigns other context IDs. So
[00:36:36] Mirja Kühlewind: Yeah. And the question for me is, and that's why I didn't put it on the slides, is this is maybe not maybe also the other ones aren't, I don't know not an issue that is specific to this draft. No. It's true for all the extensions, like how can we combine them. This extension is more likely to be combined with other extensions than some of the other extensions. But I think we need to address this question in a general terms and not only for this extension. But I mean, that's a little bit of question to the chairs, maybe what you want to do about this And adding extensions together
[00:37:16] Magnus Westerlund: I think it applies to rechartering because we need room for in the charter to actually work on this question of figuring out how to handle extensions interacting with other extensions. Because I think this is important guidance to the future of usage where other extensions are defined by other bodies or working groups in the field. So
[00:37:40] Mirja Kühlewind: And I also wanna say we took this out of the draft because that made it easier to adopt the draft, but I think we still need it.
[00:37:50] David Schinazi: Well, I think if you David Skenazi. If you took it out of the draft, so we were to drop the draft, there might be a reason that some people are opposed to that and would be opposed
[00:38:00] Mirja Kühlewind: to I'm the just saying it would have required more discussion before we were ready to adopt.
[00:38:04] David Schinazi: Yes. Anyway, I think figuring out this grand scheme for combining extension is somewhat boiling the ocean. I think we intentionally skipped this for the previous extensions. We I still have yet to kinda see a use case for this. And I know that 3GPP are doing some weird things with all this, but I don't think any of that's gonna ship. So I'm not too worried about it. They can do what they want. So I would say let's punt this from this document as well and punt it from the recharter until we have an actual use case for it.
[00:38:41] Mirja Kühlewind: I mean, so the the the use case comes up as soon as so because this is an extension that you likely hopefully, if we have, like, the shiny ECN enabled world everywhere in future, you would you wanna use it on every connect UDP connection. And as soon as you have any second extension for connect UDP, you're running into that problem. Right?
[00:39:05] David Schinazi: I agree, and I would prefer to cross that bridge when we get there.
[00:39:10] Mirja Kühlewind: Okay. And then you hand this to the HDP working group? Or okay. Anything else? No.
[00:39:23] Gautam Akiwate: Thank you.
[00:39:31] Chairperson: Okay. Next up, we have Gautam. I hope I'm pronouncing that right. To present a draft, which is not gonna be adopted at mask. It's for DNS op, but is of interest to the the MASQUE working group.
[00:40:02] Gautam Akiwate: Should be good to go. Thank you. My name is Gautam Akiwate, and together with Tommy, Polly, and Eric, we have been putting together a draft that sort of talks about defining HTTP header fields that will enable a proxy to relay SBCB information. And as I said, this is not intended for MASque, but we figured that this would be of interest to folks here. So we figured we would do this here and and at some later point of time, we are going to also present this in DNS op. So the reason why we would want HTTP header fields so that the proxy can relay SCCB information is the if the proxy is doing DNS lookups on behalf of the client for a variety of reasons for privacy, say, we're losing out on a lot of rich information that svcp, https, https resource records provide. So for instance, whether the target supports h three, ECH and the client can then appropriately choose Connect UDP versus Connect based on that information. So this document essentially defines a few different classes of HTTP headers and roughly there are four headers that we define. The first is the client requesting the SVCB request. So this is pretty much saying the client saying, hey, proxy, as you're doing your DNS lookup, I'm also interested in the SVCB HTTPS. The second set of the second header that we define is the proxy responding to the client saying, here is all of the SVCB records that I found. And as we were defining as as we were thinking through this draft, we also realized that the client might have a preference for one, like, say, versus connect UDP and might want to sort of signal to the proxy, hey, proxy, I would really prefer connect UDP, but I don't know if the the target supports connect UDP. So here's connect, but if the target supports h three, then I want you to, like, close the connection opportunistically and just send me back the SVCB, and I'll try again. There are there is also a case to be made for ECH. And then the fourth set of header is basically the proxy responding to the client saying, hey. I got your h three LPN. Like, you wanted me to close the connection on that. So here here you go. I did it, and here is all of the SVCB information. So I'm gonna go through each of these headers. It's not a lot, but as I said before, the client requesting SVCB HTTPS resource records, This is NSF token. All it says is I would like the HTTPS or SVCV, so this is essentially an SVCV token. The token value must be SVCV or a compatible type. When a proxy gets this, if it supports it, it will essentially take the binary encoding and send it back to the client using this header field, the proxy is expected to send back every SVC B record that it encountered as it did the resolution. If the proxy does not support this, then it should not include anything and the client will sort of infer that the proxy does not support this. Okay, and I was sort of talking about conditions under which a client might want to request a cancel on. I've given one example here. The document lists out a few others, ECH for instance, I think HTTPS too, like I don't want to use unencrypted traffic if the target has an HTTPS resource record, and this is basically a bunch of SF tokens that the client and the proxy have pre agreed upon. And this this only this this evaluation only happens at the the the priority record, the resource, the SVC, HTTPS resource record that has the highest priority, for instance. And then, again, the final one is the proxy responding to the client saying, hey, I see that you requested closure on if the target supported H3, and here you go, like, the target did support h three. So I did not send any of the early data that you had onto the client, and instead I've just closed the connection, sent back you the SVCB data, and here is an indication of all the conditions that matched. So, sort of putting together all of this through an example, and I realized I made them super small, so even if you can't see it, it's basically the client is requesting a proxy DNSSCCV request with HTTPS and it's saying, hey, if the target supports H3 ALPN, then I would request an early close. If this is the HTTPS resource record that the domain has configured and in this case, the ALPN does have h three in it, the proxy sees this and then sort of does not forward the connection anymore. It responds back to the client with the response and says, here you go. And by the way, I did close your connection based on your request for H3 ALPN. And then the client can do with the information what it pleases. In this case, it can retry with Connect UDP. And that's pretty much it. The goal is super simple. We have four headers, the client proxy sort of interacting with each other, trying to give us information and that's the goal. So if there are questions, I'm happy to answer them.
[00:47:01] Martin Seemann: Yes, I have a question with no hats. And we already talked about this a little bit on the hackathon. So I'm not a DNS guy, so I don't have any, like, strong opinions, but this feels it feels kind of complicated. You're like putting taking different DNS records and then defining how to serialize them in HTTP headers. I'm wondering that with all the amazing work that's going on in the v6ops working group, it seems like the client is the the right place to make to make all these decisions of, like, which transport to use and should I use ECH, which h h h t p version. What if you just ran a DNS over h t t p server co located on on the proxy server, on the MASQUE proxy server, and just have the client reach out over the the same quick connection
[00:48:02] Gautam Akiwate: Mhmm.
[00:48:03] Martin Seemann: To that server, get all the information that it needs, and then just feed that into the the normal happy eyeballs algorithm. Yes. Make all the all the all the decisions on the client side, and then just dial via the proxy.
[00:48:19] Gautam Akiwate: Yeah. So that's a perfectly valid strategy. The only downside of that approach is that now we're spending a round trip trying to get this information. So in the most common case, the, so considering a scenario, let's say you would prefer to use Connect UDP, but in the most common case, it's not supported, so you're going to end up using Connect, so with this sort of technique, you're going to use connect and you're essentially going to optimistically use connect and be like, if there is connect UDP, if I have the option of connect UDP, you can cancel. So in the most common case, the happy path, we are not spending this round trip trying to get DNS information on something that does not exist. So that's pretty much the motivation, but you can do the DNS over HTTPS. It's just you will spend a round trip getting that information, but it's a perfectly valid approach, And we could do that too.
[00:49:24] Eric Kinnear: Hi, Lucas. Pardon. So thanks for the presentation. I I kind of read the draft and understood the use case for passing some of the information DNS information around in the headers. I'm cognizant that this isn't adopted draft in this working group. So I don't want get too much into that. I hadn't quite understood the the nature of the conditional request that you're making before I saw the example. So so thanks for that one. Raises some questions in my mind. I don't want to go into maybe. But the one question is, should maybe actually mask have a different method that says connect using A or B under these conditions so that it then happens and it just picks and if you're trying to save round trips, you know, you could save an additional one. I'm not saying that's a good idea, but to to consider it, I understand the problem statement correctly.
[00:50:18] Gautam Akiwate: I'm yeah. That that would be acceptable. I thought mask was not taking any new more new work, but that sounds like a perfectly valid thing. I don't know what shape it would take, but that would be interesting.
[00:50:39] Martin Thomson: Martin Thompson. I had much the same reaction to Martin Seumann. I think this is a pretty bad idea, to be frank. I think the idea of having a conditional connect is is far more interesting in that respect because one of the problems with this arrangement is that you're effectively tying the two requests together and burying one of the requests in the header fields. And that seems like a like a poor poor choice of of design. Whereas if you say, please connect over this, but only connect under the following conditions, that's something that HTTP basically already does with with if whatever predicates. So my suggestion to you would be not to try to do the sorts of things that you're doing because I think that has some interesting implications for things like the life cycle of the different requests and what have you. And also, your header names are far too long.
[00:51:45] Gautam Akiwate: Okay. I think it would be useful for us to chat as well to get your concerns. But thanks.
[00:51:53] David Schinazi: David Schinazi. I think this is an interesting space, and I think it's definitely worth exploring. I have similar concerns about the specific solution. I I wouldn't quite go as far as Martin did, but I think that there's a lot of sharp edges here, and it seems hard to get right. I guess what I would think my apologies if I haven't had time to read the full draft yet. But I think starting a bit from first principles on what is the path that we wanna optimize for might be useful. Because if we say, oh, most of the web is connect, and we think most of it will do connect, and then there's this error path, if it turns out that the website supports something better, we're kind of optimizing for the old, not well lit path. And so I I I think definitely worth keep keeping going on this, but I I think my intuition is that there's a way to do this that's simpler, hopefully.
[00:52:51] Gautam Akiwate: Okay. And and just as as a point, like, it could also be that you choose to do connect UDP with saying, if it doesn't, then, like, also early close. So, like, that's also an option. Yeah.
[00:53:06] Mike Bishop: Mike? Mike Bishop, not with a hat at this point. So part of the point behind the service b records was to give the the bucket of information we wish the client knew before it started the connection. And in this case, the client is learning that information midway through the connection. It's done the transport layer but not TLS and up, essentially. So that really subdivides the space into two pieces. There's the where do I establish that transport connection, which the proxy needs to know. And this the client might like to know what the proxy decided, but it's already happened at that point. And then there's the stuff the client needs to know for those higher layers like ECH keys. So I don't know if passing the entire service b record is necessarily the right structure. Maybe it is. The thing that really makes me uncomfortable is three zero seven coming back from that. You're doing an HTTP redirect to what? A different method?
[00:54:18] Gautam Akiwate: It is a placeholder, and we were not sure what the thing was going to be. So, like, the three zero seven to subject to further discussion. So yeah. The direction that Martin's pointing,
[00:54:30] Mike Bishop: I think, is potentially a lot more productive of being able to say, connect if the following things are satisfied or if not the following things. And then the server can come back with, well, it didn't meet your requirements, so I didn't do the connection. That's that's something that HTTP has. You would be defining new conditions and, okay, that's potentially interesting.
[00:54:54] Lucas Pardue: Okay.
[00:54:57] Mike Bishop: For the rest of it, we'll talk. Okay.
[00:55:04] Eric Nygren: Eric Nygren. For some context, I think having thought about this problem and started it a bunch, it's certainly full of sharp edges. And kind of where we landed in this draft is, like, if we're gonna do it this way, it's possibly one of the less sharp edges ways of doing it because you do need to get all of as, get all of the information to the client. And there's enough logic there that just that the simple conditionals would be really, really hard to express the logic needed to do things right give without exposing too much surface of information or fingerprint information from the client's behavior. So but I think there are some I think some of the, like, what problems are we trying to solve is a good question because if we're, if we like, the the conditional cases are really most useful if the proxy is h t p one one and you wanna be able to reuse a persistent connection. If we assume the proxies are always gonna be h two or h three, then that's less important. And then maybe the parallel DNS requests over over and on a different stream might give similar results. I think the other case where the cancel can be useful, which also may be one that we decide is not a good thing anyways, is in the ECH case where you want to send your client hello in the same flight as the as your connect request. I'm just gonna, like, pre send the the the the client hello, and that's the one where you do want to do that instead of ECH has stuff you don't leak information and it's kind of one of the other use cases for it. But it's still there's a bunch of corner lots of corner cases here.
[00:56:39] Lucas Pardue: So I think this work is quite interesting, especially returning the IP addresses and DNS records through it because I think that's a gap at the moment. And sometimes the browser would like to do things through a proxy treat posts in a specific way, but it doesn't have that information unless it resolves that through the outside of the proxy or through the proxy. But that still might be different than what the proxy's view of DNS is. So I think that's valuable. I don't know if the headers are the best way to do it, but I still think that's important. The other thing is connecting and, like, only connecting when certain properties hold. That still requires a round trip. So you'd still get a negative response, and then the the client would have to do another connection. I do think that either other idea of, like, connect to this thing using quick if possible or or not, and then the the proxy does it for you. I think that's probably better because it doesn't require another round trip. So yeah.
[00:57:46] Gautam Akiwate: Yeah. I think so. That was also something that Mike was suggesting. So that's worth discussing. So I think maybe we should talk because it seems like a promising idea, but I don't know how much work that would be.
[00:58:00] Yaroslav Rosomakho: Hi. Yaroslav, Zscaler. I really like the kinda first part, the SVC b request response. Maybe response should be going into proxy status header. Not sure if it needs a separate header, but the cancellation thing feels very overengineered and open ended, not in a good way. So you have to have some kind of agreement before what you support, what you doesn't, it's very, very specific for certain use cases. And for of course, it's it's unhealthy generalization, but still connects are relatively cheap. Connect UDP is not really anything that is happening, so you don't have to signal with somebody to start Connect UDP. You just open a socket and hope for the best. So, yeah, my recommendation would be to just drop the conditional thing. And with that, if it's just HTTP SVCB, HTTPS request response, maybe HTTPBIS would be better place for it if you don't really do anything DNS specific. They are simply sending request responses. K. Thank you.
[00:59:12] Chairperson: Okay. We've drained the queue there. Justin, do want to remind everybody where to go to discuss this draft further? Is it the DNS op mailing list?
[00:59:20] Gautam Akiwate: Yes. Yeah.
[00:59:21] Chairperson: Okay. That's great. Thank you very much. And next up, we have Yaroslav to talk to us about BGP. This is another draft that is it's in the inter domain routing working group. Yeah.
[00:59:40] Yaroslav Rosomakho: Hello, everyone. So BGP Signaling of MASQUE Tunnel encapsulations. So this is one of those exciting, at least for me, drafts where I try to connect two separate oceans that don't normally talk to each other and see if we can extract some some synergies there. So BGP. BGP is past distance vector protocol, runs on top of TCP. It's the main routing protocol on the Internet. I think it's a first statement. And, yeah, many people honestly believe that that's the most important protocol on the Internet. Clearly, they're not yet familiar with HTTP. That would change their mind, but but still it is important. Over time, it grew from just using just sending I p v four prefixes to many, many other use cases, I p v six, VPNs, flow specification. It is used for Ethernet VPNs and and so on and so forth. So this is a really unhealthy generalization of BGP. Normally, BGP boot camp takes, like, ten days. I unfortunately, I have only ten minutes. So I'll I'll try to give you a really compressed summary of what we're trying to accomplish here. So every BGP speaker has their own autonomous system number. That's how they kinda identify their own administrative domains. ASNs can be public, assigned by registrars, or they could be private. So if you're not a carrier with carrier independent address space, you just want to be a BGP speaker, you don't need to get public autonomous system number. You can just pick one that you like and hope others that you speak to are not going to use the same. So BGP session can be built between speakers of the same or different autonomous system. Now BGP essentially, again, that's unhealthy simplification, but still is carrying key pairs. So it is associating network layer reachability information, which many cases just a prefix. So some something that roughly is what are what is what is the route pointing to with a set of path attributes, which is very roughly how do we get there or what are the attributes associated with this route. So things such as next hop information or IS path, they are path attributes. Those routes are carried in update message. So normally, those update messages are up to four kilobytes. However, there is a relatively new extended message capability that is available. So if peers negotiated that capability, update maximum size is bumped to 64 kilobytes. And surprise, max proxies can be routers, especially when they speak connect IP or when they speak connect Ethernet. They don't have to be collocated with client or server or commune of communication. They can be in the path and essentially from topology perspective drop in replacement of IQv two or VXLAN or other terminating nodes. So from the outside world, that would be seen some kind of a tunnel that is transmitting ethernet or IP or TCP or UDP. BGP is gaining some momentum in SD one overlay usages. There is no, to my knowledge, strict definition of what SD one is, software defined wide area network. It's one of those marketing terms that was defined by some industry analysts or some vendors, not by technical people really, but term sadly stick. So one of the ways how to see to look at SD WANs, it's, you know, like multipoint site to site VPN. So you have multiple sites, you have multiple routers, they somehow discover each other, they establish some kind of trust relationships with each other, they send with different properties packets between each other. They could have multiple paths. They could have all sorts of interesting load balancing riddles to solve. So as one of technologies that SD WAN can be used can be using is for data plane is IPSec, used quite commonly. And we it quite often is using some kind of proprietary signaling methods to define how sites are, how they are discovered. More recently, we see significant increase in BGP usage for SD WAN communication as a control plane protocol for SD WAN. There are there is a number of specifications in BEST and IDR working groups that explain how SD WAN controllers can be using BGP and how sites can discover each other. And they have also developed ways how signal tunneling information over BGP. It is specifying tunnel TLV and lots of sub TLVs in terms of what the tunnel technology is, how do you discover the peer, how do you authenticate the peer so it can be used to propagate IPsec IPsec gateway information and
[01:05:12] Lucas Pardue: can be
[01:05:13] Yaroslav Rosomakho: used to announce various VPN routes and preferences associated with that. So the proposal that Alvaro and I came with is why don't we extend BGP machinery to support MASQUE proxies? It was surprisingly easy to do, deceivingly easy, perhaps. So we specify four tunnel types, and specifying a tunnel type is relatively cheap. So it's it's it's I think it's two bytes. So we can specify many, many tunnel types in the future. There are already loads of tunnel types exist in BGP such as, again, VXLAN and IPsec/IKEv2 and and GRE and so on and so forth. So we're proposing to define connect TCP, connect UDP, connect IP, and connect Ethernet as tunnel types and two tunnel encapsulation attributes sub-TLVs. So those are configuration parameters, so to speak, that BGP speakers would associate it with the prefixes. So I have a certain prefix or certain network clear reachability information. And in order to reach them, I would be speaking to a MASQUE proxy, and MASQUE proxies would be defined in the current proposal as a URI template and ALPN. So, again, it feels that it projects very nicely into existing BGP machinery and could be valid alternative for IPSec based SD WANs, especially when it comes to connect IP and connect Ethernet. Now there are a couple of questions that we have to MASQUE experts. If nobody is brave right now to give their opinion, we can take it to the list. But still, right now, we are not specifying the good old non templated connect, only the novel connect TCP that simplifies specification significantly because we don't need to think about how do
[01:07:07] Gautam Akiwate: we
[01:07:07] Yaroslav Rosomakho: encode destination ports. It's all your right template. So all very, very straightforward. So would anybody have potential issues with that with requiring if you're doing connect TCP then or TCP, and then you're using normal template at connect TCP? And second question is about DNS. So, yeah, that's another protocol that some misguided people think that's the most important one on the Internet. Routers do not like doing DNS lookups because it requires some kind of control plane, can be costly, could have some kind of delay. And we already we already suggest that we could carry ALPN, and BGP machinery already have a way to carry IP address for tunnel endpoint. So that is instead of just having your right template and ALPN, we could have your right template, ALPN, and tunnel endpoint IP address, which already exists in BGP. So having host name and URI template is still useful so that you would be able to validate certificate, include correct host header, but at least the router who's initiating the MASQUE proxy connection won't really need to do DNS lookup. So what any any thoughts about that? So anybody would like to share feedback? Any comments? Anybody finds this useful? Alright. Okay. Well Okay. Well, thank you, Yaros. Thank you. Hope that was entertaining.
[01:09:07] Chairperson: So during that presentation, there was some discussion in the chat about the previously presented draft for proxying DNS lockups. Do folks wanna come to the mic to voice some of those opinions about the appropriate venue for the draft?
[01:09:32] Martin Thomson: The text on the screen gets very small from back here. Go ahead. Martin Thompson, I think that that draft rightly belongs in this group or a group like it. Now I understand that you just talked about the charter and this group is trying to close out, but whoever owns and maintains MASQUE on an ongoing basis should be the one to talk about the integration of of this sort of thing with with MASQUE. I think there's there are DNS considerations that would it it would be worthwhile taking this to DNS op to discuss, but I I think ultimately the the violence that I'm seeing is being inflicted upon MASQUE and HTTP, not not the DNS.
[01:10:27] Eric Kinnear: Hey, Lucas. Yeah. Put it in the chat. Like, I literally, I just don't go to DNSOP. It's all WG chairs. I just don't have the time. So if it went there, then I couldn't help. I would I think it does need the help. So just.
[01:10:42] Chairperson: Lucas, sorry. Can you is the converse true that if it comes here, you would be interested in helping?
[01:10:47] Eric Kinnear: I'd be more likely to attend, but my attendance record for MASQUE wasn't super great in the past. But, yeah, it's more things more HTTP adjacent, I'd be more available too.
[01:10:59] Chairperson: Okay. Thank you.
[01:11:03] David Schinazi: Your lack of enthusiasm is troubling, Lucas. David Schinazi, I I agree that the complexities here are around HTTP itself and proxying and mask. So I would say either we consider this as part of this recharter and have it in MASQUE, or we don't, and we have it where all the MASQUE work will go after MASQUE is closed, which is HTTP bits. So but I I think this is worth continuing. It should at some point be brought to the DNS experts, but I think the complicated bits are all gonna live in HTTP.
[01:11:43] Chairperson: Thank you. Tommy.
[01:11:47] Tommy Pauly: Tommy Pauly, Apple. These are just some comments that kind of inform some of the venue and or things I was thinking early in
[01:11:55] Gorry Fairhurst: the
[01:11:55] Tommy Pauly: discussion. There are things that exist like the proxy status header that already give so it we do have ways to get back what IP addresses we connected to and what were the CNAMEs and other stuff that goes in proxy status headers. And that is something that was done in HTTP BIS. That is a place where we are already putting DNS derived stuff back in headers, partly what this is related to in terms of that. Also, I'll note that there are complexities for SVCB that I don't think it's as simple as you can just do your normal connect request to a name and then in parallel, do a Do request for the SVC or HTTPS records because the act of even looking up HTTPS records cause you to potentially learn a different port or follow different addresses you wouldn't otherwise see. And one of the things that's currently lacking today is any standardization of does the proxy even look up the HPS record. And in the case of svcp, it probably doesn't know how to do that without more information about the URI going over it. So, yeah, I I think there are HTTP and MASQUE connect related like, there are things related to the connect request that would need to be done for the proxy to correctly follow this at all. It's not as simple as just doing something on the side. So that kind of leans towards maybe HTTPS, maybe something here, but then also involving DNS experts.
[01:13:32] David Schinazi: David, it's me again. Can we discuss the draft in general, or would you rather cut that conversation?
[01:13:38] Chairperson: I mean, I think the most proximate question is is where to continue discussing that draft. But, you know, floor's open. We are at the end of our agenda, so if there's interest in that discussion.
[01:13:48] David Schinazi: Well, I just figured I had a bad idea when I sat down earlier, and I wanted Martin to tell me how bad it was, so I might just go ahead and say it. I in terms of the layering here, I think this doesn't go far enough. I think this cobbles a lot of the pieces that we have today of, okay, I want a GPS record. I wanna try this and fall back to that. I think what you want is the next step of MASQUE, which is connects to HTTP going further up the stack instead of lower down the stack. And then, you know, you toss-up your client hello, and you toss-up your quick initials and say, hey. I want HTTP. Do something for me, please, and see what happens.
[01:14:37] Martin Thomson: Yeah. David, you're right. That is a terrible idea. So that that is but but we should explore more of it. I I really only got up here to discuss the the question of venue. I think there's a very interesting question that I don't know has been explored well enough yet, which is what does it mean to do happy eyeballs through a proxy? And this is sort of cracking in into some of that problem. And I think what you've done is sort of made some assumptions about what that is and then taken the next step into optimization, which is kinda cool, but I think it would be better grounded in a discussion in HAPI as well as the ultimate destination of the MASQUE working group for whatever whatever changes to the protocol need to come that follow on from that discussion. So I don't know if that's helpful or not, but I think having happy look more more rigorously at the problem of what happens when you need to work happy eyeballs from a distance through a proxy is something that I would like to see people spend a little bit more time on, and then we can talk about what sort of optimisations might be necessary to get that to work really smoothly.
[01:15:58] Eric Nygren: Eric Niagara just responds to the I think we have to be really careful on David's idea on the h the connect one because I think the this one of the things that came up in discussing this is what is the trust model here and what is the security model? And I think here, we're already slipping into giving more power to the proxy than a normal proxy has because you're starting to give it kind of the powers of a DNS resolver. If we start moving up the stack, you start moving it kind of moving some of the security even more of the security functions out of the the client into the proxy, which is a little quite questionable. I think the but I think the one on that, Martin was saying on thinking about this from the happy eyeballs perspective for proxies is a good idea because if this draft is really just a optimization, it may make sense first to kind of look at where are the slow paths and do some experiments on on kind of practical real world on, like, which optimizations actually matter before to add in a bunch of complexity for something for an optimization that might may or may not matter.
[01:17:01] Tommy Pauly: Tony, Poly, Apple. I I think it's good to have the discussion in Happy, and and there are aspects of happy apples there. For where it lives after that, if we when we have technical building blocks, partly in respect for wanting to close MASQUE, but I also think that it probably makes more sense to say it is generic HTTP best because we already have precedent for things that are connect TCP, that are proxy status headers, etcetera, living in HTTP. Technically, even though, like, we all think of MASQUE as, like, it's all of the new proxy stuff, including TCP connect that's not really in the charter. The charter is just about the other things for UDP and IP and Ethernet. And this problem is you know, people in this room care about it, but it is really generic to things that have nothing to do with UDP at all. You could do this purely with normal connect, and it applies just as much.
[01:18:05] Eric Kinnear: Eric, you hear? With no hats, yeah, I would say I don't think this is actually connect HTTP, and I'm not planning on giving up the possession of the keys to the proxy and have it do a TLS handshake, that seems not great. So really what you're doing is is connecting the transport underneath, which maybe is an HTTP biz thing, maybe isn't. The happy eyeballs aspect with the happy chair hat on is a great thing to discuss in that working group, sure. Otherwise, I think we need to figure out where the rest of that direction finds a home.
[01:18:46] Chairperson: Okay. I think from our perspective, although, you know, we're in this rechartering process and thinking about it, we're not gonna slam the door on something that the working group is interested in, you know, facilitating and developing. So I think the door is open there. Similarly, sounds like HTTP might be the appropriate place to go, and we can talk more about that offline or on the mailing list. Unless there's any other business, I think that draws MASQUE at IETF 126 to a close. Thank you all. What'd you think? Surprisingly