Internet Engineering Task Force 106, 20 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF106-QUIC-20191120-1000

Description

QUIC meeting session at IETF106
2019/11/20 1000

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

A

Okay, let's get started.

A

This is quick, and this is our sessions second session for the week. If someone come in, the back door could possibly close it. That it'd be really appreciated. Thank you, or we can get the next person to close it. Okay,.

B

A

Is the note well good morning, by the way, this is the note? Well, hopefully, you're all familiar with it. If you're, not, you can find it using your favorite search engine by searching for ietf note. Well, it's the terms under which we participate regarding things like intellectual property, but also regarding things like our behavior in the room and on the mailing lists and in the hallways and other ietf uShip places. So please take a look. Please learn more about it.

A

If you have any questions, we'd love to chat with you, either myself Lara's when he's here, he sends his regards or other ITF leadership.

A

Blue sheets are circulating one on each side. Please sign those as they combine. Can we have some volunteers or a volunteer for scribing two hours for which you will be eternally thanked.

A

It's amazing how quiet the room can become. I won't ask Ted Hardy because he's done so much service in the past.

A

Are you volunteering Ted your service to the community is is above and beyond. Thank you, Thank You Ted can are you gonna use the ether pad Ted or the Google Doc ether pad? If folks could help Ted out on the ether pad, if you're not actually helping, Ted out, maybe refrain from getting on to it, because it doesn't like lots of people at the same time that would be appreciated.

A

Can someone volunteer to jabber scribe is significantly easier to ask.

A

Thank You dkg once again we're not entirely sure the bridge from jabber to slack is working, so please bias towards jabber agenda bashing. Our agenda today, we're gonna, continue discussion of the issues. I think we're in a place where we can discuss just the HTTP and recovery issues. Today we have Becker interrupts.

C

Yeah we have one remaining transport issue: slash pull request that we didn't process. Yesterday, I heard one remaining transport issue and then I heard a lot of ekor. huh Can you that we didn't.

A

Part that we didn't.

C

A

C

Which one pull request? Three one: two, oh okay, I start with I wanted Rudy tag.

D

: J's I would it be possible to add in agenda bash the swapping of datagrams and version negotiation they do to some people tried to sneak to a different meeting.

A

Well, first of all, we're not sure when that's going to start, it depends on when how much the issue discussion.

D

Totally understand.

A

And we've already agenda bash yesterday that getting version negotiation before the other two was important, so Mike.

D

And still remains, is there reason not time fie? It was just a question. Yes,.

C

You know any objection.

D

To that I think.

C

That'd be fine, I think well time. Okay,.

A

Any other agenda bash. Sorry, I didn't even finish the agenda, so we had finished talking about issues including that talk about extension documents. Apparently talk about datagrams. First then verse negotiation, then load balancers. We end up with planning any other agenda: bashing, Provine, sorry yeah, the acoustics in this room are horrific, so everyone needs to speak very close to the mic and very distinctly praveen.

E

Agenda I think, like the planning discussion should be moved up front. One of the discussion with implementers has been a request for like a quiet period where we could get some deployment experience so I think planning moving it. Upfront would be very useful. Any.

A

Objection to that, okay, Jonah.

F

If you could I take a couple of minutes to talk about the quick intrapreneur.

A

As time permits, sorry.

G

Can we put that at the end, desires time permits? That's fine with me. Okay,.

A

Okay, any other agenda bashing; okay, that's probably the most lively agenda. Bash we've had ever.

A

So, let's execute on that planning.

A

We're going to talk about extensions and other documents later on today, and so Lara's and I, and the area directors have been having a number of chats about how we're gonna go into the next phase of this work.

A

As as we've discussed, we currently have a co-op for consensus on getting the recovery and HTTP documents into the late stage process. We are, as you can see, winnowing down the issues lists on all of the drafts, so there are very few left, and the anticipation, as we've discussed and tried to Telegraph number of times, is that the drafts are going to settle down from a technical standpoint of the bits on the wire, but we will enter a period where we think we understand. Yes, mr.

H

Chair sue, B does I think it is Winston or Thursday I'm. Sorry, I can't hear you today's Winston or Thursday your site. Thank you.

A

For that, if only every issue were so easy to solve.

A

This is what I get for chairing more than one working group and reusing, slides.

A

Right so good morning, I will point out. I've only had one coffee this morning and for someone where I'm from that's not any at all, so we're hoping that the drafts will settle down from a technical standpoint. We also anticipate the editors taking that time to do some fairly substantial reworking of the documents from an editorial standpoint to make sure they're communicating clearly not changing the technical content, but changing how it's presented so that it is readable and and usable by people who haven't participated in this process.

A

At the same time, we feel that implementers are going to need some time to digest everything. That's happened to work on their implementations, to do interrupt work and also to get some deployment experience. That's something that people want to see very much before we ship the RFC's to make sure that this thing actually works in the wild. And so the tentative plan going forward is.

A

Is that once we get the documents into a good shape and we close these issues, we'll go to a working group last call, hopefully before the end of the year and and as a way to notify the greater community that we think were technically done. However, we're not going to request them to become our FCS for some time after that, and and very roughly speaking, that's something like the middle of next year, because we want to get that experience. Give the editors a chance to work in the documents a bit to get deployment experience.

A

So it may not be our last working group last call on these and I know that that that dissonance is is harsh for some. But but it is a what we think will be. Our working group last call because of that we're gonna have some capacity in the working group for discussing other things, and so we're talking about how we can start the discussion of extensions to quit.

A

V1 and whether we start the discussion of any potential quick, v2 and also discussion of new application bindings to quick and in discussion amongst the chairs and the area directors. We think that the best approach is for this working group to start discussing extensions in a limited way.

A

We don't want to have a flood of them come at us all at once, but to start a few discussions and and and and that's why we're starting to have things like discussion of load, balancers and datagrams verse negotiation is, is, is the third one I want to talk about there and at the same time, you know there are other folks who want to do new applications on top of quick and and our bias is to not do those in this working group, but instead to talk about new venues for those or reusing existing venues.

A

So, for example, there's AB off I think later today about web transport and that's a potentially working group forming buff I, believe no, not quite yet, but one may appear afterwards at some point and but but we wouldn't want to do that. Work in this working group, for is the important thing to convey so I think that's where we're at. We have an interim scheduled in Zurich.

A

The anticipation is: is that there's an intervention or experience, hopefully on those working group last call documents we'll have some discussion of any remaining issues that we need to, but we'll also have some time to talk about these extensions. Any any discussion.

I

Of this Christian yeah I mean I like the idea of stabilizing the protocol before publishing the RFC and having some time to test and verify. However, if you delay pushing the document for publication at the same time, you're also pushing the IDF review pushing the idea of review. Yes, I mean that so, basically, if you're not doing the ietf last call, you are not getting the feedback from people who are actually in the working group, and so that creates an uncertainty about the duration of its own ITF.

I

Last call later on and I'm a bit concerned about that and I'd like to find a way to mitigate that. Okay,.

A

I think that's a reasonable concern to have I'd be interested, hear what other people think about it.

E

Pravin I do like the idea of going to a sort of semi-formal working group last call so I think that's a good idea. What I would like is something more concrete in terms of a draft number that we are targeting to close of the remaining issues such that implementations can deploy and stabilize on it.

E

I think working group coming out and saying something formal would be useful instead of having a vague date, waste deadline like target a particular draft where we say: hey, we're, gonna, freeze this for a little while, so that people can deploy I, think that would be very, very useful and regarding IETF process, I think that can go on in parallel, like if you find any major issues from deployment we can come back and like fix. Those, but I think like having a very stable draft formally declared, would be very, very useful.

J

The saman Thompson I think, based on the issue list that we have in front of us and the discussion that we had here earlier this week. The next version of the draft might be that one that prevents looking for I'm, not 100%, confident about that, but I think we should certainly try to make that the case. We have a long time between now and the interim meeting and I think the editors are pretty firmly committed to nailing all of those issues.

J

Most of them have pull requests against them already, so I think we're we're in pretty good shape for that one. As for Christians concern, I think we have a fairly simple answer to that one.

J

The ITF review is largely based on Directorate reviewing in the modern day and so simply going to each of the directorates now and asking for review, which is a practice that most of the directorates already support for various things is sufficient and will get us some wider review and I would I would say that the the steps that I would like to see happen. We finish the next draft.

J

We do a working group last call on that, and then after that finishes the chairs talk to the various directorates and ask for those reviews to happen, and that will happen during our idle period and we can deal with the issues as they come in, but I suspect.

J

What's going to happen, there is that we will have 25 and then a 26 will contain a whole bunch of editorial changes based on review and working good last call and feedback and 27 will be Directorate feedback and then we'll sit on that, but 25 and 27 should be functionally identical. If we're. If we're changing something there, then that's a pretty high-energy event. That's maybe optimistic, but that's the that's the sort of thing that I would like to see happen.

B

I

But I mean at the same time you cannot expect to have review for a bunch of directorates and change nothing, so it may will be that there is some substantial change when you don't know that sorry Brian.

A

Before you speak, can you raise the microphone I think it would benefit everyone? Thank you.

K

Hi Brian Trammell yeah I, basically came up here to see what Martin said. I'll expand on that very slightly there's even a button in the data tracker no I think to request director review review from a director up on a certain thing. There.

C

K

So I mean you just click the button if there's further, like I, think that gets us exactly what we want if there is further lake-like discomfort that maybe the entire community like if there are there are like whole areas that aren't in this room so like maybe there are people only won't write. A review. I know that we do not generally use IETF at IETF dot org for Nicolle discussion, but there is a mailing list that we can say hi by the way you know.

K

Maybe you've heard we're like replacing TCP with TCP um sorry yeah yeah. It's like last call coming up great like so last call preview. Can we actually send that to last call at IETF that org I mean we can also send it to ya? I mean yes, it's like almost last call. That's like you know, preview of last call please start reading the document. Now it's big and important yeah, so I mean like we have. We have like I think we have a lot of options here to pipeline this and I.

K

Think what like what I'm hearing is that everyone here is interested in pipelining. It and I think that's a good idea.

L

Hi, this is Sean Turner, just driving the point home we've kind of had some running code. We did with TLS 1.3 I, don't know that we did it perfectly, but you can tell the ADEs the ADEs talk. You can request the early reviews. You can send the messages to everybody. You can Twitter it. You can be like look. This is coming. If you want your chance, here's the github repo knock yourself out I mean there are ways that we can do this I do not think we should try to get it top.

L

Try to let the arts you go early, because we're gonna end up changing it anyway, so we know that right, there's like an N DSS conference in January, so like stuff can pop up. So my theory is just: do your plan.

C

Where's, what Sean said do you know do other things, and people will still show up at the last minute, so you don't like it. The I think that running code as well I think this generally seems like a solid plan, um the I'm, probably the person who thinks that calling it last call when we know it's like not. The last call is pretty silly, um but you know what it's.

M

C

Shed thanks David um and the reasons that a bike shed is that often there's a presumption we do or last call that if issues not raised in the last call, then they're out of order when they're raised later and um and so on, the I think praveen's entirely right that it's good to have a last call.

C

Let's try to flush out as many of these as we can and like they'll spend sometime sometime, you know doing um you know, doing testing and doing some errant ation, and that will know that turn up some things about the change and those issues will obviously be in order. But what also needs to be an order is upon reflection. Having looked at this longer, not from data, but from looking this longer. There are things which are not good. We can start changing them.

C

My point is those are still in order at that point in the process where they would not be in order. Ordinarily, if, like you were sitting there working group for two years with the last call and like you aged it, like it, ITF I was called people, think you were a jerk and so I'm just that dust. But that's the reason. That's the reason. You're hearing resistance from the last call.

N

David's Kazi google just want to quickly say this is a good plan. I like it, especially from our implementation side of things it. The past couple years have really felt like running after a moving target because we're like we have quick. Oh they changed the header format. All right run change that. Oh, they change this and it's we're almost there now, and so this quiet period is gonna. Allow us to actually catch the target and actually put it in production and get numbers that we'll share with the group.

N

So I think this is a great button. That'll.

A

F

Jenna and got a clarification question I'll be talking about last call for all the documents. I would talk about some of them, but once.

A

Again, you're reading my mind, I was going to bring up when you when the cue drained I in place it in these discussions. I think that everyone's assuming I I, think but I want to confirm is that we're gonna do all four documents at the same time, I really all five documents. At the same time, I.

F

M

F

That I think that's all right. Okay, I just want to I just want to point out that we've not yet moved it just in terms of process. We've not even move those ones, HTP and recovery documents to the late-stage process, but sure and.

A

F

That's something we're.

A

Gonna talk about briefly today, but there's already a call for consensus up for that and, of course, that that's an internal process, it's an external facing process, so the other documents we haven't talked about very much at all or the ops and management documents we do need to start talking about those more yeah.

J

So mutton told some was going to talk about those two specifically. This quiet period will allow them to catch up as well, because there's like, like those people implementing chasing the moving target, has been difficult for those documents and I. Think it's probably a good idea to to allow that to sell. It might be, then, that we can publish all seven documents at the same time, which would be a really nice thing to be able to do.

A

So we all understand the plan, the plan will meet battle and we'll have some fun. Yes, planning is important.

A

One of the important takeaways that people should have here is is that if you do think you have an extension, that's generic not specific to an application you'd like to propose for quick, write, a draft bring to our attention we'll reserve time for it. If it sees some discussion on the list we'll think about whether we want to adopt it and then we're going to start that mechanism going, but this working group will, we think be the locus of that and one thing: I should mention: I'll put a meal email on the list shortly.

A

If we do do that and I think this is from talking the area directors the direction we want to go in we're going to need to make a charter change. Our charter currently says: thou shalt not work on a datagram extension woops. So we need a slight chart. Okay, that's not them! That's me: we'll need a slight Charter change to enable us to work on on those extensions, we'll put a proposal out for comment. The area directors will change the Charter, do that do whatever they need to do and we'll move forward.

A

There are other parts of the Charter we can change, but we're not gonna think we're gonna, try and do that quite yet. So let's talk about issues.

A

Occur, you said there was one remaining issue from Transport. What if she never was that.

N

I can talk to that one okay. So as the author of the PR for it, so the sorry. What's the issue number sorry Iker says thirty, one. Twenty.

C

N

Alright, so this is the PR and I guess. The issue is thirty. Fourteen.

N

Okay, so let me summarize this so first thanks Kazuo for finding this issue. In short, most packets in quick are encrypted and in particular, their integrity protected, and what this kind of a slight side effect so the crypto, but what it also means is that if you get a random bit flip on the network, it's the same as an attack, but we detect it and we drop the packet.

N

One exception, though, is retry packets, those on Mike initial, don't have any kind of protection and if the retry token gets a bit flip on it, we don't notice, especially if the UDP checksum is disabled. That's particularly bad! If that, because if the retry token is invalid, the server will reply with a second retry and according to the spec, the client must not like do that. Dance the second time. So then the connection is dead in the water.

N

So the quick and simple fix that we agreed to in cupertino was to add an integrity tag at the end. So if there's any kind of error on that we detected and we drop the packet, then if you switch over to my PR, the proposal is to do exactly that.

N

It also has a slight thing where it uses a pseudo header, similar to how TCP computes its checksum, so that some fields don't need to be sent over the wire anymore they're, just added as part of the checksum and in particular the original destination connection ID, and that's really all there is to it that a1 one more last point was: we were wondering what hash, algorithm or slash checksum to use here and in order to not add any dependency on the protocol, we decided to use GMAC cuz.

N

Everyone already has an Aes GCM implementation for initial packets, so yep right there perfect, we just reuse a a das, GCM 128 the key was initially zero, but I could rightfully pointed out that it might be nicer to have one that changes and then a Martin Thompson had the good idea to just reuse. The initial salt from okay well then get in line to say that, and so we use that key.

N

So that way, it's the same for all the time. The nonce is just zero. There's no plain Tex, and this gives us and the associate data is this entire pseudo header, and that gives us a checksum and that really authoress to it.

C

Right so um I guess two points plus listed there for the first point. First, on quick, graphically which I mean I know, this is a fine point. We shouldn't use the initial assault as the key we should take. The right we should Katie has something off. The initial assault. I understand like this is not like, like I'm going hands vigorously about like how is it really secure anyway, but um nevertheless a good practice on the more substantive, a acetal nodding? So that's fine, that's it cause it.

C

It's a constant any case on the on the issue that I think that Dave and I were forth on is whether any of this material should be encrypted, in particular the retried token be encrypted, and so, as I I think I think my claim is that encrypting it has the nice property that, like two centuries there is any structure each I took in France, ossification um Martin's, counter-argument I believe is that recall was that on wait.

C

What so I think they're two arguments while you might want there's one or why you might not want to do it, which is it costs the cost in AES or operation or two for the GCM computation further for the AAS computation on the the martin counters. I believe, with this will be a fixed fixed mask, so you can just X or the fixed mask which- and so this is there's no performance. There's no performance consequence really.

C

The I have two ways: there are two the most there's some benefit, um um because it means it means it's quite a bit more work for, like for someone, doesn't in the draft to see the structure of data on the on, because all you're getting because you're getting X or something unknown on now, I, where I was going to say, is um there's actually two ways you go here. One way it all three ways: one way is the current thing we recycle it at all.

C

The second way is the fixed AES key with a fixed mask which turns into fixed masks, so you can on which has additional advantage by the way that it means you don't like redo. It means you can use exactly the same computations you ordinarily would do for backup reduction on the on one more thing, that's worth adding is that if you were willing to accept the AES operation, um then you.

M

Could use either disconnection.

C

Ids the nonce I mean you would not have a face mask anymore.

C

Sorry, you could use either of these connection IDs as a nonce and then you would not have on you'll not have the fixed on computation, but you also have a better off occasion.

K

N

So it's can Aussie Google a lot of these I, get that you have really good instincts about cryptography and that QE use is bad and a big red flag. That should just make your knee twitch, but when the key is public in the spec implications are a lot less interesting and therefore like this really becomes a beauty contest I. In my personal opinion, the thing you're trying to encrypt is the retry token, which the server encrypts with an actual key. That is not public.

N

So maybe we just need to say that the shark of structure should not be visible. We already say that the retry token must be distinguishable from a new token. For example, the there are. We could have built this similar to initial meaning that you do in HK DF based on the connection IDs and that's is better for ossification Nick. Banks was scared of that because he thinks that we'll have really bad performance Beck's on his box that sends the retry as Google I. Don't think we care much, but that's a reasonable thing.

N

At the end of the day, ossification of Paulo bites that are already encrypted. Is not something I worry about, so from my perspective, this is a bike shed. We really need the token sorry. We really need the integrators check at the end, but what we use for the key- and if we put the token, is a complete bike shed I'm totally in favor of flipping a coin and being done with this and.

E

I'm gonna cut the queue Praveen I just had a clarification question, so UDP checksum is only man optional for ipv4, because it's protected by the activity for checksum on ipv6, it's mandatory. So my question was: are we trying to get protection for the packet beyond what is provided by the IP or UDP checksum here I'm, just trying to understand why we need to do this.

N

There it's crazy you as a client application. You do not know what IP version your packet Walker over. Even if the socket you're using is ipv4 ipv6, you could have a nat64 in the network. There are a bunch of NAT sticks force today or if they see an ipv6 packet with a checks party time with a checksum, they will rewrite it to v4 and clear the checksum. So there are cases where, like you, will not get it and you have zero control over that from the application. So I think there's really a use here on.

C

Our court on that I just wanted to clarify I.

C

Just wanted to clarify on slash respond to point David just made it Jeff one very common way. You can start tokens like this is to have a header which, to.

M

C

I was indicate sure, thank you, but unique is the key or the token version followed by a followed by separate text. So it's true. If the cipher text itself is white, is it just random but often there's a header which is not.

O

Chris was just commenting on something earlier, particularly what David was saying, with respect to the key being public and what Eckert was trying to encourage us to do earlier. Domain separation is a good thing for graphically speaking. We should derive a key from this pixel and use it.

O

Let's do that whether or not it's encrypted I don't have a strong preference on that. So maybe that's the bike shed.

J

So mum Thompson I, wanted to ask the question whether anyone thought this was critical in some way. I, don't I, don't see any indication that people think that this is. This is a hole worth dying on. It's just that we have a preference from some people not to have it encrypted and preference from others that it be encrypted.

J

um One of the the key observations here is that we don't want to run HK DF and we don't want to install the different AES key, because both of those operations are expensive enough to show up in the test and Nick had some pretty good numbers on what a cost to send retries with the full HK DF plus a yes key installation, all those sorts of things so I think we have agreement on that. But ecers point about the three points in the spectrum that we're discussing is I.

J

Think probably what we need to look at, and that is just the integrity tag. The fixed key encryption with the way that just just adding encryption in in the way that Davis described and the third option being used something from the original message.

J

For instance, the destination connection ID the first eight bytes there off, for instance, as the as a nonce, so that you get a different output depending a different mask for the token and so I think, if we I suggest that we just do a beauty contest on those and see what people think because I don't think anyone's particularly concerned about one versus the other. Here, oh yeah, that's that's a that's a good question. Does everyone think they understand the three options?

J

So it's basically no encryption encryption with a with a fixed nonce or encryption with a varying nonce based on the destination connection, ID.

J

Everyone who seems to be engaged in this discussion understands.

P

Colloquy regarding other three options that Martin Thomson mention I think between the first two options and the preference would be to go for just doing GMAC compared to a doing X or the reason is that I mean endpoints can retain a pre-generated X, okay for one inch of salt. But if we are going to have multiple salt based on the versions, then it becomes increasingly difficult to pre generate all the xor patterns for each draft. Therefore, I, regarding the first options, I think the first one mixed losses so.

A

So, martin, the the queue is closed. Okay,.

O

This is a clarification question because I realized that from empties discussion, I don't understand so you. You did comment about Nick banks having these legitimate objections to encryption, and then you presented two options that were encrypted and I'm confused.

J

So the the the thesis here is that the that the costs involved in Nick's experiments. Yes, the cost involved in those experiments was largely to due to the fact that you have to run H KDF a very a number of times in order to get the keys, and you have to install the AES case, whether when, when you get a new AES key, you have to run a number of operations in order to get it in the state that you can use it. And so those costs tend to dominate in these things.

J

But the thesis is that running the AAS operation to XOR those bits is very, very cheap and when you're talking about using AES GCM, it's basically cost nothing, because you have to touch those bits anyway to get the cheap GMAC. And so that's the thesis that were operating on here. You know there is a cost, but I would suggest that it's very hard to measure that, because of the way that this all works so.

G

Janna, do you have a question of clarification or a point of clarification question as long as it's a question? It is a question this.

F

Is just piggybacking on exactly this conversation, because I was confused as well. We had agreed to something in Cupertino. Does this effectively mean that the agreement remains the same? Okay.

A

So it sounds like this isn't quite ready to go. Do you think it'll be her useful to have a hum to distinguish between those three I thought you did or already understood that yes, I.

J

Want to understand from this this room. Yes, I pay your C, because this could drag on. If we take this to the list, because it's one of those ones where it doesn't really matter, but we could yeah it's gossip forever right.

A

But we're not going to close it today, so any.

N

Chance we could have a home on those, that's where I'm going.

A

Yes, thank you we're gonna hum. We have three options. The first is no encryption. The second is encryption with a static nonce, and the third is encryption with a nonce dependent upon the destination connection, ID correct. So.

A

Hum for all three, if you don't care or come for, none can.

K

Can ask clarification question so the first is the status quo. Is that correct and the second? Oh, as first isn't quite.

K

I

K

We do for initial encryption right.

C

Okay, this is actually making worry about this home a little bit. The first was in the pr2. All these fix the problem, because you all have found the point one, the different there's different, like colors I'm, like fixing work, as you all, have found the first of us in the PR, which is to say just integrity, check, nothing is encrypted.

C

The second is that an integrity check plus things are encrypted, but with this completely fixed key, so that basically the basically the encryption is the same, the same plain text will be encrypted the same way every time. The third option is on. The third option is an integrity check plus a form of encryption, and so that you will with system with a fixed key, but with a diversifying nonce, so that the same plane is will be encrypted differently each time there was that those are the three options.

I

It's just a process suggestion I have the impression that the second option is kind of really weird. So I would like to be first her on eliminating the second option, because he doesn't bring anything in.

A

Sorry, what was that.

I

C

Suggested it, but then my rows with a nonce thing: I decided I decided like the third option, better stuff.

A

So then the options are no encryption or encryption with a nonce based upon the destination connection. I do maybe.

J

We skip the hum on the second one. Let's talk about the first and then turn that in the last. So, let's let's, let's try that unless.

A

They won't feel struggling otherwise, no okay. Has anyone contacted the Secretariat about the lights? Okay, I like to see you, so if you believe we should have no encryption, please hum now.

A

And if you believe we should have encryption with a nonce based upon the destination connection, ID, please come now.

A

It's about even the second one was maybe slightly louder, but I think that was due to maybe one person who's really good. At this.

Q

This is DK GG. I prescribed reporting hums for no and and one hum for the encryption. Okay.

A

So this is, this is does does I guess I'd be interested to hear if anyone believes that it's great there's a critical distinction here, whether you know we need to faceplant on this for a technical reason- or this is just a beauty contest yeah.

F

So Jenna and God I'm gonna suggest maybe just asking the room of people can live with either solution and have skin Ozzie actually decide based on whatever feedback he gets on the PR and move forward, but he's written the PR.

I

Martin wants to cause we've we've.

F

Said this in several ways: now it's a beauty contest. Echo said it's different colors, but you didn't use the work by would bite but I'm, suggesting that this is a bike and that we move on.

C

That's what I do so our tactical difference is difference. Value like I mean it's just a matter of what how you judge those but basically there's a question of. Do you judge put the performance cost of the EES versus the somewhat improved cost of the obfuscation of of the aggression? That's like that's what you're but George? Okay, the cue is still cut.

A

I'm not really wanting to spend much more time on this right, so you have something short: Ian, I, I,.

K

Had a suggestion that originally the reason we went for the first option at least the interim was due to Nick's bank's feedback about the CPU cost. Can we get some feedback on whether like this is actually a blocker for deploying quick or just like kind of painful or something.

K

Yeah I mean Praveen, the best person I can think of channeling it, but but if otherwise, I don't really care but I'm. Trying to you know, but.

A

Can you answer that I think.

E

Like deployment ways yeah if crypto will add, cost right, so the question here is: if you're only looking for integrity check play, then it seems overkill to me to like go crypto. So I have a strong preference for the Nugget option. Sorry I have a strong preference for the no crypto finalcut. Oh that's very hard to tell because it will need to be deployed and measured right. So the only I rough measurements. Okay, so you do.

A

Have a strong preference, that's actually good to hear. If we just say no crypto is anybody? Gonna lie down on the right about that.

A

Sorry, no encryption yeah.

J

Yeah so Martin Thompson that that assertion is based on an assumption that this is expensive and we don't have those numbers Nick produced numbers for the other thing, which was definitely much more expensive but I, don't think we we can say based on just a yes. Crypto is more expensive when we were running G hash, so running AES alongside that, may not cost anything noticeable. I. Don't.

A

J

Don't know what what the cost would be. Let's.

C

Take the discussion of the issue, then: okay I can at least bond her to write up the things that people can see them from them in case anybody's confused, okay,.

G

I

I mean if we are strictly speaking about the norms and not to be computing, the key, then my number says that you can do that at something like 28, a second on on CPU like.

A

Okay, so I keep on saying: let's move on and yet the my client still keeps on fizzle sorry process.

N

Question as owner of the issue and writer of the PR, what I'm, really my opinion is on this is irrelevant. What I'm getting from the room is that some people assume that it's one is better because they think something is cheap. Some people assume that the other is better because they think something is expensive. No one's willing to like lay down the road and kicking and screaming on this.

N

If we take it to the list, people will take their keep, giving more arguments and more opinions and a willl a go on and on I think that I would really prefer for this to be a coin toss here and now so then I can we can versus PR and I can move on with my life if someone actually runs those numbers and has further input down the line to the working group, that's that can ward things and that can ward changes to just about anything in the protocol.

N

But for now, in our current knowledge in our current state, let's do a coin flip, so we can move on. So so here's the thing about.

A

Coin flips we did four and http2 and if I remember correctly, two of them didn't turn out so well. In the long run, those are pretty regular odds for them.

N

The odds, but so what I'm saying is the only thing that could make us make a informed decision is some new data. And what can we open this? If and when some people cope with? Do data, but I have a very strong intuition that people will come up with a pinion z--, not data, so.

A

So David, let me ask you this. As the author, the PR, have you heard anything in the room today that will make you change that PR.

N

Not yet, but if the coin falls on that side, I can change the PR.

A

Okay, the editor is: do you still believe that this is proposed already.

A

You just wouldn't flip a coin. We.

G

Haven't flipped a coin yet for quick.

F

R

F

You look at the list on the PR there's a bunch of approvals. At the same time, there's been a discussion that just happened here, and this is exactly coin flip territory. I, don't think that you're gonna find resolution there. Yes, it is propose already based on what we had earlier and now. This is there's more discussion. Now that's causing people to maybe think that we could do something slightly different, but it was proposed already. We can always open it again later, as David says, if we have data.

F

But at this point we are speculating so I'm saying that we should either merge it as it is, or do a coin flip, but either way so I should finish it I'm sure I didn't get that I'm. Sorry I'm saying that we should merge it as it is, or do a coin flip and decide which way we are going.

S

If Mark isn't gonna, stop me I'll come here, repair toupee own, you just need upset. The speakers aren't as loud up here. So I can't hear a lot.

A

Of what you're saying.

S

We did a hum for what people like. We can also discriminate a little more by doing a hum for what people don't like if you care I perfectly fine with the coin flip myself well,.

A

The question that I want to ask is: is that this is proposal ready. We can do a call for consensus on this in the next batch. This is already so. This.

N

Had a call for consensus.

A

N

Ecker raised a point on that saying: we're.

A

Saying what I said in the rules is the one that he am so Acker has any of this change of mind all right.

T

Mike Bishop, if I, can offer a suggestion. As a previous comment noted, the distinction between these two one clearly offers a little bit of benefit and there's question about what the cost is. Would anyone volunteer to get the didn't, get the data on the cost and see if there actually is a difference?

T

Okay? So if we accept Christians data that this can be done at what 20 gigs three gigs a second that seems.

I

Q

I

I mean if we do a regular AES encryption on packets. We have a different nonce for every packet and on the measurement we weren't at our 20 gigs on the CPU in the window stack. So that's I,.

A

Think we should move on pravin, one.

E

A

E

Last comment like this is like a DOS attack scenario right, so we're talking about system already under stress, so any solution that puts even more burden on the system in generate the retry is I. Think like not ideal. Okay,.

A

Let's take it back to discussion, I, don't think we're gonna make any more progress right now,.

A

Thank you, yeah. Our scribe is reminding us to say our names when we're speaking. So, let's move on to the other documents. Let's start with recovery, I think so recovery editors. We have six open issues. Are there any that you need to get some input from the working group on and you want to discuss.

K

Yes, definitely the second one and possibly the third I, think there's the I won.

K

I have a highlight at the end. That I think is the question. At least I want guidance on this actually mostly comes down to pseudocode. Oh yeah, for the working group proposed PR attempts to include a mechanism to limit Steven to increase during slow start we're not pacing by itself. This does not actually fully guarantee the must that we have in another normative section. My opinion is I would rather not add pseudocode for cases that we don't recommend.

K

We say you should pace packets if possible, and you may not- and if you do not, then you need to limit bursts. But if people would like pseudo code for maze as well as shoulds, then we need to kind of revisit that and expand the pseudocode quite substantially. So this is not actually a normative issue, but I'd like some guidelines on like what is the expectation of the pseudocode, doesn't need to like cover all the things you may do.

K

For example, there's no texture, no pseudocode right now around detecting packet reordering and increasing the pakery ordering threshold. As a result of every rank and that's another one that I can see adding, but it's fairly complex, and so it's a fair bit of work. Yeah, sorry ian's. What Google said that? But I'd like some guidelines here, is really what I'm asking for not only about this PR but about going forward and I.

A

Think we'll hear from vidi next.

A

F

A

Lost her actually did we lose me that go no okay, we'll wait to hear back so ah fantastic.

A

Know me deco, we seem to be having some troubles. Go ahead, John! Alright, let's try one more time.

U

A

That's not good go.

F

Ahead, Jenna Jenna younger, so I'll make just a couple of notes: the pseudo-code lives in the appendix that's by design the reason it's in the appendix is because it doesn't have any normative status. The text is normative. The pseudocode is merely a guidance to implementers about how to implement the text. That's already in the draft and to the extent that we want to add stuff or not add stuff there. That's really up to us. It's all guidance in there anyways.

F

So if there is an implementer who's asking for how to do this, which happens to be the case, I don't see any reason to not add it. At the same time, I don't have a strong opinion on this. I personally am of the opinion that we should be.

F

We should be pacing, but that's my personal opinion, not the working groups. Okay,.

A

Today, I'm going to try one more time and if this time doesn't work, why don't you give your input through jabber and we'll jabber relay it to the room.

A

Now Oh Jabbar, please Vinnie, sorry about that. Go ahead. Eric.

V

Kinnear, so I think it does say that we should be pacing, and so it feels as though we should have a copy of the pseudocode, which is kind of the main like. This is what you are expected to do and to John's point. If there is an implementation or a group of implementations, where we know that there's kind of another branch that can be taken in terms of what the implementation is doing, it seems fine to have a section in the pseudocode, for here is kind of the alternative.

V

But I would suggest that that be a separate section, so that there is a clean copy of and I yes, but basically there should be a clean copy of the pseudocode, for if you are an implementer and you just read through the pseudocode and you do that thing you're following the main recommendations of the draft and where we have a place in the draft like this, where we've kind of said, if you aren't following the main recommendations, you must do this other stuff.

V

It seems fine to have pseudocode for that, but it'd be nice to have that. Have a distinction.

U

Gori, gori, fair, has look at a good thing at the back. Cuz I would agree with what we just said, and in this case we have 496, always some pseudocode it for another protocol to kind of build on anyway. So let's keep the main path really clean on the shoulds, and if you want to do the must other and that's fine, but there is already a reference to how to do it on this one.

M

Alright, Andrew McGregor I kind of agree what people are saying about the pseudocode, but we should keep this documentation because it's entirely possible that an implementation may have spacing support that isn't always functional and then need to know. What's do what to do in, we need to know what to do when it's not working.

S

Repair to pay on Google, this seems editorial.

S

R

S

Habits die hard no longer at Google. Thank you very much.

Q

Daniel Kahn Gilmore, relating for video, as Jonathan said, the pseudocode is a reference for implementations which don't implement pacing. This would provide completeness to the pseudocode for increasing congestion windows.

A

Okay, so editors does that give you the input that you need. It sounds like there's general support for having something here: I.

F

Think we can figure this out. This is again like I said it doesn't have a normative effect, so I don't see any reason why the working group really Mesa spend a lot of time on this, but it was valuable to hear input about what people.

M

F

This should so good should reflect.

K

It's clear to me that the working group is split and not so different away as Jenna and I, so yeah I think I think this is useful, like we can keep going. Pravin did want to note that there were a few issues that didn't get a design tag yet because we are in this limbo, where I'm not really sure we're in the late stage process and I haven't tagged thing is designed, so you might want to go through and see if there are things that aren't tagged it with either editorial or design.

K

That also might deserve discussion. And if anyone knows where my badges, then that'd be cool thanks, my name is Ian's, but.

T

Maybe you could filter on not editorial instead.

M

A

Any others you want to discuss editors or anyone else, just.

A

For context, I think we have about: let's call it 20 minutes before we need to start the other discussions. So.

G

A

This end for HTTP a.

F

Couple of issues here, you can see those ones right there which make out of C 69 28 normative and can be make a nominative reference to 80 85.

F

This is worth noting because we are changing something or there's a proposal to change something here that we had agreed upon earlier to not do we had agreed earlier in this working group that we wouldn't have normative reference to two normative references to TCP RFC's for the mechanisms that we use here. However, Gauri has noted that in his review that we don't have any strong basis outside of these references for some constants that we use.

F

For example, we use the 69 28 value of initial initial window of 10 the basis for that is our fc-69 28, which is a tcp RFC. Similarly, we use reordering threshold of 3. That is again I, can't remember which one that is so that's one issue, that's the first one 30 to 45. So there's a there's, a suggestion and a proposal in a PR there now to make that RFC normative. It seems completely reasonable.

F

The argument is that 6 928, even though it was written written for TCP, the only discussion there is about the size of the initial window and to the extent that the size of the initial window matters it doesn't matter what the protocol any uses it's about a network load. So we should be able to use that RFC directly and use that as the basis for making our decision. I won't talk about 80-85 as well, but I, let it finish. 6 9 20 at first.

A

So you know I guess the question is: does anybody does that cause anyone heartburn.

U

Yeah I I'm motivated making that normative it is exp status, but I think it's a useful document to be normative. For this one.

F

So there's actually so. That raises an interesting issue which we may have to deal with later on, which is that this is a standards track document and 69 28 is well it's a standard, strack document, but it's experimental so we'll be putting a dependency on that. Maybe that's alright I'm happy to figure it out later on. If.

A

Folks have concerns about that, get to the key to the.

O

Mic 1, Martin, Duke I, don't understand. What's the difference between having a normative references, you 9:28 or just saying the initial window must or should whatever be 3 in the quick document. Just saying the reason why is over here, if you care.

U

Well, okay, that's interesting, but then is quick, experimental status and and how are you going to justify this choice? I mean someone's already done this made this choice. If you make it normative, then that choice is okay.

A

For me, here's the microphone please.

U

C

That seems like a great solution. Right um I mean I, thought I. Was that soon as a great solution, um you know the the purpose of the text is to explain what the Hector doing and like pointing their document explains if it's not a normative reference, it's like it's just like citing a paper. You say we said it this value and go read this paper to find out. Why.

O

So so Cory is it your? Is it your contention that we should not have the normative so I mean I like how the documents are arranged I think is, is secondary, like the question is: should the should we have a normative reference on what the initial window is or not.

U

I think we should and I think that's what I would advocate here. If the ad finally decides it's a downdraft that they don't want to put up with, then they can take it back, but I think we should have it as a normative that reference, because it is the basis on which this decision is being made.

U

But I don't think that's most.

M

People's understanding with it, we.

U

Take the pacing requirement that goes with it and if that pace and requirements removed, then this document could be changed or you're saying just going to dependently. Do the experiment you clear that as an experiment going to do here, I.

B

C

So what normal requirement means is you have to understand in order to understand the specification you're reading, you have to read the other thing and but what I'm not gonna agree anything right now, because the I understand the specification perfectly well, it's got a number in it.

C

The numbers there, the the an informational reference, means that you may want to read this in order to understand but background or other information, but I, don't like the number sufficient to put the specification and so like, like if you look like, like any random like like crypto like bit using thing it's like for like references but like paper isn't like in like trying to plate SNP and use this security in those things and they're all and like I'm, like he's very hard understand that the technical choices we've made like like like in- and you know in these protocols that are reading those papers, but you don't need to and that's why they're informative references and it's the same, and so they said to which the reason that you recent is this is the background for this number is chosen as informative reference.

C

A

I see lots of nodding heads, so let's keep it brief. I don't want to spend too much time on this gory. One last word and.

U

Yeah like no, we should figure out what we want to do. Yeah.

A

Yeah yeah: let's take this offline I think, but we've heard from a bunch of people, editors, any others on recovery.

F

So there's a similar slightly different but question on 80 85, so 80 85 is the UDP guidelines.

F

Rfc I can't remember the exact title, but it's basically about Europe eBay's protocols and they're, specifically targeting the conditional control behavior.

F

The question here was: should we have a normative reference to that RFC in recovery draft, given that we talked about congestion control, but we also do allow, but does the does the issue that was raised so.

F

Yeah so there's a PR that there's a PR that that fixes this, but it also has changes 80-85 to nominator. Now this is not a tcp RFC, so this doesn't go against anything. We've agreed on in the past. I think this is reasonable.

E

K

Also think this is reasonable, although if we, if our position is that we just don't want normative references in this doc, then obviously we shouldn't do this, but I think this is a much more reasonable choice for.

J

Every any comment on that yeah, so sometimes I'm I think the PR is fine. This issue was sadly worded. We don't take normative references unless we have a reason to take a normative reference.

J

The bug that we had in here was that we had a specification that defined a congestion control algorithm that did not that was optional effectively, but did we did not have a requirement to say that if you do quick, you need to have some form of congestion control mechanism, and that is what 80-85 provides for us, and that is what we're, depending on it for, and this PR fixes their problem.

A

Anything else, editors.

K

If people have time now right now, if they care about the hen, handshake deadlock, prevention, stuff I would request that they take a look at 31 61 and the attached PR and give me feedback as to whether I should just close it with no action or not. But we don't need to discuss it now. But I asked for a review. Just cuz I think only three people or two people have looked at it and then the other issue is I. Think Praveen had.

E

One or two issues that.

K

Is there anything critically, do you want to discuss Praveen.

O

E

Billion I I just opened few recently so I would request the editors to review them and there are other folks as well. There's at least seems to be one safety should that I found in the AB Limited case, and there is two deviations from TCP calculations for a certain time. So we should reconcile those.

A

Okay, so same question for HTTP: what issues do we want to discuss.

T

So probably the most thorny one we already discussed, we've got a couple that are assigned some with outstanding PRS, so I think the main one that I'd like to see working group feedback on today is 30 to 65.

T

So this one is notable and that it's requesting something that is kind of new to HTTP and kind of, not so, basically in each one. You have headers before the body you have trailers after the body and if you're doing chunks, you have chunk extensions, trying to sort out which are their own thing in h2 we don't have chunky extensions, but you can send headers. You can send trailers. This is a request that we remove the restriction that there only be trailers after the body and say that you can send trailers at any point.

T

After the body has started and they're all just trailers, they can arrive any time. That's a little bit of a change. I, don't think it's breaking anything I, don't think it's required by our Charter, so I just like to get feedback about whether we want that or not, because.

W

P

T

P

This proposal by itself is a sensible thing, though I wonder if the quick working group is expected next decision, so I think it might actually be a good idea to raise this topic as an HTTP working group issue and then discuss this as an extension to http, 2 and HTTP 3.

A

So with various chair, hats on I think we do need to go and at least highlight this in the HP working group and make sure that there's comfort there. There are folks like Julian who aren't following this as closely over there. I have a personal response, but I'll let the queue.

X

Drain go ahead, that's her McManus on its face. This is perfectly reasonable. This was perfectly reasonable. Also in each one and as I recall, we didn't add a hook for it into h2 because it was never used and given the no-one's clamoring for it this time I. Can you speak up just a tiny bit and given that there's no strong use case presented here, I think we ought to really let that decision ride.

J

So so Mountain Thomson, we more or less signed on with the contract of porting the h2 cymatics across which were very clear about where trailers can appear. This is kind of cool idea, though so, but I I think that the request here needs to come from the air. Should he be working heard.

B

Luke's party I'm just reading this description, I wasn't sure if Roy's request put in scope any idea of this kind of behavior for server push or they pushed response, push request from server to client. So I think there is something to keep in mind and I might do that.

B

So how would that affect push.

A

B

Is the feature request here applicable to pushed requests? Ie is only capability to add trailers to pushed requests.

B

So if the answer's, no, then that's a constraint of this, which is already there but should be kept in mind. Ok,.

W

um Mr. Roy fielding to answer that Lucas's question I I'm, not aware of any tie to push I would say responses, I, don't think it's requests be close.

M

W

Mic place on the I, don't think, there's any place I'm, not aware of any connection to push responses. That would require a trailer, but then I would I. Don't have all that much experience using push responses that lasts for more than a single frame in this I wanted.

W

I wanted to came with Micra for it to point out that when we discussed HTTP to a lot of emphasis was made, is that we do all these things in the next version of hb2 as soon as this working group started folks said: well we're not going to do another working group hp-2, so guess what quic is a CPU version 2 and if we do not act responsibly when we have needs within the protocol.

W

Just because of the chartering discussion, the Charter must change, because it's taking over a protocol, that's very important to the internet, and we can't have continuing 7-year blocks of time that cannot adjust the basic protocol because the working group that's working on the next version, it doesn't want to address changes that might have come up for the previous version. Ok, I, just don't.

A

So if you have a proposal for.

W

A charter change well.

A

I mean my right, my suggestion.

W

Is that this is within the scope of the Charter, because it refers to http semantics.

A

I, don't think anyone's disputing that it on charter scope right now, so so keep your powder dry, I'm gonna cut the cue but go ahead.

N

David skin Ozzy Google Chrome.

N

If there was a use for this, someone would have built it as an extension to HTTP too often like when there is a use case for something people build it so that I get that that's not entirely true, come because sometimes the people who build it or not the same people who write the stacks but very often you'll, hear at them clamoring that they want a new feature and especially when a feature can be trivially implemented as an extension, there would have been some movement there.

N

I would much rather see this as an extension and, if look like we've been doing with like gos 1:3 and htv-3 popular extensions get ported into the next version of the protocol. This is not a population of h2 that warrants putting into h3 so I would, and on top of that, this would require some work, which I'd rather not have to do so. I strongly encourage this to become an extension, and if it gets widely used, then we can add it to the next revision. Victor the keys cut.

O

Martin Duke I have no technical opinion this at all, but I think if we are going to mess with hb2 in ways they're not immediately germane to quick I, think we should.

O

You have DHT to be working group, give us guidance and as long as it doesn't influence the the schedule, we can try to bring it in and that's kind of it Mike's prerogative and I'd, rather not waste more time discussing the technical merits of that in this forum with people who don't know what they're well people like me, who don't know what they're talking about Thanks.

A

So I think we're hearing. You know that the impetus for this has to come from the HTTP working group and I think from from a charter standpoint. You know we're chartered I think to allow the semantics of HTTP to that's been a problematic phrase in the Charter for a while, because really the semantics of http/2 are driven by the generic semantics of HTTP, and so this is probably an HTTP core issue.

A

If those semantics are excuse me clarified in HTTP core, we can choose to bubble those into HTTP three, and that would be the path I think that would be most sensible for this I. Think personally, I agree with Martin. This is this is pretty cool I. Think a lot of people can imagine use cases for this if we're commonly available. What I like about it is that it's backwards compatible with existing api's.

A

You know it's there's one thing about the wire serialization and decoding the frames and everything, but there's another thing about how do I bubble this up to applications and if my API doesn't support having trailers in the middle I can just collect them and then make them available at the end. If the trailer supports normal trailers, the API supports normal trailers, so I think it's deployable. But let's have the discussion in the HT working group Roy.

A

Maybe perhaps you could open an issue on core and we can discuss it even tomorrow and then see where that goes make sense. Okay, sorry, an issue in.

A

Yes, an issue in core place: HTTP core. Thank you, I assume, that's what you mean by the other group. We're not gonna blow third group into this all right, okay, good!

A

Like any other HTTP issues, you want to discuss now. I.

T

Think most of the others have pending resolutions, or at least assignments. So if you have an issue assigned to you, please make progress on that. Pr I would appreciate it and otherwise I think we might be better served by giving the other presentations so I didn't catch that we might be better served by the other presentations. Okay.

A

So one more thing before we go to those, we have an open call for consensus on taking the recovery and HP documents to the late-stage process from talking to folks I think we're pretty much ready to do that believe that open a little bit longer for any other further feedback on the mailing list and then we'll we'll make the transition for those okay.

A

So what ordering did we decide upon? We decided on pun, datagrams. First.

A

Sorry, um it's not gonna. Do you any good? Sorry yeah one moment, I'm not gonna, put random USB things in my laptop nice. Try.

A

Go ahead, Eric.

V

All right we're gonna, try to keep this decently short because it's fairly straightforward and we've got a lot of other good stuff to do so. I'm gonna try to get through all the slides and then we'll talk a little bit at the end of that. So we've talked about this before and we've had some side meetings and other things in which many of you have engaged.

V

So thank you for that, but I'm Eric Kinnear in the middle of this slide and let's talk datagrams so in some of the side meetings and the other conversations that we've been having we've learned a very long list of use cases where people think that they would like to use datagrams to support unreliable data, transmission and I put a couple on this slide, but there's really way more and really the the thing that seems to shine and come out from all these are our applications that would like to have a reliable control stream or some sort of negotiation and and reliable transmission of information between the two endpoints to coordinate some other transmission, which can then be unreliable.

V

We also notice here that quick provides functionality beyond what you just get over DTLS and UDP a lot of that being the multiplexing of these streams and the last reason we really wanted to do. This was because it's a very straightforward extension that makes sure that we can kind of grease and use the extension mechanism and make sure that it's working next slide please.

V

So we want datagrams in quick as opposed to just dt, OS or somewhere else, because we want to be able to share that same handshake and authentication context that you're using for your reliable stream data in your existing communication, with some other endpoint for unreliable data as well, along with using that handshake, etc, etc.

V

Comes with the fact that quick generally is going to work pretty well for that, for example, DTLS retransmits, handshake, packets, on a fixed, timer and quick is going to be using the full mechanisms of quick to get packets to the other side and there's also a bunch of other quick features that are really nice. So things like transport parameters and the ability to negotiate things upfront having acknowledgments of this Datagram data.

V

So, even if it's not retransmitted, you can tell whether or not it got there and potentially adjust your sending rate or or make other choices based on that information, and you can also multiplex additional content over the same transport. So you have the ability to sit there and and have your control stream. Have some other content going and bring up multiple different streams worth of data, one of which is this unreliable Datagram? Next, please, the design has simplified greatly since we first started talking about it. So thank you all for your feedback.

V

There's now two frame identifiers- and it's really just the the last bit there determines whether or not there's a length field present. So if there's a link field present to you, have a Datagram frame, followed by the length of that Datagram frame and then whatever data you want and if it's not present, then it extends to the end of the packet.

V

So you can skip that extra overhead for those of us who are super concerned about overhead, which starts to actually matter when you start talking about tunneling and doing some other things, it's a negotiated via the max Datagram frame size, transport parameter, which helps a lot when you're looking at things like PLP MTU D next slide, please.

V

So in terms of the details that we've hammered out since we started talking about this Datagram frames are act eliciting they are not retransmitted. Ping is the same way, but in at least our implementation. We discovered we'd made some interesting assumptions about what a Calissa ting meant in terms of recovery and congestion control. So we need to make sure that we have the distinction between frames that are not retransmitted and frames that are separately from frames that are act versus not. They also do not contribute to flow control limits.

V

However, they are congestion controlled, so you've got your congestion control, getting your pipe of data to the other side of your connection, but there is no sane way to do flow control here, so we took that out. Flow IDs are also gone. Thank you for your lovely feedback. However, they didn't go super far. David has written up a draft that adds flow IDs into the HT p3 datagrams, which can live on top of this. So it's pretty much exactly the same, but it solves a lot of thief: low, ID questions.

V

So please take a look at that document and go there, and the other thing that's noted in here is that max Datagram frame size can be stored and used in gr, rtt requests, etcetera, etcetera. Next slide, please.

V

We were really really happy to see that at the hackathon we actually got some inter up on here, and there are several more implementations. Even since I wrote the slide that I know I've been looking at adding Datagram support because it should be pretty quick, but we've got several that that are already doing it and also thank you folks for the Wireshark toast sector, tea screenshot. Oh, that's pretty fun! You have a little data gram thing and then there's a blob that currently says quack so yeah, so it so far.

V

The feedback from from implementers has been that it's not super difficult. To add support for this frame type, there have been some really good discussions around API and how you let an application know that something was probably lost or certainly act. So those are good things to keep in mind, but don't actually affect the on the wire bits at all. Next slide, please.

V

So that brings us to the end of our hopefully short set of slides, so thoughts, feelings and the other thing we were looking for this time was to potentially talk about a call for adoption sure so so.

A

Just to be clear, you're suggesting and call for adoption just for the quick diagram document, not the HTTP three bonding correct right. There's an interesting question there that when we do get to the HTTP binding, whether that's done here or in the HTTP working group, because our intention has been to hand off h3 to them after we're done exactly yeah, Mike Mike.

T

Bishop, this is not a question directly on datagrams, but something that datagrams brings up. I noticed that you reserved two adjacent frame types so that you could embed a flag and the type just like the the inspect frames do do our new reservation policies that require random assignment. For that.

Y

T

Question I think we just changed the registration policies for well, okay, we own we discussed in cupertino and we have a PR and part of the guidance, and that is that I Anna is that we randomly allocate. That's not. Are you allowed to randomly allocate to adjacent points under the current text or a.

N

Block of registration, facts in language.

T

N

As someone who's worked with Martin on that PR, it doesn't quite say that so we should just add text to allow it, because that makes a whole lot of sense. If you're right I think was next.

R

Victor was silly of google. We use data chrome frame currently in production, so I fully support working group taking on such work.

S

Roberta pay on Facebook.

S

I'm certain that we're gonna adopt this pretty much, and that's a little scary for me, because I worry about the fact that it's going to be interesting at proxies, especially without flow control.

S

So I think there's a lot of hidden problems here that we've suffered through in the past again I'm sure we're going to adopt this and I bet. People are going to figure this out, which I guess is a good thing, because then we can replace it with something better. But it might be a good idea to at least put some text in about the fact that intermediaries with no flow control is a recipe for fun.

A

So folks, folks, the q1 thing that I'd like to hear about is timing in terms of whether you think it's important to adopt this now or whether it's important to wait. If.

O

You think we should adopt it. Yeah crystal and I think we should adopt it's good work, I've, no opinion on timing, I! Guess that's for other people who care more about this I just want to say that they're interesting security implications that come from this particular extension as a Waterdown example of something that might go wrong. Imagine an application is using a Datagram frame to send a very secret specific, sensitive message like fire, the missile and you have an attacker who's like randomly dropping back. It's um waiting to see whether or not things are retransmitted.

O

The fact that these are not retransmitted leaks, a bit of information and like how that affects you know, quick security. Posture is sort of not clear. I've been talking with Kenny Patterson about this particular issue.

O

Don't know if it's a big deal but like something to keep in mind and maybe birthday acknowledgement at some point in the draft, but ya.

O

N

Send it to be transmitted.

O

N

Quickly jump in as a author of the document Chris, would you be willing to file an issue discussing this problem against our github? Please yeah, of course. Okay.

A

I'm going to close the queue very soon, I think Moses.

Z

And I think this is important work to do now, especially because I think it's gonna surface things that need to be fixed in other drafts, especially recovery. Presumably a big user of this will be media applications and flow control and congestion control sections of recovery, and even this draft are they need a lot of work. You know there are a lot of conflicting and country things, and and- and it needs to go broader than just this group- there's other groups in other areas that need to weigh in on this too.

Z

So I think it needs to be done now. Sooner than later,.

O

Martin Duke, f5, um very exciting and I think are important work. My only concern is bandwidth. I think there are a few what we're, starting to punt things into extensions that we really really need soon after v1 ships to make quick work properly, like version greasing like maybe this version, Association thing, etc and I think we can probably walk into a gum at the same time, but I would like to I think there's a lot of key resources that need to commit to support to work through all these things simultaneously.

AA

Hi Colin, Perkins I think as a minimal Datagram extension. This is a very reasonable thing and I think we should adopt it before we finalize it. I would be interested to see how people are using datagrams and what people are building on top of it. We may find that a slightly less minimal, Datagram extension turns out to be a more appropriate design once we have a little more experience flow, IDs being the obvious thing in that space. Thank.

A

You the queues, closed after Jana.

AA

And yes, you can clearly build one on top of the other if everyone is using a flow ID. If it turns out that everyone using datagrams wants a flow ID, we should probably just build this into the Datagram.

B

Lucas pardhu I support adoption of this document I think that although the design of the frame itself is fairly simple as many issues in terms of how we use this thing and that having a venue to to bring in people to discuss those and actually capture that information is really important.

K

Yeah I think we should drop this now. I, don't think, there's any reason to wait and I appreciate all the simplifications that have got to do it, because that makes it much clearer to reason about and gives me a lot more confidence that they're not gonna screw this up and.

W

Who are you sorry that was.

K

Ian, thank you. I am Brian. We are. We are both from Google, although entirely different parts of the company, uh yeah, actually I, basically came up to say what Mo's ed and then what Ian said and then what Lucas said so do it? Do it now.

F

Gen-I and god I support adoption of this document, but I'll it is. It is a bit of a fur gun like Roberto, says but I think it's an obvious foot gun. We all knew this was coming. That said, I will I will say this one point, which is that I think this is useful in other way, people are already implementing it, so we actually get to exercise the extension mechanism and I think that's super useful that we don't need to prioritize this, because the functions here aren't critical, I.

F

Think Martin Duke was right that we have other things, but this one is useful because it actually allows us to implement an exercise that.

G

A

Think that's all good input. Thank you very much. Eric I'll talk to Lars, we'll talk to our directors and we'll likely see a call for adoption soon, but we do need to consider the Charter aspect to this as discussed. Thank you next up. Where were we version ago? She ation.

N

Good morning, everyone.

N

My name is David skinned, Ozzy I work at Google and I'm here to talk about quick version negotiation. So this draft is joint work by our horse. Calling myself next slide. Please so first point wait a minute: what are we talking about? Doesn't quick already have first negotiation, so the yes to some extent the quicken variants define a version negotiation packet, it uses version zero and it sends a bunch of versions in quick v1. So the quick transport draft.

N

It says if you receive one of those to fail the connection report back up to the application that quick is broken. We cannot use quick because the server doesn't support this version. That's fine, when all were the only version in the world is version 1, because if the server doesn't support it, then you're dead in the water. But what if another version were to come about? The client could, in theory, just get that back and reconnect with that version.

N

If it supports it problem, if you just do that in AV, you could expose yourself to a downgrade attack. What if an attacker sent that packet and because the client supports version 1 and 2, and it turns out that one is no longer safe, because we found a really bad bug in we don't want an attacker to force you to use one, even though both the client and service support, that's the main thing.

N

Another point is the whole main premise of quicks existence in the first place is to be fast like allow us to actually send the request to the server in a few hour around trips as possible, so spending a round trip is a deal-breaker, especially for browsers.

N

So if we were, for example, to say like we have quick, v1 and then quick v2 comes around, some of the servers will support one, and some of them will support one and the browser can't just go to, and then in the case, where some servers don't support it spend a road trip, then go to one, that's too expensive and that's a complete deal-breaker. So what do we do next slide? Please.

N

So if going back a year but I know, we've been doing this for too long I, don't remember. When we did what at some point, we had this as part of the spec, the original transport parameters code had support for downward prevention and the way it worked is the server would just send all its versions and the client would say: wait a minute I or originally sent you this version and now you're telling me that we switch to something else, but you support it.

N

The first one in the first place, what the hell that must be an attack abort, but someone at the time I've forgotten. Who pointed out that if you have multiple servers as in you talk to a first one, it tells you now I, don't support this version negotiation. You try again and you land on a different server, because you got load-balanced and they don't have the exact same set of versions.

N

Then you can end up in a situation where, for the client it looks like a downgrade attack when in reality, you just hit two different servers that are both equally trusted and both have the private keys for the TLS, sir. So that's bad, both in the multi CDN case, but also, if you're, just in your own network, in currently deploying your software and so there'll be a period of time where the new version is hit here, but not there.

N

So at the time we were starting to argue about how to fix this and, as with all the problems that are a lot of the problems that aren't blocking for quick view on. We said: okay, blunt this out, we don't need it. We want to focus on getting quick view on in. We can always build this as an extension later. This is that extension.

N

It comes with two main goals: solving the downgrade prevention problem, but also this spending an RTT problem. It allows us to deploy quick v2 on the Internet in a way that both the client and server use it without the deal breaking spend of an RTT next slide. Please, in order to do that, we, this draft introduces a concept which is compatible versions, the idea there being that, if quickly, two ends up looking very much like quick view on, let's say, for example, a quick v2 is quick.

N

V1 plus the Datagram frame that wouldn't change much for HTTP 3, so you could say these versions are very similar would be great if we didn't spend the RTT, so we define compatible versions as when the server receives the client floors flight. So in quick view, 1, that's the initial containing the client hello. If it can understand that and map that to a v2 or version B, as I put it here, first flight then they're compatible, so they make mechanism.

N

Is the client sends the first flight of the version it thinks that is most likely to be supported. So, for example, if v2 just came out that would be v1 and the server and the client says, oh by the way, I. Also support me to which I know is compatible with you want, and then the server says. Oh I support that too. Let me convert your initial to whatever a first flight in is in v2 and run with that. So then you, the initial, that the server responds with, is now a v2 initial, pretty simple.

N

We just need to make sure that we don't allow downgrade attacks or foot guns. Next slide, please! So how do we do this and, as with most extensions, it's a transport parameter, so the transport parameter contains different things on client and server on the client Ted. Do you want me to go through the slides or is it for now I.

AB

Have a question at.

N

The end okay, so the just return on the client contains a few things. The first one is the currently attempted version, so that's redundant from the version that is in the long headers of that initial. But what it means is that version lands in the TRC schedule and if we've learned anything from the history of TLS is that, if things are not in the key schedule, then you can end up with some really funky attacks. Where someone swaps it and you don't realize it.

N

So we put that in there that way, it prevents an attack where your attacker is just swapping over that version.

N

You also add your previously attempted version, meaning if I tried a got a version negotiation and tried B when I'm trying be the I'll say here that oh I tried a originally by the way and I send a copy of this verse negotiation packet I got from the server and just a payload, which is just a list of versions that were in the version negotiation packet. So the idea there is on the server when you get that you can check.

N

If that you, if, in response this previously attempted version, you could have potentially sent this VN packet and the client sends one last thing, which is the list of compatible versions that the server could in in-band switch to if it supported them. Next slide, please from the service perspective. The first thing is the negotiated version so similar. That's also the version that's going to be on long headers, but that way we landed in the key schedule and then the supported versions list.

N

So the idea there is, if there are incompatible version in particular, especially let's see version 3, is not compatible. You can tell the client hey by the way for next time. I support this, so the client can cache that if it wants the same way today, we cache things based on all service, for example, next slide.

N

So how does this work for downgrade if the attacker is tampering with the version in the long headers, though the first part in the transport prior won't match, so the TRC schedule will fall over and the way quick is defined. You have a bunch of versions in a bunch of long headers, but the first one you get is what you establish on that connection. So if it changes after that, you drop them on the floor. So you have that strong map in here and then, if an attacker forges a virgin negotiation packet. So it's.

J

A clarification, yes, you have a client and server have to check these things match. You know in order for things to fall over, it's not just a not just that the handshake pulls over.

N

Automatically sorry, that is what I meant. The server like both sides upon receiving stuff need to make sure that they match agreed, and so, if an attacker forges this a great one, the list of things like because those are there, it can say, wait. The server can say wait. A minute I would have never sent you this the end packet because I know all my servers support. This version, that's bad, and if the server deployment has different banks, where knows like over here, I support one and two and over here I only support one.

N

Then I can say yeah it's possible that I sent you over negotiation for just one cuz I know I own some servers that do that, and also, if you're in the multi CDN use case. If you know what the other CDN versions, you can do that here next slide, quick.

T

Question Mike bishop: if somebody tampered with the version, isn't that part of the ad the packet would just felt worse, yeah.

N

Bondish initial packets, the.

T

Initial backers can be rewritten.

N

All right, so the mechanism is pretty simple. The draft tries to describe that. The draft originally only did compatible versions and kind of a few weeks ago before the deadline, we kind of rushed in to add the downgrade prevention, and so it makes the draft really clunky to read. So that's on me I think we need to work a lot on the framing and refactor it to make it a lot more sensical, but I think the mekka mechanism is correct.

N

So what, if folks think, especially there are cases like the ossification work that Kazuo proposed that might require version negotiation? So I think it would be nice to have this in the working group it to progress it. Okay,.

A

I can see a lot of people want to talk about this. We have about five minutes, so I would suggest that we focus on. Is this an area that the working group thinks it needs an extension in? Is this a reasonable starting point for that extension, knowing that it can change, and do we need to do it now or do we need to wait and questions of clarification if you need them to answer the previous questions, please go Ted 10:30.

AB

My clarification question actually relates to the discussion we had yesterday with a LPN. We can't hear you Ted, okay, I, wanted to ask the relationship between this and the discussion we had yesterday about potentially using a LPN with full-stack, as opposed to just the particular application layer. If we do a LPN with full-stack. Does that obviate the use of this okay? Thank you.

N

So to basically this version negotiation mechanism is for the transport layer and if you don't speak this, you don't understand the client version at the transfer layer. You won't be able to parse the LPN. So there's still a need for this.

S

Repair to pay own I did not see a clear discussion of what happens in the zero RTT case with us, and zero are ITT being the thing that is now fun and providing a lot of value. I think that would be great to answer. Marc's things. The first answer is yes and.

N

To give a ten second answers: your TT is a perversion specific concept. So if you don't understand that version there, but that is a good point. We need to add more text. If you do four compatible versions, there's going to be work to figure that out. If we do not figure that out.

S

It will be difficult to upgrade because you will suffer performance penalties that you wouldn't otherwise good.

N

P

Cattle Hawks, thank you, hope presenting in the draft I think this is an important work. On the other hand, I wonder if there's immediate need for this to be adopted due to two reasons. One is that for something like datagrams can be negotiated using a future, and my decided that we only need a version number change when the pockets, the critics putter pockets, that's being exchanged during the handshake changes. The second reason is that for something like version, something like version aliasing, we need a different kind of downgrade protection.

P

For example, the proposal that we had using a new token frame was to use the value of the token to see if a down gray should be prevented, so this one doesn't address the old cases where downgrade should be prevented. So that's one of the reasons, I kind of wonder. If we can park this until we have a something and do we have a new quick version that actually uses a different country, chimerism I'm.

J

Gonna close the queue after Roy and Martin do better up, not in Thompson I think we need an answer to this one. Before we start working on the version. 2 I somewhat disagree with Kazuo, though I recognize the points of valid.

J

This document needs a lot of editorial work, I, provided that feedback I think there's different ways to spell it, but the basic framework of what David described, which is to have the incompatible and compatible upgrades, is quite valuable and so I think we should adopt it now and treat it like the other extensions I. Don't think we need to block quickly one on this being complete, but I do think. We need to be working on this so that we have a story for when we do have quick v2 and we.

C

Have a design it's.

J

Good enough take it.

C

Well, this makes in the right place for us, Eric, rajala I'm, one of the authors, I, think we've traded out this I frankly have some misgivings are at the incompatible negotiation, but we can fight that out in the working group, but I think like having that like, like having a good item to sort to work on negotiation. I think like we should do and we can figure out the details later or this is good. A good video start.

K

You but Google, yes, I also think we should adopt this, though, if if it turns out that you know due to the editorial work, it's easier to do so sometime between now and the next ITF in a few months. That's that's fine, but I. Think sometime in the next, you know three to six months. We should be doing this in this working group.

W

Roy fielding Adobe I I'd like to get a little bit back to the HTTP, 1.1 or 1 versioning scheme. That has the ability to send optimistically minor version changes that are compatible.

W

So is there a way to do that in this scheme and other than that, I would also approve adopting so.

N

Just a ten-second answer so currently quick track at the transport layer doesn't have a concept of minor versions, but maybe the compatible versions is that so we'd have to maybe that's there's a mapping layer, the let's take it offline, bring that to this because I think that's an interesting point. Okay,.

A

Thank you very much, David we'll where.

N

We're going from here.

M

A

Chat with Lars we'll check with the aero directors, it's definitely on the list. Thanks. Thank you. Come.

O

On morning, everybody home martin, duke one of these, your suspects just to see how much didn't you talk about it can I see a show of hands. Who's, read the draft okay about half the two thirds good next slide. So this is a.

I

O

A lot of things, but it is mostly about allowing servers and load balancers owned or implemented by different entities to work together.

O

Basically, you want load balancers to work off connection ID rather than four tuples, that you don't break, not rebinding resilience and so on, and so the ideally for a low state load balancer. The connection idea should contain the server ID mapping, and so this is just basically proposing several standardized methods of encoding. The server ID mapping in the connection ID, so that the load balancer can understand a packet and or understand the routing of a pack get to the correct server next slide.

O

Okay, this is turned out to be a useful vehicle for several other problems, for instance, there's interest in having essentially the quick equivalent of sink the offload, which is which I've decided to call retry services. So there Nick banks I'd co-author akin for the scheme on how to do that.

O

So that's also in the draft and then also there is interest in eventual Hardware crypto offload for quick and after some conversation of Intel I was certainly convinced that that that would very much benefit from somehow encoding the length of the CID inside the CID, and so, if you are trying to use those services to provide standard way to do so, so we can use ones. You know a fixed number of chips that to solve that problem. Next slide, please! So, basically, you know the the underlying value.

O

The value statement and quick is that if middleboxes try to mess with the connection, it kills the connection, and this is amending that that attitude to instead say that the server must explicitly consent. This sort of quote-unquote contribution that the middle box is making next slide.

O

This is fairly clear from the draft, but I do want to highlight this point and a lot of conversations about security. It's a very much a binary thing where something is secure, or it is not. The point of a lot of these server, ID and coding. Algorithms is to is to hide the fact that a connection that two connection IDs that belong to the same connection are going to the same server.

O

However, this mechanism has limited ability to solve that problem in this extreme. When you one client connected to your server pool, you are linkable, no matter what the C IDs do next slide.

O

Conversely, if you have approaching infinity clients per server, then you're about as on linkable, you could be regardless of how clumsy your scheme is next slide.

O

Let's get next slide, okay, so the first part of this draft is basically just providing some common configuration and what to do given that configuration, that is, it's describing some algorithms. There are basically three bits to this.

O

One is one is what method you're using to encode the original? That's the issue, connection ID in a retry token, to allow these retry services. A second thing is whether or not using the CID length encoding and then the third thing is what algorithm you're using to encode the server ID in the connection, ID next slide and then there's more stuff there for that's parameter specific to each of those algorithms.

O

Now so again, the first part of this configuration, then the second part is well. How does the configuration get around? The draft definitely enables you to go ahead and use whatever existing config distribution infrastructure you have. That is probably encouraged, however, for people who don't have that there is a very simple in-band protocol.

O

It is the overriding design, principles or one to be very simple and two to look sort of like quick, because the one thing can guarantee about a path we've seen a little balancer and the pic server is that it it bits quick next slide, I've, gotten robust and diverse feedback about that in configuration, and you can see some of it.

O

I have no particular love for what I wrote down there and if the working group as a whole kind of gave me a solid message to go with one of these three one of these four options, I would be happy to do so with two caveats number one find something needs to be used. This number one and number two I do want to talk a little bit of putting in a different draft. So there is, of course, the general problem of proxy to server communication in TCP.

O

We have the proxy protocol that does not work in quick for a variety of reasons. There's some desire to maybe find a solution for quick and I would be happy to have this fall in with that effort, but that effort does not currently exist next slide.

O

Some other discussion points, so one thing is one unfortunate property of all of us is that server infrastructures are deciding whether or not clients are linkable when, fundamentally, that is something that affects the client most of all and would be great to have a way to communicate somehow with clients how linkable they would be if they attempted to migrate, and then clients could make the decision as to whether they wanted to go ahead. Migrators tear down the connection start over the whole new connection.

O

Should they change IP address, so you could do something good transport foreigner, particularly if something like quick OB was, was a you know, a standard, a reference point on what was a Lincoln Bowl. What was not so I would appreciate feedback on that, and maybe there should be a quick extension second issue. Retry services are, they are course version specific, because retry packets are version specific. All the other stuff is based on connection ID connection. Id is part of the invariance, a link field, which probably will not have a problem.

O

So do we really want to have things that are quick version specific and not version specific in same draft if we rev quick, that might just be an editorial pain without waiting deep into the algorithms for people who weren't reading it? There are some some of these methods involve encryption and some of them don't there's one that is sort of an obfuscation algorithm that attempts to do some mathematical operations to make the server ID less obvious.

O

A lot of people will say: I've heard from a lot of people that that don't see that it's clear that that's cheaper than just doing crypto. On the other hand, I've heard some pushback from others that that they would really I see didn't see a an option like this and this okay. This actually kind of moves on to the second point, which is I, think we've struggled a little bit to get really robust engagement with a lot of the low state load, balancer vendors, particularly in the cloud environment Nick.

O

My co-author has talked a little bit with the Azure people and, and frankly, a lot of it is what one obstacles to get through. The initial reaction of this sounds like a pain. Can you change quick? So we don't have to do anything which is probably not a realistic view of things. So um you know really it's. What are people will you know this? This room is essentially the community of pic server implementer. So obviously your feedback is quite important.

O

It'd really be nice to do I'm still trying to work to try to feedback from the other end of this of this communication. To answer some of the questions like the third one I have on this slide. Next, please so I would like to move for adoption. There were a few fairly minor issues that are open on my private github, but ultimately, I don't make move forward on these on these larger questions without larger, broader working group input, and these algorithms are not that complicated I've already played with implementing them.

O

That was at most, you know hundred lines of code to do one of these algorithms. If we really nice to start interrupting with them, I would hope to maybe do that as soon as Vancouver and definitely there's some there's an opportunity for somebody to help help me set that up and define that.

A

Yeah and that's it: okay, Thank You Martin. So again, we only have a few minutes to discuss. I'd like people to focus on is this appropriate for this working group? Is this the right time? Is this the right starting point, and especially I've heard a question of whether it's appropriate to do this in the quick working group or elsewhere? So if you can speak to that, that'd be interesting. Please go to some.

J

On Thompson viewpoints I like the model I like the way you're framing this I, don't like the protocol, but we can talk about that. I'd, probably like to see that separated I, don't want to see any ghetto crypto in any of the things we produce here. I would prefer that we have where.

M

Time limited: let's move on.

J

So I'd like us to look pretty seriously that sort of thing one of the things this looks a lot like is the sort of work that happens in the in the ops area in this organization and I predict that we'll have some young people looking at this one I don't know how you want to manage that. But expressing these as yang models is something that I I suspect will happen, whether you like it or not, I'm.

O

Open to using it yang model to express the configuration I, actually, cracked, open the RFC for that and solves 172 pages and then thought maybe I could get someone to do. You hang a lot of for a fee.

J

O

J

Don't think it matters how it's spelled so much as that. What the contents of the model are, so let's concentrate on getting the models right and then we can talk about how to how to spell it. Okay,.

A

Let's not go too deep. Keep the comments brief. Please pretty.

E

Praveen I think the graph is great, especially like the fact that we are giving options that are incrementally deployable instead of going to like a really expensive solution. It provides multiple solutions on the way there and I think this extension of the three we talked about is the most important because it directly affects quick, wave and deployment and like data centers in the cloud so in terms of adoption, I think it's the most important and they're already talking with like third party load balancers about this, so I think it's very timely and very very important.

AC

Make a livin so I think Martin mostly said what I, what I wanted to say: I think it's! It's good that you put like the different parts apart and like as much as I would get because he's belong together. I think it's like easier to rip them apart. I'm, especially uneasy about like defining a completely new protocol here for configuration. I think what could be in scope here is like the configuration it solved, the yang model and the algorithms for sure, because we have an open issue on that, one in the manageability, Draft and I.

AC

Don't care if it's in that draft or if it's separate draft but I, think it's very much in scope and I just wanted to add that there is ongoing efforts about proxying in general, so that could could fit and we're moving on, and we probably will propose some more work at the next meeting. So that's that's in process and we should sync up a little bit more.

O

Tell me poly Apple yeah, so we should adopt it. We should adopt it now and I agree that we should split out that other work, but.

C

The protocol work.

O

For the protocol work yeah, you.

I

O

The definition of the quick bits here I think that's all. You should do and kind of find them, maybe another home. For that part.

V

Eric Kinnear keeping things quick what tommy said, but I'd also like to say yes, we should also adopt this because we as people trying to deploy things at scale on the server side. It will be very helpful to have guidance in this area and I. Think that's going to be instrumental in in making a quick that that many people can deploy as opposed to a few people, can deploy.

Y

Equations gave Verizon media Yahoo eeveelutions gave Verizon media Yahoo EdgeCast very.

M

Close to the microphone, please.

Y

So I think this is great work. Thank you really fantastic to actually define every way of doing it. We absolutely should adopt this. We, this is one of those things. That's missing from being able to actually go. Large-Scale, deploy, I agree that the protocol actually probably should be split out, because some of us will just want to express this as yang's. Some people want to express this as JSON other people want to do in band different people and they do different things, but ultimately I hate to use.

Y

There was an example, but how we exchange the bits this day and age really doesn't matter for configuration, so just define a semantics and everybody else will figure out how to encode it, but the actual algorithms, that's what's more critical, and that requires Interop, and that's that's awesome. What you've done so absolutely we should adopt us. Thank you, one more remote.

G

Should be adopted, okay, that's.

A

What I heard Roberto.

S

I think you'll have the last word what the last four people said. Sorry, what the last four people said. Thank you.

A

So I think from what I'm hearing we should expect a revised draft from you, that's pared down. Perhaps does that make sense.

O

Yes, I would still I've been decide, shows obviously available. There's a number of contentious issues. Well, a contentious is not the right word. I've got I've gotten no uniform rec feedback on a lot of these issues, so I encourage some of that, because I might even pare it down more, but.

A

And that's what we don't need the issues to all be solved to adopt that we just need to have a good starting point in the web scope and from what I heard people have concerns about the the protocol portion of it. Yes,.

M

A

That out, focus on the model and then go from there. Okay, and do some coordination with ops do some coordination elsewhere, we'll figure it out? Okay, all right great! Thank you! So one more thing, I think we've got one minute left John did you want to speak briefly? Thank you. I.

G

Have slides during clothes.

F

G

I, have you have slides.

F

Up there on the thing, if we have time, if we don't have time, it's fine I, don't.

W

G

F

Well, the if, while you're pulling this up I'll talk about very quickly Martin's, Eamonn and I have been working on a quick Interop runner that basically automates interrupts testing among various implementations. We introduced this at the interim and we had a couple of implementations playing at the inn at that time, and now we have a larger number of implementations. I can't remember how many we have at last con over six or seven implementations are now in the interrupt runner and they're all working with various tests.

F

We have I think managed to get most of the tests that currently are part of the interim suite in the Runner. The value of using this runner is obviously that you automate all tests and people are exporting their implementation, so you can run against anybody's implementation at any point in time that you want it generally, it's logs. It generates various things that you can look at for debugging purposes and we encourage those who haven't yet put their implementations into the runner to please go ahead and do so that's about it.

F

I was going to show a chart that it produces the matrix, but that's yeah and there's a if you have any questions about it. Please write to me or to Martin, there's also a slack channel that you can join. What's the slack channel a quick, Network, sim I think it's called okay, yeah, quick Nicole, then great.

A

Thank you I think. That's all we have so we'll close the meeting, hopefully we'll see a bunch of you in Zurich or, if not there in Vancouver. Thank you very much.

A

A