Internet Engineering Task Force Interim Meetings, 14 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-MASQUE-20220214-1700

Description

MASQUE meeting session at IETF
2022/02/14 1700

https://datatracker.ietf.org/meeting//proceedings/

A

Heads up we're going to give it uh one more minute for folks to trickle in.

B

All right, let's get started.

B

So good morning, everybody welcome to the february interim for the mask working group.

B

A little bit of housekeeping before we get into our presentation, this session is being recorded.

B

uh We have a set of notes which are linked in this slide, that you cannot click on, but we'll drop the link in the chat as well. Please go and add your name and affiliation into those notes. Just in case medico is not automatically blue sheeting for virtual interims.

B

As you're, hopefully aware you can enter the queue by raising your hand, and you can leave the cube by clicking on that same button, which will change once you've clicked on it and when it's time to start speaking, you can click the little icon. That indicates that you're not currently sending audio and click it again to stop sending audio.

B

This is the note: well, it's the terms under which we participate in the itf. Please take some time to read it.

B

Also, please note that there is a code of conduct and that everyone needs to be treated with respect.

B

Here we've got a couple of links. This is our agenda. The meeting that you are already in and that's the notes, link.

B

And for our agenda we're going to try to keep it fairly focused today on the output from the http 3 datagram design team. That has been meeting for the last several weeks and months since our previous ietf meeting and we're going to go through. Those results have some time for discussion, and then we will take the final consensus on that to the list.

B

So we're going to use the full block of time today, for which we only have an hour and we're going to see if we can get through all of that and get that wrapped up so that we can go into 113 in really good shape.

B

And with that david, you have some slides.

C

All right looks like there's audio and slides, and people confirm that you can see them. Thank you very much, sean all right good morning. Everyone, my name, is david kanazi and we're going to go over the output of the design team today. um So, um but before we begin uh just wanted to wish everyone a happy valentine's day from us over here at mask enthusiast, incorporated hope.

C

Everyone will be having fun at some point today um now for folks who haven't been paying attention, a quick recap, um so our main focus for the mass working group is building connect, udp, no lucas. This meeting is very fun. You have to know which is like connect, but for udp, and since there was interest from other works such as web transport and using datagram with http, we split that draft into two one of them became was initially called h3. Datagrams is now called http, datagrams and the other being connect2udp, which builds on the first.

C

We had an interim on this topic in april of last year um to focus on the design of the http datagrams and went through multiple iterations of the design like the through feedback from the community. We we changed and then we had some discussion. We made the changes we implemented them in software. We redesigned everything again and again, and so you know at 112 we realized we were kind of going in circles, so maybe we should get everyone who, like really cares about those design elements into a room and form a design team.

C

So that's what we did, uh and so they everyone in the working group could volunteer. There was an email sent to the list and up here on, the screen is the list of all the participants. So I want to in particular thank eric martin mike tommy allen, lucas alex marcus ben victor for all their work and reviewing the documents and offering suggestions and, most importantly, for all reaching consensus on a proposal. So I'm really glad we landed on something that everyone could live with. That was really important.

C

um What were the goals of this design team that we? What was our mandate when we begin began was to reach consensus. You know, if needed, rough consensus uh amongst the members of the design team on an overall design for http datagrams, so in what you know, what they mean, what they look like somewhere encoding and things like that and the are the output of the design team would be to write a recommendation as forms of github pull requests uh to then bring them back to the working group and discuss them before 113..

C

So the idea here is today I'm going to go through these uh or like the contents, so we can have discussions feel free to jump in at any point to ask any questions uh and then the goal we'll hand it back over to the chairs afterwards to see if this design team consensus can turn into working group consensus, if everyone is okay with it, so the output came as two pull requests: one on http datagrams, one on connect2udp, I'm pasting the two links into the chat, so folks can open them if they want.

C

uh We thanks to martin thompson's amazing uh id draft tools. We have, uh if you open the pull request in the description. There should be a link to a rendered view of the pr of like the the final text, assuming the pr gets, landed and also a rendered diff between the current draft and the pr.

C

But you don't need to do that. I'm going to walk you through all the changes that we made and how what the protocol looks like now. Some of these bits are changes. Some of them are just elements that we already had in the draft before the design team, but that we agreed on keeping.

C

So the first one is the capsule protocol, uh so the http datagrams document defines the capsule protocol, which is a sequence of tlvs type length values on the data stream. So the data stream is like, if you have an http request stream, once you're done with your either your request, headers or your 200 response headers.

C

It's that bidirectional stream of bytes and the wire encoding using the rfc 9000 formatting is on the right, which is as a sequence of tlvs, where the t and the l are quick style, variable length, integers, 62 bits, um and there is an in a registry for these capsule types uh and then any new method or upgrade token http, uh so upgrade token- is what we use in h1 for upgrade and in h2 and h3 for what's called extended connect.

C

So if you want to do websockets or other things over uh should be two or three you use http upgrade tokens, and so those new ones can in in their specifications say that they use the capsule protocol. So, as an example connect udp says I choose to use the capsule protocol, and so so does web transport.

C

We also introduce a new capsule protocol, http header, that allows endpoints to inform intermediaries that the capsule protocol is in use. So the idea there is, if someone wants to write an intermediary that can forward the capsule protocol and like handle the specific datagram frame that I'll explain later, they can recognize it by this header, and one important detail is that allows intermediaries to translate between different versions of http. So, for example, common deployment scenario.

C

Is you have http 3 from the client like, say the browser to the front end and then using another version of http from the front end to the back end that still works here with connect udp or web transport with http datagrams.

C

So http datagrams are strongly associated with a currently open, http request stream. So that means that when you send an http datagram, it has to be tied to a let's say, a connect udp request. They can't be just sent on a quick connection without any semantics um and the stream has to be open. So once you close it you're not supposed to send datagrams anymore, uh and so there are two ways of sending them. One is in the http, oh sorry, in the quick datagram frame, which is the draft itf, quick, datagram extension to quick.

C

That is, that was just last week, approved by the asg and is um going through a editing by the rfc editor, um and that allows you to send unreliable frames inside quick. So, and this document explains how, when the alpn is h3, how you can send http datagrams using that frame, and so I have the wire format here on the top right of the slide, and so I've copied the bits from the quick specification as well.

C

So it's the quick datagram frame which has a type of 0x30 or 31, which tells you if the length is there. If the length is not there, it goes to the end of the packet, but that's like that's inside quick, like we're. Not talking about that here, that's already almost published.

C

What we add in this specification is in the start of what the quick frames calls the payload we add a quarter stream id which allows you to associate any datagram with a http request stream, and the reason for that is http defines request streams as client-initiated bi-directional streams, which are all divisible by four.

C

So in order to save some bits on the encoding we divide by four uh and then inside that you have the h or after that, rather you have the http datagram payload, which then methods define the semantics of that and the second way we have to send http datagrams is a new capsule called datagram, so the type is datagram the length and similarly right after it has the http datagram payload. This one doesn't have the quarter stream id because capsules are sent inside the request stream.

C

So you already know on which stream you are when you're parsing it. So you don't need to repeat that field um and the nice property that that gives you is that you can now send hp, datagrams over all versions of instruments. Sorry all versions of http uh over quick and sorry http 3. You can use the datagram quick frame, but on other ones you can send them over this.

C

It means that you can do this property of having all this work when, let's say you're front end to back and link, doesn't support h3 or, if you're, on a network that blocks quick or udp.

C

uh So the one of the bits that was a major change was the extensibility demultiplexing. So before we had a concept of a context id inside the http datagrams frame, we took it from there and we moved it to connect udp. So what that means is no now in http datagrams there is no longer a demultiplexing identifier.

C

That feature has been removed, uh and so web transport, for example, doesn't have any demultiplexing because it doesn't need it. uh We we introduced it, however, in connectudp, so how does it look there?

C

um The oh! So I see a question in the chat from martin duke uh yes, it is sorry one second. It is currently inconceivable to send an h3 datagram over a push stream. um Part of the reason for that logic is that uh quick push streams are also associated with requests. You can still send your http datagram with that request. um So that's one of the parts of the design uh back to where I was uh connect. Udp um decides to use the capsule protocol and it's an issue.

C

So it's even though the we still informally call it connect2dp all caps. It's not an http new http method. It's an http upgrade token. So what that means in http, 2 or 3? It's you. You send the method as connect and you send the colon protocol a new pseudo header using connect2dp.

C

So this has a dependency on ryan hamilton's, uh using websocket over http 3 draft or for h2 rfc 8441, which is how you add the protocol new pseudo header, and then we introduce a context id, which was the concept I mentioned, used to be in http datagrams and is now inside connect udp, which allows the multiplexing uh so in.

C

uh If your context id is set to zero. That just means this is a udp payload and then so the proxy processing is defined. In the document you get a datagram with context id 0. You write it to the destination that was specified during the request and hostname and port, and you just write it there on that socket and if you receive something on that same socket, you put it in a datagram with context id 0.

C

and that the context id is so. We can kind of see the y encoding here on the right of the slide. If we're inside the datagram quick frame after the quarter stream id, we now have a context id followed by the payload and if we're in the capsule uh after the length, we have a context id followed by the payload um and any other value is there for extensibility.

C

So the the values are dynamically allocated and what that means is every uh request keeps a pool of these context, id values so in practice the simplest way to implement this. Is you keep a uint64 in memory of? What's the hot? What's the next one I can give out that hasn't been used and any time an extension wants a new demultiplexing identifier.

C

It just gets a new one and then it can send it. So the even numbers are client allocated and the odd numbers are server allocated this kind of mimics, the design of quick streams. The idea there is that way. You don't need a synchronization point between them. You can just start using the next one, because you know you own it as an endpoint um and so but then, once you have that context id you have to communicate to the other side. What does it mean like?

C

Oh now, I'm going to send you datagrams with context id 2.. You have. The other side has to know how to parse them and what semantics they have. So in the draft we define the concept of registration, which is this idea of telling the peer. What does this number mean and there we're foreseeing at least two ways of doing that? One is an http header, so one second sorry.

C

Sorry uh so in an http header you can say, oh by the way uh context, id 2 means like in the definition of an extension. You say context. Id2 means um the uh sorry in the in a new extension that wants to do uh timestamps with connect udp, you could say I have a new header that is udp with timestamps, and that takes an integer with it and when you send it, you send it with two, and that tells the peer by the way, when I send you a datagram with two.

C

That means that it's this extension um and if the gear doesn't know the extension it'll just receive datagrams for a number that it doesn't know and it'll then drop those on the floor. So there's no harm then, uh and another way like there are some extensions.

C

Let's say if you want to do compression of like quick connection ids, where, like you want to do something stateful halfway through the connection, you can use capsules for registration, so you can say like halfway through your your question being live, you can send a capsule that says by the way context.

C

Id 42 means we're compressing these bits or have this extra state, so you can do that either at the start of the request, with headers or during with capsules, and we also don't close the door if their people come up with new ways later, but we don't specify a generic way for registering. We just say that you have this these options and that isn't somewhat of an open question that we decided wasn't in scope for the design team of.

C

We could decide as a working group that that's good enough, uh that we can leave the extensions figure this out or we could define a standardized way for registration inside this document that extensions have to adhere to so that one. I don't think we should discuss today because that's outside the scope of the design team, that's still an open question that we'll discuss as a working group, potentially at 1, 13.

C

um and another bit that we similarly decided like that to leave for the working group is how you compose extensions. um One way to say is we don't particularly define that now, but some folks were saying: maybe we define a way that if you have two extensions to make it easy to combine them? Oh that's one adds the timestamp at the beginning and then the next one adds ecm markers.

C

That's again an open question. We haven't discussed that as a design team or want to discuss that with the working group and that's kind of all of it from uh from the slides. So my hope there is that this somewhat makes sense. It's a design that that's not too far from what we had before we've kind of moved things to simplify http datagrams as much as possible, while keeping connect2dp extensible for all the extensions that working group members want to build, but I think we have everything we need to build these.

C

um So I this is the end of my slides. uh Please send any please walk up to the mic and come ask any questions.

A

uh Someone just tried to join the qubit, then they popped off. I don't know if that was an accident or not.

C

Yes, use the little hand button to join the queue, and then I I can run it if you want so uh patrick, go ahead.

D

Yeah hi there uh patrick tarpy, from ofcom, um I'm kind of I'm. I suppose I'm trying to assimilate all this. It's quite a lot to take in and I'm a bit more of a kind of like I need to see things running. Are there any kind of like test stacks written in go or something like that? I can spin up and actually watch it perform.

C

um So, let's see uh I so my team has a stack in c plus plus. I know the cloudflare folks have one in rust that supports the well, not the latest version of the draft, so we're gonna we're waiting to implement that once it lands. uh I don't know if quick go supports datagrams.

C

Currently um there are, I know the erickson folks have added support for this into aio quick, but I don't know if that made its way back into open source. So to answer your question: yes, there are quite a few test uh stacks, I'm not 100 sure about go.

D

Oh, thank you. I mean if, if anyone can share something on the mailing list, I'd be really appreciative because, as I say, I'm a bit more, I need to see stuff running before I really understand it. Thanks sounds great.

C

So um I see miriam asking a question on the oh, well perfect mira's in the queue go ahead: maria.

E

Yeah um yeah, I thought I'd just come to the to the queue and ask so I don't remember all details of the previous um version, but it seems like the main difference is that you moved some of the text from the http datagram document into the udp connect document, or was it like? What are the major changes? Maybe you can summarize that.

C

um So yeah, I didn't go into too much detail of the previous proposal because I didn't want to to be confusing, but in a nutshell, the the previous system was quite a bit more complicated. It had a lot more concepts, so it had like the concept of a datagram format, type with a separate iena registry.

C

uh It had uh all this extensibility mechanism to add context that were also optional with a header that then you would negotiate with a special mode to all.

C

You allow you to send things during your first flight, all in http datagrams, so that was the feedback I got was that that was pretty complex, uh and so all of that is now gone and it's replaced by kind of a more static choice where each method decides if it uses this or not, and that ends up simplifying both specifications and, at the end of the day, the implementations as well, so that that was like the the main concerns from my recollection on the previous designs were complexity, and so we added a lot of these moving parts uh and found something that gives you uh almost as much flexibility with way less complexity.

C

In the current design,.

E

So the I think, the reason why you put this first into the http data driven draft was because the expectation for that other protocols would use the same kind of extensibility mechanism, the same kind of structure, um and now you kind of agreed that everything was moved into content connect, udp and basically, this kind of context protocol would only be used by connect udp or what's the exception.

C

So the connect udp is going to use it, uh and our expectation is that connect ip will do the same thing, because both of those have very similar uh use cases with transport. However, uh will not um that's the current plan. Well, obviously, the the web transfer working group will have a chance to react to these changes in the http datagram draft there, but I expect that from all of the key participants of web transport that were part of the design team, that's what I think they will go with.

E

Okay, so the input from web transport was they're not interested in using this anyway, um so we don't need to provide a new generic mechanism for it.

C

That that's right, we don't need to provide a generic mechanism inside http datagrams, and so since we want it for connect2dp and connect ip. These like documents will define their mechanism. It ends up being a very small amount of text, so we'll have some duplication between connect2dp and connect ip, um the uh martin thompson phrased it pretty well as uh preferring um uh composition over inheritance kind of, um and so that that simplifies things, especially for for web transport.

E

I mean, I don't think, there's anybody else in the queue so ask another question um sure.

E

So, of course we cannot kind of dictate the web transport group what they should be doing but like how is this group feeling about actually having at the end two approaches which are very similar but still not the same? At the end,.

C

What do you mean? Yes,.

E

It's not a question very similar.

C

But can you clarify your question? What do you mean by two approaches that are similar.

E

So I I assume that web transport also needs these kind of extension mechanisms to some extent right.

C

No, it does not at all.

E

C

So web transport doesn't need this at all. It just has an api for datagrams that fits directly into datagrams, so webtransport doesn't plan on having any kind of extensibility there because it doesn't need it.

E

I see okay, thank you.

C

Of course, thank you for your questions.

C

Does anyone else have any questions.

C

All right that sounds good, I'm gonna hand it back to the chairs.

B

Thank you david all right. If we have no more clarifying questions or other comments, we're going to give the show of hands tool a workout this morning um we're going to go with one quick question to kind of confirm the the sentiments in the room, and then we will take the output from this design team back to the list to discuss consensus with the working group as a whole.

B

So we're going to start the show of hands session here. It's the uh it should pop up for you actually and you can either raise your hand or not raise your hand, so raising your hand says. I believe that the output from the design team is the direction that the working group should take for http 3 datagrams, and if you do not raise your hand, you are saying that I believe the output from the design team is not the direction that we should take.

B

Give everybody a minute to find the button and click on it.

B

All right, we appear to have stabilized we're going to end that and take it down in the minutes.

B

And with that, if we do not have any further clarifying questions or comments, we're going.

C

To eric, can you uh confirm for everyone what the result was.

B

Yes, we have 21 raised hands, saying that we believe the direction is the direction that we should take and we have zero, not raised hands, so this is normally where I would ask if anybody who did not raise their hand would like to come to the mic, but no one did so. That is glorious.

B

C

B

All right, thank you to everybody in the design team and everybody for showing up this morning we're going to give everybody some time back rather than try to plow through a couple of issues. We will save those for uh 113 and keep this nice and tight and focused on the design. Teamwork.

A

If I may, before we adjourn um david, you thank a lot of people for the design team. um We wanted to thank you uh for leading the effort and getting everyone to consensus, as is clear in the chat, um this was a pretty big effort over many months, so you know thank you for thank you for all the time you put into this.

C

Thank you chris. I really appreciate that this uh this ended up being fun and uh I just told people that the uh meetings would continue until the consensus emerged and eventually they got tired of seeing me every other week and we landed with something that I honestly liked. So that was great thanks, appreciate it yeah excellent.

A

All right folks there's nothing else. I think we can call it get 30 minutes back.

A

Have a good rest of the day.

A