Internet Engineering Task Force Interim Meetings, 15 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: MASQUE WG Interim Meeting, 2021-04-15

Description

MASQUE WG Interim Meeting, 2021-04-15

A

All right, let's get going so welcome to our april interim for mask we've, got some fun things to do and as we get into those fun things, this is the notewell. You should all be familiar with this. Please read it again in case you haven't, read it in a while, but these are the terms under which we participate here, make sure that we are reading this, paying attention to it and especially being respectful and kind to everyone else, some useful links. The notes are here. uh Thank you mike for being our notetaker.

A

um For today, we've talked about scribe selection, the notewell we can batch the agenda, we're going to start off by putting the first half entirely on connect, udp and h3 datagrams. We've got a couple of choices that we need to make on that, and it would be good to get some of that wrapped up.

A

Then we're going to do a presentation that we have deferred quite a few times, that's still in the connect udp space and, as we finish with our connect, udp stuff, we're going to go into ip processing requirements and try to wrap those up as well and then, if time permits at the end, we've got a little bit of a preview of some of possible solutions for connect ip.

A

In terms of concrete proposals, which I expect we will be talking about a lot more at the next ietf meeting anyway.

A

The other thing we're going to do is try to time box this fairly strictly so we've put times for each of these things we're going to put a timer up on the screen and let's make sure that we stick within those so that we have time to get through all the things we want to do. There's lots of good discussion. uh Sometimes we may need to take some of that back to the list and with that, let's get started with h3 datagrams.

B

C

Thanks eric uh hi everyone, I'm david schnazzy and uh so on, the agenda we're talking about both connect, udp and its dependency h3 datagrams, but um with there was a lot of conversation recently on a tree datagrams and we kind of realized that there are some pretty big open design issues and those would like have cascading effects on connect, udp, and so what we're going to do today is we're going to not really discuss, connect udp at all, because a lot of the open issues on connect2dp are kind of dependent on these design decision, httpd grams, so we're going to kind of put connect udp on hold until we reach consensus on those points in h3dgram like not on, like all of the my new details, but at least on the fundamental design, goals and properties, and that way, then we can go, go back to connect udp after because otherwise uh we would be kind of changing it.

C

A lot cool next slide. Please.

C

um So a quick uh summary uh for those that haven't been following the list too closely, uh so the quick data graph, the grab frame, is an extension to the quick transform protocol, uh but it is not defined.

C

uh It doesn't have defined semantics in http 3, which is an application layer protocol and because http 3 is multiplexed, you can have multiple requests, so let's say: connect udp connect ip over the same quick connection, and so when you receive a datagram that applies to one of those you need to be able to tell which request this maps. To oh, is this for this connect udp?

C

Is it for that connect udp, or maybe this connect type, because you could have all three running at the same time on one connection, so the solution is pretty darn simple.

C

uh You put a vine at the start of the payload of the quick datagram frame, and then, after that, we have something that we call the h3 datagram payload, which that will then be used by let's say, connect udp or other things, but we start with an identifier that allows this demultiplexing. So that has been the design kind of pretty much from the start and there hasn't been any question about how to do that, but uh are we done? No, unfortunately, the fact that we have a number there isn't enough.

C

We need to associate that violent with the request. So how do we do that? That is the question that we're trying to answer today in the next 57 minutes. Let's dive right in next slide, please.

C

So some some requirements of like the the specific design that we're going to build, so one we've been calling fo it false start uh to as a nod to tls but conceptually, let's say: you're doing, connect udp and you tell the client sends a connect. Udp request. um It's going to eventually receive a 200 that everything's fine or you know http status code error. um But you know this is 2021 latency. Is we finally realize that latency is important? We shouldn't burn a round trip to then start our first udp packet.

C

So an important property is to send that udp packet alongside the the http request, and if the intermediary decides to reject the request. It just drops that datagram on the floor, no harm no foul, but it means that we don't burn around trip.

C

Another important requirement is intermediaries, so by this I specifically mean http intermediaries. So just a quick note on terminology client is the client. I guess that's not a very helpful term, but it's pretty clear what that one is uh the proxy in connect. Udp is the one that responds to the connect, qdp request and opens up the udp socket. So the proxy is the server http terms. The target is whoever you're trying to connect to.

C

So let's say if I go to proxy.example.org and I ask it to connect udp me to google.com, but google.com is the target um proxy or example already is the proxy and then between the client and the proxy. There can be http intermediaries. So that's what I mean by intermediaries and we need to support those. They make the design a little bit more complicated because they're things that are per-hop properties and things that are end to end.

C

But when I say per let's say when there's an intermediary per hop means between the client and then a terminary, whereas end to end is from the client all the way to the proxy uh again. These aren't too exciting, but we definitely need to support them, because there are many http deployments that use them and then the third requirement here is extensibility um we're going to build, connect, udp we're going to build, connect ip.

C

We already have a lot of interest from members about extensions to these protocols, so we need to make them extensible uh and in a night and in an ideal world it would be really nice if you could extend connect udp by only modifying the client in the proxy like if you could build extensions without having to modify the intermediary each time. That would be like really lower the barrier to entry for extensions, and, I think, is a very important feature all right next slide.

C

Please now I'm going to go through uh a few examples to help illustrate what we mean here. um Could you move the timer a little bit like smaller of it to the right? uh So this is the simplest example where connect udp without any extensions, so you put your udp payload in h3, datagram payload done very simple.

C

You just need a way to associate your uh to use the variant to associate this datagram with your request, because that request has all the context you need, which is the target ipn port, that you need like which socket that you're going to actually shove this udp payload on next slide. Please.

C

Now, let's do the same thing, but let's assume someone wrote a connect2dp timestamp extension, which is that it allows you to convey at what timestamp a packet was received, um and so uh in that case you would have a format that um that has a 64-bit timestamp for the sake of argument followed by the udp payload.

C

Again, that's simple, but the added slight complexity here is: when you receive a datagram, you have to know how you're going to parse it is this just a udp payload, or is this a timestamp for followed by the udp payload and that's going to impact your design decisions later?

C

Because if you have multiple of these formats, it can kind of make things a bit more complex and especially keep this in mind in the context of false start, where, when you send that first packet, you haven't fully negotiated extensions yet so you have to be able to tell if this is an extension, a frame with the extension or sorry a datagram payload with the extension or not um next slide.

C

C

This is an example that it's a bit more complex, but I think we've already had discussion on the list that it would be useful and so I'm going to kind of dive into it a little bit because that informs kind of the kind of things that we want to be able to build here. So let's say you have connect ip and it allows you to um send ip packets. uh We'll talk way more about this in the second half of our meeting today.

C

But let's just assume that we go with this design, um and so you send you set up your tunnel you're, sending ip packets everyone's happy, and then you realize uh I'm sending a lot of packets that all have the same ip header, because it's for this ipad and that's a udp header, because it's for this one, five tuple. It would be great to save some bytes on the wire by compressing that so let's say you build an extension to connect ip, where you say all right.

C

I want to negotiate in the middle of this stream of this tunnel. Let's now start compressing ips. So for this specific ip header, I'm now going to send this uh just the ip payload to you- uh or even you know- maybe just the udp payload or what have you some kind of compression scheme, and you want to be able to have that multiplexed with other ip packets, because there could be. Let's say your majority of traffic is for this compressed flow, but there could be other flow on the side.

C

So, similarly, you need multiple formats to coexist over the same request and uh just one quick point on on design there is we had discussed on the list. You know using separate http requests here um to be able to negotiate these things, but that doesn't work well with intermediaries, because a separate request can be routed to a different backend.

C

So, given this for one request, which is you know this one association from one client all the way to a proxy we're going to need to a have these uh multiple formats coexist and b be able to negotiate new formats on the fly halfway through next slide. Please.

C

So this kind of leads us to slightly updating our requirements list earlier. The first three are the same, but we add these two new requirements that I just mentioned, of having multiple formats multiplexed and um and to negotiate midstream. I think I see a question in the chat from maprg.

D

Sorry this is mia um yeah. I totally understand your point about uh multiplexing multiple formats and you want to change in the middle and say now I want to start compression or whatever, but I'm not sure why you need to um negotiate in the middle of the stream like if you, if you know that those ends or like for the negotiation part, you really want to know if both would support this kind of um compression or whatever, and if you know they support it.

D

And if you know uh what the mapping is, you can negotiate everything at the beginning right, you don't have to do it somewhere in the middle.

C

So in the, uh if you could go back to slide six, please eric uh in this example.

C

As you can see at the beginning, you do not necessarily know what five tuple is going to be you're, just an ip tunnel that, like the fact that you notice later that there's a lot of traffic on the five tuple is not something that you knew at the moment. You created the tunnel. That's why you need to be able to negotiate it halfway through.

D

Okay, so I was, I was having the assumption that for basically every ip flow uh that comes in you basically send an unknown connect request. So you would always just have one ip flow there and then you would actually know you know if it's an ip flow or not.

C

So that that's the fifth bullet on this slide, which is that you can't use separate http requests here, because they can be sent to different backends.

D

No because they would be routed the same way as they would before if you, if you need them to be sent on from the same ip address, you can just tell your proxy to do that right.

C

uh That's not how it would work in our deployments like if you wanted to be sent from an ip that would be owned by a given backend.

D

E

um I I was just going to comment on this topic too, um so myria, like I mean I I definitely like. I was coming from the same mindset too. I think the key tricky thing here is about intermediaries that it like, if you're going to one proxy. Yes, that proxy can definitely do the right thing between multiple requests.

E

But if it's possible to do this deployment where you are going through like two different intermediaries or something those intermediaries may not be aware of everything that you want them to be aware of, and they could end up forwarding on the requests to two different, actual backend servers that do not know about the same request and may not be able to tie these things together, and so, like you know, I'm thinking about you know how this applies to the stuff that we were doing for the quick aware stuff in which we are currently doing multiple requests and that's another case where it would be a lot simpler to work with intermediaries.

E

If you have one request end to end, and then you can do messages, control messages within that single request to kind of add and remove things, it's less work to stitch things together, so essentially think of it as the stream id being the the request id. That's this end to end thing and that's all you need to get through intermediaries and then, with the end to end you can negotiate whatever other ids or other extension properties you want and those are effectively hidden from intermediaries.

E

Then you don't need to worry about having all the intermediaries know about each of these and who to forward them to correctly.

C

Thanks tommy totally agree uh ben schwartz.

F

Could you flip to slide seven.

F

So I think that the the word negotiate here is is possibly uh generating a little confusion. um I think that we're talking at least some of the designs we're talking about here.

F

The payload formats are negotiated once at the top of the request and then instantiated with different parameters mid-stream so, depending on what you think the word negotiate means from. From my perspective, I think of negotiation as the thing that happens uh at the beginning, in the request and response.

C

Okay, so maybe negotiation was not the the right word. I apologize. What I meant to say was this in this connect ip example to associate. um You know the these semantics. Let's say the the members of this five tuple with uh a format kind of in the middle, so maybe negotiating that's our word but exchanging this information and I think in further slides I might use the word negotiation as well. So please think of it. That's that's not that's what I mean not necessarily with that other definition.

C

So, sorry for using unclear terminology here all right uh next slide, please cool! So now that we've kind of landed on a rough sense of what we're trying to build and some requirements, um let's go into uh the design discussion. So I've split this up into a bunch of binary questions on ways.

C

We can solve a lot of these problems and I on a lot of these, I personally have opinions, but I'm not tied to any of them like I care a lot about the requirements and what the system can do, but for a lot of these, let's see where we can go as you may notice. I have posted a picture of a glass bike shed and please don't go and try to paint the glass bike shed. That is a bad idea.

C

So what I mean by that here is: let's really focus on the 10 000 foot very high level, architectural design possibilities for a lot of these. There will be many details and nuances to get right, um but we don't need to get into these today. I think if we today, we only have 44 minutes left.

C

If we manage to answer the top level like architectural points, that would be incredibly helpful and then we can, you know, on the list or at a next interim or sometime, very soon, really get into the meat of how we want to encode these bits, because that is also very important, but let's first get the architecture right and then get all the details. Perfect next slide. Please.

C

um All right, so this was an idea that was proposed by ben schwartz recently, and I like it so one uh you know intentionally at the beginning of this presentation. I was very vague about using the word barrant um like, for there is a number at the start of the quick datagram frame payload um that uh that number in the current drafts is called the flow id and the flow id. So if you see on the it's on the left column here, uh it is a connection-wide concept.

C

That is pro so again. It applies to one quick connection, not to an end-to-end request and it it it solves two per or handles two serves two purposes. One is to map from this datagram to a request, and the other is to additionally map inside that request to what I'm calling in request context. So, for example, in this ip compression it'd be 2.5 tuple, so you have one flow id and it gives you all this information.

C

um The downside of that design is that it's a bit more complex for intermediaries, because, since this flow id is a perhaps concept, intramurals need to do translation on both hops um and so ben proposed a two-layer design where, at the start of the datagram frame payload, you don't put one var and you put two and one is the stream id, and that gives you an association with the um http request.

C

So the stream id is already a per hop construct in quick and so intermediaries know how to handle this, and you would pretty much just reuse that and give you a direct mapping and then after and so that gives you a mapping from the datagram to the request. And then you add a second number potentially encoded as a warrant. um That is, we also call flow id.

C

We might want to pick a different name, but let's just call it the flow id for now and that one is actually end to end and that is like tied to a request and it maps inside the request to the specific context.

C

So let's say like this: you know five tuple compression that we were saying, um and so the downside here is that it. It sends one more warrant on the wire which all right in practice will often mean we waste one bite, not great, but also not the end of the world.

C

But it gives you a much cleaner separation where, from an intermediary perspective, you have to rewrite the stream id, which you already do when you're forwarding requests, but the flighty you just leave it as is, and you don't care um and when you're doing you know negotiation, you just send that seemingly back and forth. So I want to hear your folks thoughts on these two designs here.

C

I'm I'm personally leaning towards the the two-layer design, because I think the the cost of one bite is is worth it for something that is cleaner and simpler for intermediaries. But uh I I would love to you know, get some ideally reach some consensus in the room that we would. You know, confirm on the list about picking one of those two designs.

C

So please step up to the microphone and tell us what you.

G

G

So this is perhaps just me trying to understand this uh better. So I'll ask questions uh for that. First, the the flow id sounds more. Like a request id to me. I mean it is per request. After all, so it seems like it is really just a request id. Is it not so.

C

No, uh the flow idea is inside. So sorry there is a namespace of flow id for each request. I guess so per request was, in the other sense of per request. That's there. That was not the right word. I guess sorry uh like a a given connect. Udp request has a set of flow ids.

C

I see so conceptually.

A

C

Stream id is what tells you which connect udp request and then inside the connect, udp request, you would have flow id 0, which means just this uh udp payload, so id1 means.

H

C

481 means um timestamps uh timestamps. Thank you. Sorry. I heard some really weird notes threw me off of course there and then you know so then you and then you can negotiate them midstream to have like uh meanings with additional things. Does that make sense? Jonah.

G

It does I mean what you're saying. Is that it's really it's really context id it's what it sounds like more and more to me like, yes,.

C

That is actually a good. That is a good name. Yes, uh I like that, because.

G

Flow is abused all over the place. I don't want flow, um but it sounds like it's specific to a request and to a context. So, okay, that helps me understand it better and the stream id here is what flow id used to be.

I

uh Yes, correct context: yeah.

G

Minus, oh yes, flow.

C

Id used to be the sum of both and now we've kind of split it in half one is the stream id which is you know the literally the quick stream id and the other is the. Is it exactly the quick stream lady?

C

So in ben's proposal it was the quick stream id divided by four, because all requests are, you know: zero module four, but we don't need to like figure out the encoding today.

I

That's okay, okay, I'll! Let the others go and think about this a bit more. Thank you. Thank you. I think next is tommy. Yep.

E

So I I also like you think that we kind of need to go with the two-layer design um after ietf 110. We had bounced back and forth the number of ideas and like independently. This is kind of where I ended up as well. um I think largely, as you were saying it has to do with the fact that we have intermediaries like if intermediaries did not exist, and we did not need to worry about them.

E

Then I think the single layer design would be fine, but really, I I think, of the stream id purely as a convenience for intermediaries and management of where to route this particular frame, and then all the other stuff that you know at least I had thought of for flow id really.

E

Is this context- and you know even last time you know we're having these arguments about what does the flow id mean um and I think some people viewed it as it's just for routing like a stream id and some people were saying like no, it has meaning to what's this request splitting it up, I think just makes it a lot clearer and then it's very clear that sometimes you will have these degenerate cases where you don't need any extra flows, you're just always using the zero flow id or the context id, because it's a very basic thing and that's okay.

B

um So yeah, let's do the two layers design all right. Thanks, tommy uh maria.

D

Yeah, I also think this that two-layer design is is cleaner and and therefore nicer. um I can also agree that the flow idea is very confusing. uh I would even propose to not call it context id but just context, because I think we should still um discuss what the what the semantics of the context idea is. So you could also have an extension that just defines that, like whatever these two bits of the context should be the easy end bits right.

D

um So it's basically at the moment it's just a field and then an extension could kind of assign any kind of semantics to the field and that's what we want. Yeah.

C

So thanks mary, well, the the reason it's an idea is that specifically, it would be encoded as let's say, a variant because quick likes variants and that would map to a context. That could mean more things. So it could mean ecn, bits and other things. uh And then you could. You know conceptually just choose to encode the ecn bits in there, but it just stays conceptually an identifier, um but that points at something.

D

Yeah, so for me the difference is that you know um an extension could rather define a semantics about how to use this context. While, um if you just have an identifier, then, basically for every request, you, you would use a different set of identifiers to mean the same thing um rather than defining semantics for a field, but this is something we can argue about later. I think.

C

Yeah that makes sense thanks uh and then in the uh in the chat, because I'm going in order klein mentions that, uh like rc 8724, which is static, contact center compression has kind of similarly a concept of identifier that maps to a compression context. So yeah, that's that's how it would. uh It is similar an idea to what I'm just gonna call it context id from here on out, because I really like that name. uh But we can pick the name later. Kazoo.

J

So I also prefer the two layer design. The other benefit is that it decides to design string chunks. So it removes the headache of separate having separate mechanisms for identifying context when we use screen checks, cool.

C

Thanks: okay uh matt in the chat prefers context overflow, great uh luke, curley,.

H

Hello, uh so um I think my only thing is uh well. First off I really like the stream id mapping. It especially makes it uh great when you receive a datagram uh before the connect request, and you can tell oh hey, there's gonna be a connect request coming you can you can buffer it?

H

um The only thing is the the context id seems it's a little uh application or protocol specific, like I can totally imagine a case where I don't want to send a zero on every packet like it feels like it could be negotiated on the connect request. What the you know, what the first byte is going to be.

C

So that part, we uh have a further slide to discuss so hold that thought and we'll get back to it. That's good! um Thank you, uh then, uh alex.

K

um I also want to say that I think the two layer design uh makes a lot of sense, and I, however, wanted to say that, while I agree that flow id is not a great name, I think context is in many ways worse, because what is a context. um So I would prefer that we not use that name.

K

um I do, however, feel pretty strongly, but it should be an id and extensions should not be attempting to use it as a bit field and try to assign different semantics to the identifier that should be done in the payload that they themselves are using from this id that they have allocated.

C

All right, thanks alex um then lucas has another clever name for it, but let's not try to bike shed the name today. uh So I see I see, martin duke in the queue.

L

Yes, hi david, uh uh I have a clarifying question and uh uh neither a comment or a question depending on how it goes, um first of all, so to be clear, the full id or context whatever we're gonna call. It is that globally unique can two streams.

A

L

The same flow id or what's the relationship between the two things.

C

So the the namespace would be specific to a request, so two requests- or in other words two streams, could reuse the same number for different meanings. The uh the number would be tied to like the namespace would be per like tied to a request.

L

Okay, well, that's good that will probably shorten the length of that variant. Then that's good. So the other question is about ecn. I mean, I think you you. I know people don't like you seeing an example, but I care deeply about whether or not we get that in and the the the flow id is. um I mean if that's, if that's end to end and like the ecn, signaling needs to be per um per hop right. So how does that? How do those interact or am I am I not understanding the problem correctly.

C

I think you're, not understanding you see, we're sorry, I'm confused the ecn and my understanding and I have a slight draft there. Ecn is a property of a packet, it's not a property of a hop or end to end. It is a property of a udp packet that then gets applied to a datagram.

C

So then it is a property if you of it would be a flow, slash context id. That would be a way to encode that this, this udp payload. How do you see it? But um we I don't want to get too much into the discussion of ecn, because there are multiple ways to solve this and we don't necessarily agree on that.

L

Well right, but but I guess what I'm saying is: if it's I mean if, if flow ids are thought of as an end to end property like the packets are destroyed reconstituted at every at every proxy hop right so that ultimately, no.

C

No, they are not hold on hold on packets are not reconstituted ever so. At every intermediary, like packets, are set.

L

Oh yeah yeah, yeah, you're, right yeah. I got it yeah yeah yeah. I got you I'm sorry, yes, because actually I have this wrong. Thank you.

C

Cool thanks, uh jana's back.

G

Yeah thanks uh david, so I um I think that if, if I understand this correctly, I think that the two layer design makes a lot of sense and I don't think of it as tool. I guess it is two layers in some sense, but it's not because they're orthogonal right.

G

So the way I understand this now is that your streams are, I think, tommy or somebody said this earlier, that stream ids are really for routing and- and I appreciate that intermediaries need to understand that intermediates might change it, even as they go from one hot to another hop, but the context id is really going end to end.

G

So in that sense it is it is it's it's it's two layers, but at the same time the purpose is completely different um and uh I don't, but I think, given that the two layer design seems to make sense to me, I do have one question on on uh and you can point this to later. Basically, how are the semantics of the context id defined? Are they and you said that they defined that.

M

Particular stream.

G

Okay, good enough, otherwise I'm I think I like this design.

G

The reason I'm asking about the context of how the context id is defined is because it sort of makes me I'm trying to understand if context id is important or useful, but we'll get there. Yes,.

C

uh Cool thanks, uh then uh tommy says plus one on this being an id idea, not a bit field because it avoids conflict better. I do agree with that uh and folks talking about the name cool all right, we've drained the queue. The sense I'm getting is that there's in the room, overwhelming support for the two-layer design. So we can confirm that on the list later next slide. Please.

C

Now another design question the flow, slash context id. Is it unidirectional or bi-directional? And so let me explain what I mean by this in the current drafts.

C

uh The the concept is bi-directional in the sense that once one endpoint says this context, id means this, then you can send in both directions and another way you could design this, which some of the proposals had is something unidirectional which any endpoint like where you end up having to request two namespaces one in the client to proxy direction, one in the proxy to client direction that are separate. That might end up being the same but they're separate.

C

And then you kind of make a declaration unilaterally, and you say this id for me is worth it means this and you don't negotiate it uh and whereas, in the bi-directional sense you kind of say I'd like this idea to mean this. The other side says: okay, this id means this and then you can use it and that also still allows false start in the same way that um you know the regular connected, ep mode does, and I see questions so. I'm gonna.

N

Lucas I'll be serious for a change. Sorry. um So like I, it's not a question more than a comment, so I do apologize, but the I think seeing the example of like ip compression that you presented in the recent proposals um shows that the bi-directional design just breaks down because well, for example, the client is saying I'm gonna, I'm gonna, send you this this thing with some compressed ips and I want you to uncompress it and send that forward.

N

That doesn't necessarily mean that the packets coming back want to be compressed in the same way and therefore, if that's not true, then the bi-directional thing just doesn't make much sense to me and therefore the unidirectional design is more attractive because you can create a two-way, two-way, logical um relationship without this kind of pretend bi-directional thing that may or may not be true.

C

So the that is true. The the one downside that I noticed in conversation this morning was uh the the problem with uni well with uni directional. Is that it's it's not negotiated like you, you don't get a chance to accept or reject uh a declare, a declaration from your peer, and that could be a dos vector. We don't want to add anything in the protocol that lets an end point create incremental memory use on the pier, because that could be bad, and so uh what you're saying is, I think, they're and you're right.

C

There are use cases where the bi-directional will only be used in one direction, and you know: okay, we've wait like wasted a little bit. You know it's a 62-bit space, so it's not a huge deal. It means in some edge cases we'll use a slightly larger variant, but I don't see that as too big of a problem, and I think that there are some extensions that, like the idea of being able to um say no, I reject this um uh this.

C

My uh sorry, this negotiation might be useful and that's why I'm kind of personally leaning towards that, but again both of those work. If we find a way to make them work.

N

Just to respond, I think I think you can achieve what you just said without having to couple it to being bidirectional and just have like separate a tangential that the the registration, overflow or whatever you want to call it, um and the rejection of it is different than a yeah. I'm gonna set something up in two ways. This is how quick streams work that you can.

N

uh If the peer wants to to create a unidirectional stream to you, you are still able to shut that stream down um that's kind of how things work today and I don't see much difficulty in translating that into into a mask design, myself yeah.

C

Okay, so what you're you're saying is that we could make it unidirectional, but with a negotiation step that that makes sense uh is absolutely uh okay. That is the third option here. um I'm gonna take quite like other questions and comments and see what folks think about that that I totally see that as a viable third option. uh Ecker.

C

Party, um yes, I'm not so I think, like pi directional is clearly simpler. It matches the sort of implied semantics here, which is that the, which is that the client initiates connections and that it's in charge that the proxy takes the client's instructions um just to head off. Like previous uh later suggestions, um you know, yes, we might want a little incoming connections, but those are the opposite and the server should and the proxy should be saying, here's a new connection.

C

The client should have pretty rejected, and so we should, if we ever want to do like the thing christian wants to do, you can run a server that should be. That should be. That should be simulated as if it were the um the pure taking the the proxy taking. What is currently the client poll for that particular bit um so just to add a clarification on that specific point uh in the bi-directional design. uh The way you solve this is by having you know like we do in the rest of quick.

C

The even numbers are client initiated. The odd numbers are server initiated, so this works in either direction right. No, I don't. I understand I understand what you're saying but um uh well okay, so I guess I guess I'm not really.

C

What does a server initiative flow mean? What are the semantics or initiative flow? uh So let's say, for example, that in the ip compression example, where.

M

C

So, very quickly the request is client initiated. The client says I want to set up a vpn tunnel to you uh and the server you know accepts that and they're happily sending ip packets back and forth, and then the server can say: hey, I'm realizing that I'm sending a lot of packets with the same five tuple to this client. Let me tell the client I would like to compress these now and that's a server initiated negotiation of a flow id.

C

So then I guess I don't I then I don't understand what the cementite difference is between these two proposed um potential designs, because in either case the server can initiate arbitrary number of things and tell you and try to force them on you, and so you and so either you either.

C

You either allow this to create an arbitrary amount of state or you have a rejection mechanism, but I understand why, with the differences between these two settings, so so the the main question is whether we allow a rejection mechanism or not uh the in the draft.

C

The way the bi-directional one was set up was that one side sent something and the other side kind of echoes it to signal that it likes it, um but we haven't kind of nailed down all the semantics, so conceptually the the fact that it's true directional bi-directional ends up being very much the same thing. The only important thing that we need to figure out is whether there's a way to reject it or not. I think yeah. I guess I'm also like sure.

C

Well, I mean, if you think, it's a does factor allow the peer to like have infinite state. Then like then you have to reject it. So I mean, like you, know, um yeah. No, no certainly I mean it's really going to happen at the phone, but um the um I guess, I'm sort of like I'm getting a little worried about this conflation of flow to uh to two compression state. um um That seems like a really kind of an odd um an odd design choice.

C

I don't think it worked out that well in turn, for instance, um you know uh um I mean so like you know, so so what happens? If you have, you know partial partial compression right, um you know it's. um You know, here's a here, here's a new um you know, uh so I mean here's like a dumb example. But, like you know, here's like a new connection id, but um you know I'm going to compress the uh I'm going to compress the the packet number for some reason right um um and I've got.

C

I've got some express the packet numbers um or I mean um I guess I just think like I'm just like.

C

I think every time we try to like tag some piece of state with an integer. That's like that's, probably like a fail um and- and certainly these are- these are not conceptually extreme. So I think compressions aren't quite different, so I guess I'm not. The motivating example here for like having this sort of like initiation of both directions is compression. Then I might not present any of that.

C

uh I mean there. There are a few other examples and uh maybe go and grab the slides there or you know, watch the video at the end. But sorry, I'm not going to repeat the whole thing. Okay! Well, I guess I'm unable to come down on one design. So I'm not sure I need either of these things in the way.

F

C

Thank you, and next I have tommy in the queue. Oh sorry, sorry, no ben ben was after ecker.

F

uh So yes, bidirectional and unidirectional both have essentially the same dos vector problems. I think that's orthogonal. uh I do think that this is a. This is a great time to talk about context instead of flow, and I do think that ecker's analysis is is um on the facts. Correct like this is a um this is essentially a compression context.

F

uh We are in almost every case talking about removing information from the payload that is repeated or constant across payloads.

C

F

Think that's true, I don't think that's true.

C

That is a motivating example and take the timestamp extension is the opposite where this flow id slash context id would say this is how you parse this packet and there's additional information at the start. So it tells you how to parse this packet. It could be a decompressor, it could be additional information, it could be all sorts of things.

F

Sure in principle, though, I think that we can still represent it that way. Essentially all of these cases that add information, we could say well, there's some there's some maximum state that actually conveys all the information explicitly and then the various context. Ids are different ways of representing subsets, where some of that information is not relevant.

F

So I think that that it is is still essentially correct in all the in all the cases that I've seen so far to describe this as a compression context, I think that's valuable. um I think that we're that the overheads we're talking about are high enough, that the mechanisms we're talking about are simple enough, that it's worth it part of the reason.

F

I think it's simple enough is that I don't think we need rejection because again, these are all just compression mechanisms, and so the peers can agree at the beginning what compression mechanisms they support and then, as long as they send each other well-formed compression context descriptions. They should be able to compress without needing to reject.

C

Well, what about the dos vector if I go, and I send you two to the 60- I want to compress this ipv6 address. I want to compress that ipv6 address like you should have a way to say: okay, no, no! Stop that is you're, being unreasonable.

F

uh Yes, that's the same as http, 2 and and possibly quick.

C

uh No because those have flow control mechanisms- and I would really prefer not to build flow control into this because that's hard.

F

So http 2 has a an explicit configuration for maximum number of of live requests or streams, and if we really think it's necessary, we could build in a similar limit. That's that's negotiated here, or we could just say be reasonable. Don't don't go nuts.

C

Can I assess a clarifying point because I think I'm getting lost in this dust thing like, as I understand it, if I'm going to offer a new indicator that says from now on, flo 32 means it's got like this ip address or this other compression point. I can't start transmitting on that thing until I've received some acknowledgement of that. That was delivered right.

L

C

Can you can and it's it's false start? um We discussed that earlier conceptually. The idea is you send with this flow id and if the the other side rejects it and sees the flow id has rejected it just drops it on the floor or sees a fly that is unknown. Oh yes, if you're willing to take like four rtts of like a data loss situation, doesn't work out. Sure, okay, um that's like I like! I don't know, I'm not very persuaded it's gonna work. But, okay, I understand your point all right.

C

um I think we're gonna kind of drain the queue up to the point where it's cut a bit quicker. So alan. If you could make it a bit quick, I it sounds.

G

Like we're not reaching.

C

E

C

Slide and I want to go, can I.

E

Get to the next one.

C

E

I skipped in the queue.

C

Oh sorry, sorry tommy, I apologize yep. Tell me you're next.

E

Great, um so I I definitely agree that the bi-directional versus unidirectional is separate from whether or not we have acceptance or acknowledgement of the of the request that initiates flow id, and I I think the bidirectional unidirectional is a total bike shed. um I think I agree with ecker that it's nice to have bi-directional. That seems to be more consistent with a lot of things that we have. I could live with unidirectional though, but yeah I'll put a vote in for bi-directional.

E

I very much disagree with ben.

E

About the fact that you know all of the extensions are just compression contexts and that we would never need to have any ability to reject or negotiate um even if I think, a dos attack is one way to think of it in terms of increasing state, but there are also cases where I may very simply be requesting a given context to say that hey I'm doing this to map for this local ip address on my ip tunnel or I'm trying to do this and the proxy can just say you know you have an error like this.

E

All the packets you're going to send on this are going to be dropped, because the address that you're trying to send from that you're binding this to for compression you're compressing away, is not one we assigned or let you use for this tunnel or hey. You just added two different contacts for the exact same um ecn marker or something like this essentially say you sent nonsense, um and this is totally different from http, because in http requests we have a status.

E

We can send back that you can send an error to say no go away and similarly with quick, we can say: stop sending you can reset a stream having no mechanism for the pier to say, hey, you know all those packets you're sending to me, I'm dropping them on the floor and I don't want any of them.

E

If we don't build any way to do that, then we are losing something that we have today when we have a kind of a unique request per flow, and I think it just makes if we don't have a way to negotiate it. It essentially only lets you do it for things that you have pre-negotiated and I think we would have to kind of pre-approve everything in the actual header request response, and then you wouldn't have any dynamic nature.

E

You wouldn't be able to make sure that future changes to what you're wanting to forward or tunnel um are going to be associated to the right and to end context through intermediaries. So I think we should split them up and it's I don't see a way that we can get away without negotiation.

O

Okay, thanks tommy uh alan uh yeah, so uh this question's, I think, related to unidirectional versus bi-directional it, but if it's not feel free to move on, which is what is the lifetime?

O

uh How long am I allowed to send datagrams on a particular stream id flow id pair, particularly, am I allowed to send datagrams on that stream id after I'm no longer allowed to send stream frames on that stream? Id like after I've sent the thin bit um and how does that impact bidirectional versus you, directionality.

C

So those are separate now that we've agreed on the like two layer or two variant design, the stream id bit that's tied to the stream. So we haven't spelled this out, but my view is the lifetime would be equal to the lifetime of the stream. So once that stream has been thinned or reset, you're no longer allowed to send datagrams with that stream id the flow id is inside of a given stream, and so that would have like again the lifetime tied to the stream.

O

Okay, I can think of an example where I might want to well. I can think of an example where I wanted to receive datagrams like where I sent datagrams, and then I sent the fin on the stream, but the fin arrived first and how will the receiver handle those datagrams and again if this is, if you want to move on and handle this later, but I think it's something that I just want to understand. That's.

C

A that's a good point I haven't thought of that. Can I ask you to file an issue because I think we should get to the bottom of that yeah for sure cool thanks, kazoom.

J

Oh regarding and directionality, I think I kind of wonder if we can simply support both, because we have similar discussions for quick streams and in spotting both because the dictionary only approach turned out to have many pitfalls. And I prefer doing that because we have 62-bit space and you know we can, with some numbers.

C

That is also an option all right. Thank you cool, so um the sense I'm getting on this one is, we don't have clear consensus. Definitely we definitely did so we're going to keep discussing this this one on the list, but let's try to answer some other separate questions. Next slide, please all right: how do we negotiate these um so at the in the current drafts?

C

This is done using the datagram flow id header, where at the start of your request, you say I want to use this flow id um and you can send a list and in that list you use the parameters to explain the semantics in the formats uh the the problem there is.

C

It prevents you from creating an uh from negotiating this midstream like we talked about, which is kind of sad, because we could build some cool things with that feature uh and also the uh the format of this list. uh People didn't really love that um so another option that we looked at is to instead use a register message that you send kind of midstream, um we'll talk in further slides. How that message is encoded. It could be an http frame.

C

It could be something else, that's in further slides, but for now the important question is: do we want to enable sending this midstream? I think it's personally very useful, and it's not that complex to add uh what are thoughts on this.

C

Because the sense on the list is I've, no one was happy with the header and so far I've seen people that were happy with the the message. So maybe in the interest of time, if you uh let's keep it short but yeah, let me know what you think alex.

K

I explicitly support the message because I think that there are useful uh capabilities with doing things. Midstream.

C

Cool thank you edgar and just to confirm, okay, and so this this, but this is the same issues about timing as previously. Maybe you have to worry about um about about risk conditions between the fluid, but in this this message and the actual flow flow messages right.

C

uh So the they're tied questions. If we have a message, then we need to answer the question of. Is there a way to uh accept, reject this message or not, which was the question the previous slide, but we haven't gotten to bottom of that, but that is still something. We're gonna need to answer right.

C

um Okay and you wouldn't allow me to rename them. I imagine right, um given that we have a 62-bit space, I would expect to not reuse, because we had discussion about reusing last uh last, atf and folks were saying: let's not reuse, um okay! Well, I think provisionally. I prefer register okay. Thank you. uh Kazuo.

J

I'm not sure if I follow the benefits of registered floor id message design, because if I recall correctly, we just agreed to use two layer designs so that intermediaries can be ignorant of what the contexts are. But now it seems to me that we are the message. Design is adding for each intermediary to understand these extensions.

C

Oh no, so that that's a very good question- and I should have explained this- I apologize uh so the message would flow through the intermediary. The integrity would only see like the stream id and it would not touch anything inside. It would treat everything inside, including you know, the flow ids or context id or whatever, or the you know way to encode what the format is.

C

All that would be completely opaque to the intermediary that would just copy bytes on on one side to the other, in the same way that it should be three data frames or the contents are generally opaque to intermediaries. Some of the time.

J

Thank you for the clarification, so I think some of my concerns have been resolved, though I'm not sure if any two ways of exchanging end-to-end messages from being the datagram, uh I mean the I mean those things on the data frames being the stream chunk of some other things.

C

So how we encode this is the next slide.

O

uh Alan yeah, I'm guess I'm wondering, is it also given that if this passes through an intermediary that they basically have to forward it can't modify it? Is it also possible for two endpoints to just pre-agree that flow id has a certain meaning without sending a dynamic registration of that on the wire?

O

So you wouldn't be able to do on the fly compression that way that yeah, that's true, but I mean there's and I think we have there's a couple of different examples.

O

We've given for how flow ids can be used, one of them is compression, which you know obviously has to be dynamic, but another use for it that you've, given in the time stamp example, is really just about datagram type, and that is something which could be statically negotiated and just say when I I am intending to use flow ids to differentiate different types of datagrams on the same stream and when I send type 0, it's got a stamp and when I send type one it doesn't or or whatever, and then I don't need.

O

Yes, that message is dynamic.

C

So so you're totally right that not everyone, you needs the dynamic property. But if you have the dynamic property you can implement static with dynamic, but not vice versa. I.

O

Guess the reason I'm asking I mean, since the intermediaries have to ignore them anyway, maybe there's no way to stop me from doing this, but it also gets around some of the problems we're talking about with uh what happens if this message doesn't make it through? When can I start sending things with a given identifier, if it's sort of unilaterally defined by my extension that I'm going to have the flow ids? Have this particular semantic, then I don't have to worry about running into those issues, so you, I think.

C

You need these issues, no matter what, if you want false start as in even you know, if you want to be able to send datagrams before you've received the http response to your connect, udp request you're going to have to handle this problem, no matter what I think this problem is orthogonal from the dynamic versus static, because even if you do static at the beginning, during the request response, you still have this problem, so we need to solve it, no matter what well.

O

I think you end up with two layers of the problem like one of them is like. Are you did you get the data ground before.

G

O

Even got the headers and another one is uh halfway through the stream. I'm now decide. I want to start sending you something I haven't sent you before and now I have to worry about it all over again that you're going. Maybe you haven't.

C

O

Register message, but it's not all over again, you solve the problem once and for all right.

C

If you need to solve it for one you solve it, for both then you're done and the solution is very simple here you just if you see a context id that you don't know you either drop it on the floor or you buffer it with you know being very careful to not allow infinite buffering.

C

You know that's how you do false like things like false start right, that's simple: it works and it's not really much of a concern.

O

Okay, I guess I'll go back to my original question, which is: are these mess? Is register flow, id message required or is it optional if I, if endpoints already know so that is a.

C

uh uh That's actually a separate slide where uh I think there are use cases where folks don't need this, and so it's talking about how we make it optional is is in a cutting slide. So, let's, let's put a pin in that for now. Okay, uh then uh tommy says plus one to the message design. Then mike.

P

um So I'll just point out in terms of history here the priority update that http is working on decided to use both headers and frames for something like this using a header so that you get the information with the request and you don't have to worry so much about timing but then using a frame to update it later.

P

It's also worth noting that this is intended to be end to end, but if you use a frame for this, that is hot by hop from an http standpoint, so you'd have to mandate that intermediaries forward it correct.

C

Cool, thank you. So this one, I wouldn't say, is as clear-cut as our first one, but I'm kind of getting a sense uh that some folk more folks are leaning towards message, but we definitely need to confirm it on the list because that it's not absolutely clear uh next slide, please, which all right, let's see, we have a minute left I'll, just bring that one and we'll skip the rest of the slides.

C

It was on the topic of uh things being optional, um so their cases take like web transport, for example, that, in my understanding, don't need. You know the second layer of context, id or flow id and um don't want to. You know, spend that extra bite on the wire of when they don't need it, and one proposal from lucas on the list this morning was to.

C

If we go with the register message, you can add a separate message which, instead of registering one flow id, just says: okay for this entire stream, there will not be any flow ids like boom. The whole thing is set um that actually works nicely and it works well with false start as well. So I think that gives us kind of the best of both worlds, where methods um and or other kinds of extensions that don't need this don't have to use it, but it's built in such a way that allows us the accessibility.

C

So I'm pretty happy with this, and it doesn't add too much complexity. Do folks, have thoughts and keep them quick, because we're pretty much 30 seconds.

C

Oh, you know what we're we're out of time and the chairs are going to be grumpy at me. I think we're going to have to take this to the list.

A

C

Of order go ahead.

A

Chris, before we yeah so we're just about at time for this, it seems like we're making really good progress, and this is blocking some of our other progress on the rest of connect udp. So we do have the option to drop the rest of our as time permits things. If folks feel that this is valuable, and we can add that time back into here- that's the meaning of his time permits.

C

Also, I mean this is the number one highest priority working up item so buy shorter. That makes sense to me.

A

I'll leave it up to the chairs excellent, all right, 20, more minutes go.

C

All right, let's go, um then uh ben schwartz was first in the queue.

F

Hey uh I, I don't think this topic is actually that high priority, um like connect udp as a whole sure like this specific message, not so much, but since we're talking about it, uh I I don't think this is necessary um if you're in a way, if you're in a web transport, you know you don't and apparently, if the design doesn't call for flow ids, then you know you don't need flow ids and we don't need a frame to talk about it. You at both sides already know if you're in connect, udp, we've.

G

F

We want flow ids, I don't think we need the ability to drop them for the sake of trying to save one bite. So I think that it's implicit, but if you believe.

G

F

It's not implicit, then I still think a message is the wrong way to do this, because it greatly complicates the false start, reordering behavior. It means.

C

In what way does it complicate it.

F

If you get a datagram on a request before you've received a registration message, you don't know whether you're in single flow or multi-flow, so you can't even look at the flow id yet so this means that instead.

C

Of having but hold on hold on the important property of false start and the only way I can see to implement it is, if you get a message and you, like you, had a datagram frame. Sorry and you haven't received any register message.

C

You can't parse it no matter what there's no point in parsing the flow id, because if even if you had access to the flow id, you wouldn't know what to do with it. So, as until you've received a single register, any registered message, you're gonna have to buffer or drop these, and the moment you've received one boom. You know in which mode you're on yes.

F

Make this more complex, it adds states to your state machine. It means that instead of I get a packet that came in, I look at the. I look at the context id to find out what to do with it. I see if I have a matching context id and then, if I do, I go otherwise I buffer. Instead, I have to have an additional check and an additional asynchronous state where, before I even attempt to look at the flow id, I first have to wait until I've figured out whether I'm in the flow id state.

F

I have another set of interacting asynchronous events that to to juggle um it's. I would for that reason. I'd say if we need to. um If we really need this, then it should go in an http header so that it's uh finalized before we start receiving data.

C

That is also an option. uh Thank you. uh Jonah.

G

uh Thanks david, I I was gonna say I think I'm gonna try and parse and respond to what ben said, because I still need to think about that. But I think that you need something. I think you pointed out that you need some sort of registration mechanism. Otherwise the implicit one makes the timing difficult. I don't know how to establish synchronization if you don't have. If you have an implicit one, so you need something.

G

Maybe it's a header, maybe it's this, but you need something to say that I'm going to I'm not going to have flow ids in in subsequent messages, so yeah. uh I think.

I

G

One to this, I I don't want to speak to headers, because I I think the whole point of this was to keep this end to end. um It seems like having this message would be the simplest thing to do.

C

Cool thanks jonah uh all right. Sorry, let me look at the queue there was a bunch of plus ones which aren't plus queues uh eckers.

I

C

Yeah, so I'm not sure what I think about this particular thing, but I'm getting the impression we don't actually have a good handle on false start, which your people are begging you to rename um as we might want. um um So I think perhaps like we're fleshing out in some detail. What like really. This means, um as I pointed out in the chat there. Are there really two semantics right?

C

One is um I've sent a setup packet and if I said a packet fails then like these packets will be irrelevant um and that's like, if I say, connect to this like remote location right, um if, like I see, if I send you a connect request to an endowed ip address, like nothing is going to salvage that in the mirror packets.

C

I said this is going to flow and should be thrown away, and the other is a soft state, and I'm saying like set up this kind of compression context and then, if that that packet gets lost then actually like this is somewhat different and because those packs will then should be admitted by either either by the end or by the intermediate point. And so those are conceptually um somewhat different um and we might- and it might have different.

C

It might in fact have different requirements in terms of buffering in terms of um uh in term buffering versus transmission. So um I I guess, I think it's absolutely probably helpful to try to break out what people really expect or whether those people buffer, um because another valid implementation, especially in the one in the in the version which is um which is connect to the other side, um would be, um would be merely to drop the packets right and and count on the encounter or gender retransmit, um which would actually.

M

Have some of the right.

C

Rate control, behaviors, yeah, so uh the way I think about it- and you know tell me if this doesn't make sense- is I really think those reduce to the same problem. So let me try to say some more uh conceptually. The idea here is you're doing some kind of negotiation step, and you know this applies to far starting tls by the way where you say. Okay, I want to do this. You know this being set up a trs connection to you uh and then you say: okay, let me just send data before.

C

I know whether you're, okay with that or or not, um and that you know if you're okay boom, we've saved time everyone's happy. If you're, not okay, this data went into a black hole. It's dead right, like that's, that's kind of the fundamental property. If that and then- and you get some kind of notification that that that happened um conceptually, then you have a decision to make uh about retrying and the retry could be at any layer in the stack.

C

Let's say you know: if your browser is getting like the the falstar didn't work at tls, you could imagine retrying your entire http get from like all the way at the top, or in this case let's say if you're doing you know, connect udp and that didn't work, maybe you're gonna, retry and retry.

C

Like your quick request over you're going to say, oh quick, isn't working, I'm going to try sheet p2 instead, and so I really equate all these to the same thing, which is just a I'm optimistically, sending something knowing that you might decide to drop it on the floor and as an optimization I might trigger on that notification to retry immediately, but in practice you know we're talking about datagram frames here that can be lost anyway, and so, if you know something gets black holes, the world doesn't, and we already have to handle that.

C

So I think all of like your two separate cases really are the same. One in my mind, am I missing something? Well, I think only if you think layers to protocol layers doesn't matter. um You know um which I do um so. um I mean think like which layer of things happen that matters, and so in one of these cases the the the issue is handleable at the mask layer and and other other layers is not um in particular.

C

If you know, if I try, if I ask you to bind to an invalid ip address, um you know I ask you to um or once forbidden by policy, then that that has to report an error to the month to the consumer or mask and it has to handle it, whereas in the, um whereas, if what happens is the packets?

C

If what happens I ask for um you know, I say please initially new compression context and you're like sorry, I don't have I'm going to have 30 and you've already done 30. um and that has to be handled at the mask layer. It's all level right, um um so I think I think I think something. I think that, like I mean yes so sure at some level, yes, like, I may get bored and hit the real head butt on my browser, I think, but I mean like.

C

I think this I think delaying points do matter, but I guess I'm just. I think I'm just generally saying this. You keep saying buffering on the receiver's side, but like um is that, but I mean like, as I say, is, is are are: is it perfectly valid implementation to simply discard anything which you don't have on a parse and if that's true, then it should be optimizing for buffering at all.

C

uh So, first off. Yes, uh if you get something that you don't know the semantics of and you drop it on the floor instead of buffering it, that is perfectly legal. The buffering is optimization uh in case you get uh reordering so take, for example, in quick. We do this for zrtt.

C

If you get zero rtt before the client, hello, you can drop it on the floor or you can decide to buffer it in hopes of getting the the clientele there. Both work one is faster than the other, but cost more memory. That's what we do in our implementation of quick, for example, uh and I'm kind of really envisioning the same property here sure I think that that might be helpful like uh to to document more clearly. I think, and so it's a concrete example of what ben was saying right.

C

um You know if I get a if, if I don't know whether or not flow ids are in that are valid or not, um are gonna are gonna apply. Then, when I get these packets I don't know how to deal with them right and um and maybe and and me if I knew what the flow ids were. I know how to sort them or bucket them, or something like that.

C

So I think it's like yeah exactly what the receiver the packet knows when it receives it's important information and if you're, gonna, buff them anyway, like I just I think, it'd be useful to like actually map out a little more detail. How we expect um this, this opposition to work for the structure absolutely and just to be clear. The goal here was to talk about like 10, 000 foot properties.

C

When you know this will turn into a pr with a bunch of text that will hopefully answer these questions, but you're right we'll have to write that nicely um cool thanks. uh Then there's a bunch of discussion on having a better name for false start, happy to call it something else. uh Martin duke.

A

He dropped out of the queue later.

C

Oh okay, uh lucas.

N

I I just want to give an example like having done something with connect udp in in a client. No, it's really easy to do a one shot, connect udp and provide a quick initial packet and then kind of just switch contacts and move on to some other work um and on the receiver side, yeah, okay, it's gonna receive the connect qdp and then, and then it's just gonna respond with the 200 there's, not a wait for a tcp and an ack and all of that stuff.

N

So, like it's nice, it's a nice property just to send some stuff and yeah. If the packet gets dropped by by the mask server, it doesn't buffer it. Okay, I can wait for a re-transmission timer to fire and do some stuff like I personally, I don't see the issue with whatever this thing. We want to call it fast, open or whatever, like it's a nice thing to keep. um In my opinion,.

C

Cool thanks- and I really agree, and actually for the for the record uh in my implementation of connect udp, uh the client doesn't wait for the http 200 uh before it starts sending datagrams and the server doesn't buffer them. If the server gets a datagram or a flight, he doesn't know drops it on the floor. Everything works great um because yeah, if you conceptually, if that packet gets lost, it's the same from the client's perspective.

C

It's the same thing as if that udp packet had been lost between the proxy and the target, so you need to handle that case. If you want to be a bit more clever, you can, but this just works, and it gives you like really. You know much. You save a round trip which is really important.

C

K

Alex uh thanks david. I wanted to actually uh address something that echoer was saying, which I found a little bit confusing when we were talking about things like the compression contexts and saying that you can't afford to lose that. I I think, that's fundamentally a type error right. If you're sending something like a compression context that you can't afford to lose on an unreliable datagram, then I think that extension is is malformed. If you're sending data like that, that would be, I don't know, potentially sent along with this. I.

C

I don't think that's what ecker meant and I'm just gonna, maybe rephrase it differently and echo. You can correct me if I'm wrong he's saying what, if you have a packet that you want to compress, and you say I want to do compression you send that reliably, but then the other side says no. I don't want to compress for you I'm out of memory, uh and then you have conceptually you could say.

C

Okay now I want to retransmit this uncompressed uh and this goes back to what we were talking about false start, which is we guess you could do this, but it's probably a lot simpler to just say: oh well, that package got lost so.

K

Right and- and I think that basically just means that we have a fundamental requirement- that any anyone who wants to send packets before a confirmation needs to be able to tolerate those losses and like in theory, you should be able to tolerate those losses anyway, you're using an unreliable transport.

C

Cool thanks definitely agree um all right, so that's the end of the queue for this slide. um We ended up not really talking about this slide. um Clearly, we need more discussion on this one. uh We don't have enough to declare any kind of consensus, but that way, I think we set the stage so that uh so by the way, yeah I'm gonna file an issue for each of these slides and we can keep the conversation going on. All these to you know, drive consensus eventually, next slide.

C

Please um so this I have like we have a few things about what the message would uh look like uh it's you know, assuming that we had decide to go to the message and not the header and I'm hoping like. We should still go through these because going for the message sounds like a very possible outcome and also, I think discussing this- will help people understand what the message kind of looks like. um So the question is: okay. Let's assume that we agree that we want this message: how do we send it on the wire?

C

What does it look like the two proposals that I've seen so far are so the one on the left is flow id 0., you reserve datagram flow id 0 as a control channel, and so that has the neat property that um you know. Datagrams are already. Intermediaries know how to handle them and check them all the way end to end anyway, and so they don't have to do any more work for this.

C

um The downside is, it means that messages can be sent on reliably, which is kind of weird, and you definitely need a way to send those reliably.

C

So it requires adding a reliable datagram frame that the interpreter needs to know about which, like it's at the http 3 layer, and it has roughly the same semantics as the quick datagram frame uh apart from it, doesn't mean the stream id, because it's already inside an http 3 stream. It just has the flow id um and then the alternate design here on the right is we create an h3 frame for this? um It's a cleaner separation. It doesn't have this notion of wait. What do you mean?

C

You can send this unreliably, but it means that the intermediary needs to like know how to parse this frame and by parse I just mean like look at the http 3 type and go oh. This is this copy, the the data and send it to the right back end, or vice versa, to the right client and that's it uh no parsing of what's inside no looking at the flow ids, no looking at any of the extension information, just copy paste um do folks have thoughts, uh so I see ben.

C

Let me just double check that any there wasn't yep yep ben go ahead.

F

There are a lot of different ways to spell this. I think it's a bike shed. I really, I don't think it's worth worth meeting time right now, I'll just say I don't really like either of these, and I think that there are some other combination. That's the equivalent but uh cleaner.

C

uh Okay, uh the the one on the left was your proposal ben. um So uh it's.

F

Yeah, I think we can do it yeah. It was. uh I think we can do even better.

C

Okay, then I will say: um let please send us your uh what would be even better, because I love to hear it, and I have actually a few slides on this message design. So then, let's maybe breeze through them a little bit. So we see kind of all the possible questions uh next slide, please so there and again this was part of ben's proposal where uh ben proposed the one on the right, um but pretty much. We have two ways of doing this.

C

We either say: okay, this frame is just right, just our flow id and that's it or we add in yet another layer of abstraction, because those abstractions are great, where this frame slash fly e0 or, however, we want to do. It means this is a control message, and then you have a variant that says what message is this? Where you know zero would be register flow id and then, but it allows extensibility there.

C

My gut feeling there is that it reminds me of sni which, had uh you know one of those extensively joints that immediately rusted shut, meaning that s and I you can say what type of it and you can only say hostname, so it was kind of a waste um and but the the one property has that I think is kind of cool. Is that the extensibility?

C

Unlike something like this tonight, the extensibility becomes end to end, whereas if you say define a new h3 frame every time you do this, um you would have to modify the intermediaries, whereas this, if you have the attorneys, just copying things back and forth, we're not looking at them at all. That allows you to have an extension, that's end-to-end without modifying the interpreter, so that's kind of neat um all right next slide. Please.

C

uh Another part- and so this one that is even more of a bike shed, so let's not completely dive into how we should do it, but just to keep it in the back of people's mind you in this frame, you need to have the flow id to say. Okay, I'm registering this flow id, but you also need more information. So, for example, like I'm, registering flow id 42, and I want to do ip compression with this ip and this port.

C

So right now it's a list of text key value pairs, because that's just easy uh in one of the proposals we talked about doing q pack and then people said, wait you're, inventing middlers, we don't want midler. So I we said absolutely not: let's not do midlers. I agree. We could also have a binary encoding. That is, you know more akin to tlvs and how quick transfer parameters? Look, that's something, but that is definitely on the color of the bike.

C

Shed spectrum so we'll have to we'll have to figure that one out um next um next slide. Please and then uh another point which was do we need the reliable datagram frame. So there are some cases where we're saying it would be nice to be able to send datagrams reliably, sometimes uh like for connect2udp. Some folks were saying. Well, I would like to send my first udp packet reliably, because if I lose the um the connect request, there's it's the server.

C

The proxy is not going to be able to parse it until I retransmit that so might as well same shove, the first gdp back into that and then retransmit it as well um in in the design where we use flow id 0 as a control channel. We absolutely need this because that way we want to send those as reliable datagrams, but in other designs, it's more of a nice to have, because you could also do it by defining a tlv encoding on the data stream.

C

The only downside here, well, the only property here that is goes both ways is it requires a territory support, just like you know, parsing the datagram frame. So if we put it in early, then we have it. It costs a bit more first, but if we don't do it now, it might make it much harder to do it later, because updating intermediaries is hard so again, another open question: we have here a question from jonah.

G

A quick comment: uh I mean this ties to everything. I've been I'm trying to think about how to do. You want to do the if my destiny is correct, I think it will be helpful to actually characterize what the properties are, that you want for the register messages and then figure out how to map them to quick primitives.

G

This is how I'm thinking about this and when I do think about it that way, reliable datagram is a double negative right in the quick world anyways.

G

So that's kind of weird, and I think we have a name for that. It's called streams. We might want to consider something that you use. I don't want to design it right now, but it just seems that reliable data is nothing but a stream. We might need to figure out how to do ids and and associate things with things, but uh it seems like we might want to go back to looking at the perimeters that quick offers to to map to the requirements of these messages.

C

So so to clarify jonah. This is this would be an http 3 frame and that's one of the things that we kind of messed up in quick, quick frames. Http 3 frames are complete different things, so at the quick layer this would be sent over a stream. The idea would be, how do you encode a datagram inside a stream, and you say this is a frame at the h3 layer and I apologize. I should have spelled that out in the slides, so that that's why that's how this would look.

G

Oh no, I get that, but I think again the same thing applies to http 3 right. The default assumption is that it is reliable. The whole point with datagram the whole point of writing. This draft is so that you can actually afford to use http 3, along with unreliable datagrams, agreed and so to me, reliable datagram again, even in the http 3 world itself sounds like a data frame.

G

um Do you disagree with that.

C

Okay, I mean this is just a way to send the same like the same semantics, but over a stream. It's another way to say it is. You could build this without a frame and say like have your congestion controller retransmit that datagram frame, but it's simpler to just have one one layer above this here, but again you could put it in the data stream and then you're done. That is totally a valid option.

G

So I think what.

C

You're saying, is you don't like this http.

G

Well, I'm saying that this frame is the same as the data frame in http 3 data frame. Is it not.

C

Well, no because the the the data stream in http 3 is a stream and it doesn't have delineation.

C

So you, if you wanted to send these data graphs in the data stream, you would need to define for every request a tlv scheme inside your data stream, because intermediary users do not respect boundaries of data frames in http, 3.

G

Okay, fair enough.

P

Cool thanks uh mike, so I just wanted to note another way of um thinking of this. In the h3 context, we defined all h3 frames to be hot by hop and only the request itself is end to end. This is effectively an end-to-end wrapper for nh3 frame.

C

That is true. Is that bad? No, I'm just genuinely asking.

P

No, I don't think it's bad. I I think if we build something like this, let's not scope it so narrowly that it's only for datagram. This is an envelope that says I would like you to forward this to the end, keep it with my stream.

C

Okay, that's- that is an interesting thought. I don't want to do two things that are too generic, but yeah that could be neat all right. Thank you, okay, and this brings me uh next slide, please to the end of our slides um on h3dgram.

C

So I'm really happy. We landed well looking for on the list, but we landed on in a good spot for the one two, uh so the two layer or what I call the two layer design a lot of the other questions. um We will need to talk about more and that's cool I'll, take an action item to file a github issue for every single one of these and then I'll email, the list and please double check, and if I've forgotten anything, please follow more issues.

C

I think it would be great for us to like discuss these more and uh chairs. Maybe at some point- um maybe uh I would love- probably prefer another interim next month uh for us to make more progress here, depending on how we make progress on github and on the list, um but then otherwise, back to you chairs,.

A

Thanks david, all right sounds like we've got enough to make some good forwards progress there. uh Please do update us when we've gotten a little bit of that done and, of course, we'll keep the discussion going on github and on the list. Next up, we have a shortened quick aware proxy in here.

E

And that is tommy all right, I'll go shorter than 10 minutes, and the purpose of this is just to to give a little bit of explanation of the stuff we're currently doing not to have an in-depth discussion, but since this is one way of doing an extension, it can inform some of the other discussion next slide please.

E

So this is primarily looking at ways in which we can modify the base connect udp to make it work a little bit better for doing quick within quick. I think there are some parts of this where we have textbot advice for handling, quick migration handling.

E

Other uh cases of how do you deal with the sizes that you want the initial sizes for packets for quick within quick that actually could apply to connected udp in general? And so maybe those could move over. But specifically, the extension mechanism in here is about letting the proxy be aware of the connection ids, and that allows a couple different things one.

E

It does allow you to reuse um ports between a proxy and a target so that, if it is having to use v4 or just has a ton of connections going through, it doesn't need to actually open up necessarily a new uh udp socket for every single, quick connection, that's being proxied, since the connection ids can do the job of demultiplexing.

E

That also has some effect of obscuring. How many clients you have exactly and then the other big aspect is improving the efficiency performance. um So this has. There are kind of two problems here. One is if you're doing a lot of quick within quick. There can be just processing overhead- that's not necessarily, as ecker was pointing out on the list, not necessarily the crypto being the concern, but just some of the the fact that you have to process it in software um oftentimes in a deployment. But then also there's a concern about.

E

You are losing some mtu during encapsulation of quick within a quick datagram, potentially within another quick datagram, and that is something that should be solved that can be solved by compression. But that can also be solved by not having to re-encapsulate next slide.

E

Next slide, please sorry um yeah! So as far as applicability.

E

A lot of what I'm thinking about here is when you have multiple proxy hops um being used to kind of further obfuscate um what ip address is being used and not allow one proxy to unilaterally kind of know everything about a flow.

E

So if you have a bunch of proxy hops, you can potentially have cases where you don't need to fully re-encapsulate or re-encrypt on every hop this mechanism of doing forwarding, in which you kind of do a secure handshake. But then you just forward quick packets end to end.

E

It is not absolutely not for everyone and not for all cases. It does allow you to if you have an observer across multiple parts of a path to be able to correlate packets, um so that's not always applicable and always useful, but in cases where that is not um kind of the main concern or attack, then this is useful. It is critical for this that both parties must consent before any type of forwarding mode is done thanks a lot.

E

um So I think the key thing for us is if we are doing multiple hops of connected udp. The performance definitely is impacted if you are able to have quick awareness and start doing forwarding mode. So in tests of using a quiche based h3, um you tested both with kind of normal connect. Udp, sorry.

M

E

Yes, which quiche sorry, the um the one that lucas works on the the cloudflare based quiche, not.

E

So using the quick awareness to program forwarding rules um based on quick connection, ids um into the nick using ebpf rules, um and so this was just running a test, for example, on a one gig ethernet link to uh h3 next top. So next slide I mean it's so um on this link, you know directly with h3. We could get.

M

900 megabits.

E

Per second going through connect, udp, not super optimized. Admittedly, you know, there's definitely overhead, but just very clearly being able to forward completely. Unsurprisingly, because it's just putting rules into hardware gets you very, very fast and essentially line rate.

E

So in cases where this is appropriate, it makes it essentially free to go through one more hop, and um you know it's not for treating this as like a pure vpn tunnel. But essentially, if you want to be able to have a quick router that you can have a handshake with and say, I want to route through this hop and then that hop in that hop. It gives you a very, very efficient way to do that next slide.

E

um So, as we've been working on this, there are a couple of interesting issues that have come up. Some of these we've already uh fixed. These are slides from itf 110 and we did come out with a wrap of the dock just this week.

E

That tries to start talking about some of these, and I do think that some of these issues are things that we could bring back into the overall conversation and thought around connect. Udp, particularly when you are doing quick specifically, you have um cases where you have to worry about the mtu um and even kind of regardless of changes in mtu.

E

We need to think about when we are doing connect udp. What is our initial packet size that we're allowing?

E

um Because you know clearly, you wouldn't want the connection between the client and the proxy to be constrained to 1200 bytes, because then you wouldn't even be able to put a quick initial packet through that tunnel, but even if you, as you do for some implementations like what google does of hard coding, it's just 1350, you probably don't want to just try to stick 1350 inside a 1350, quick tunnel because that's not going to fit so we need to have some thoughts around path, mtu discovery, et cetera, um doing connection migration is also quite interesting when you have a proxy here, there needs to be thought about.

E

If you are resetting your congestion control timer. uh How does that get propagated up to the um the target that you're connecting to and then one other thing that we've already done? Is that um it's important that if you are able to share um sockets between the proxy and target that you can do it um potentially between quick flows where you can actually distinguish between them using connection ids, but it's not necessarily safe to do that for other flows anyway, I think that's the end of these slides, so yeah.

E

We don't need to spend a lot of time with questions or anything, but this is just one of the kind of motivating uh areas that we can work on as extensions to connect. Udp.

Q

Good question from ecker.

C

Yeah, I guess I'm really quite surprised performance numbers here, um so um you know like we have plenty of examples of people doing the line rate tls as substantially higher than gigi. um So, like I mean this netflix paper from a few years ago, um showing how they did it so, like I don't know what the situation is here but, like the you know like if the essential, which is which, like the particular quotation you had can't like handle like a bit of load, have quick load like.

C

I suspect that is an implication problem and it can be definitely is temporary, as opposed to being a like inherent like like, like designing, like a like, like basically like. Do we doing null ciphers so that like because we because.

O

We're like because, like we're too lazy to like optimize like our kernel deal, is it our current quicker quotation? Is nothing like the right trade off.

E

Sure so I mean to be clear, I think. Even you know, these are numbers from march. I think keisha's own implementation for some of the stuff has improved. Since then, um however, I think there is something about you know scalability here, like being able to do a hardware offload of rules to essentially turn this into a a quick handshake to a router that essentially then just becomes a router.

E

So it's like a secure, authenticated router um is like that box is going to be able to have a lot more capacity if it's just programming rules, even if it is able to achieve good line rate, um it's going to be able to handle more connections if it's just doing hardware offload rules so again like I do not think it should be used.

E

Always all the cases that we're looking at using it for would be with a mix of forwarding and tunneling, um so that kind of no end-to-end user connection would ever be just forwarded um but kind of interior links. Where you don't necessarily have user data exposed. You already do. Have um you know quick protection? So it's not. I don't think it's quite the same as saying we're using a null cipher on tls. It's saying that we just don't need to wrap up the tls encryption three or four times.

C

I I think we can. We can argue this analogy later. um The second point I wanted to make is that um you know all the multi-hop scenarios I'm familiar with. Are situations like tor, where you actually have where you actually have really aggressive threat models and those aggressive threat models.

C

You have to use different um different encryption anyway, that does this, does it that has constant size frames, it doesn't expand them and so like, like there's like a whole like sphinx and a whole set of whole set of work on this, and so like again like I just like, like the mtu thing like I like, I guess I mean.

O

C

O

Think we hope for me in this document would be like substantially more detail on exactly the applications which creates requirements because, like I'm just.

C

Saying that these are a set of requirements which one often sees listed for having weaker security um and exactly the sort of vague mode and so it'd be helpful for me to have like a much clearer set up like exactly the applications. That would allow me to assess where, like these were good trade-offs to make yeah.

E

That sounds good and we can talk about that more in the future. um Certainly um yeah I it is not the same as tour. Absolutely.

A

All right, all right, we are at time the couple of other folks are in the queue. Please take your questions or comments to the list, and next up we have the end of some of our requirements, which is back to david.

C

I'm back um all right, it's me again uh so now we're talking about the ip proxying requirements document um and the so the we're getting close to the end. I'm gonna walk us through, like a few of the remaining issues and then hand it off to the chairs on what the working group wants to go next, so first one this one, I think, would be easy.

C

uh The current requirements draft said we should support http 2.. uh It sounds like this feature is really important, so people are saying no like. We need need to support this. So there's a pr. That's a one word change, which is. We must support h2. Does anyone object to that.

C

All right, I think we can declare this good, we'll confirm it on the list next slide. Please.

C

uh So the the this is a clarification one which was slightly editorial so on the um uh support um supporting route negotiation. It wasn't clear to everyone that this you know, negotiating routes allows you to exchange a default route, so we have a pr that has a sentence to make that crystal clear. uh Does anyone object to this.

D

I think I'm on the cube, so I am happy to have a clarification here, but my comment, I believe, was also about. If this is an optional thing or if it is a mandatory thing.

C

uh About being able to negotiate routes- yes, oh yeah, so right now it is. uh It is a mandatory bit.

D

Yeah- and that was my question like if that's not clear to me, because it addresses one specific use case, so it could also be an extension um as we've done with other extensions.

C

I mean that seems pretty like you can't have any kind of tunneling without routes, uh because then you don't know what you can send over it. So I don't see that as.

D

Proxy rewrites the ap address, and you know is, is the one that is responsible for having the peter, as I descend out that you can have it so.

C

I I I think, let's maybe table this so there's an issue further down about proxying, ip packets or ip payloads, and depending on the resolution of that one, I think this one will be easier to resolve. Does that make sense cool, okay,.

K

Alex uh thanks david. I just wanted to say that I think that this is a mandatory feature because of the other text in the ib proxy requirement, which says that we have multiple use cases, some of which require routes so sort of orthogonal to the payloads versus packets question. Other use cases require this, so I don't see how we can avoid having it be not mandatory.

D

So I mean, I don't think, that's a that's a good discussion to have so we should stop here, but we said for other use cases. If it's only one use case, it is an extension not mandatory, and now we say because it's one use case, it's it's mandatory and should not be an extension. So I think this I don't think.

C

This needs anywhere, so, let's just move on yep, let's put a pit in this. I agreed um all right next slide. Please.

C

um So about validating the address assignment so the um right now, the draft has the requirement for being able to assign an address to the peer, and uh so this issue is about validating that the peer has authority over this address range. um This is a policy decision, and policy is out of scope. So my pro so the proposed resolution here is to close with no action. Are there any objections.

D

So I think sorry I should enter the queue go.

C

D

Your issue, so I think this is more than a policy policy issue, because if you, if you need that, you also need.

G

D

Support for it right, but what? What like? There's? No there's a non-requirement for address assignment. I think that's like just um too much so I would just remove this from the director.

C

Just sorry remove what from the draft.

D

Yeah the non-requirement about address assignment, I don't know why we have it, why we need it.

C

D

C

Know, as with any document that defines scope, you need to define what's not in scope.

D

Yeah and it, I think it depends on the use case. If you need this, and it depends on how we design the protocol, if you need like protocol support for it.

D

So I don't think why we need to re rule out this from the beginning.

C

Well, because we've kind of- and that was part of our charting, don't forget, of like these kinds of policies are not something that we want to do. You know, for example, saying that I'm authoritative over rfc 1918 space- I don't even know what that means. So I again like this: doesn't I just really don't understand what we would build as part of the protocol here.

A

Ecker's in the queue, if we want to.

C

Keep moving go ahead, I'm not, I guess, I'm trying to work out what's at stake here um so um so, as I immediately just like ignoring the text for a second. As I understand the situation, there are effectively two operating modes for a protocol like this one is, um I, the client just transmit my own addresses and then the server nets to whatever, like the heck it wants to it. Wasn't that too right and the other is um the server tells me what addresses it wants me to it.

C

Wants me to send it to and then maybe an answer it doesn't. But presumably it doesn't right, um don't mind. Imagine it did. Maybe it maybe you know. Maybe it says 19 agent. It may give me 1918 addresses and I'm not to those right and then that's on the ingress right.

C

um So um if I, um as I understand that this protocol is compatible, these requirements are compatible with I, the protocol implementing, I would say um either the second only or the second and the first, but not the first only correct, um namely that um that this this seems to be the required implied requirement here. Is it must be the case.

C

This protocol does support a way for the uh server to give me an ip address range, which will then transfer on unaffected output at the door right, um um but it could also be the case, but if there's not a requirement that not also probably the other function, is that what's a stake here.

C

I, yes, I think the idea is that what transformations happen outside of mask are considered out of out of scope, let's say, for example, if you want to put a nat between what's happening in the mass tunnel and what's happening on the internet, we just clear that out of scope for mask, I think that's probably it um well. I guess what I guess I'm trying to get out, though, is like is, um is do the um does this?

C

Is this text implying to say that the first thing you have to do is always do an address assignment from the pier or no no, not at all, uh and if you're asking what the text does might I'd suggest reading the draft? I I'm reading that david. I I am reading the text, so perhaps you know typically. Typically the response to your text isn't clear. Is it's clear? It's not really quite the right answer. um Okay, then, if it's not clear, then absolutely, let's fix that. Sorry about that.

C

I'm trying to understand, what's, as I said, trying to understand what's at stake in this discussion so like um like like what is it like? What is the question here about like this? This issue?

C

I think that's the question for miriam, because it's maria's issue.

D

And so I should probably look back at the issue, um but, like my memory is that this was about a non-requirement that is specifying out that, like any kind of address, validation should not be supported, which I think we might.

G

Want to support.

D

If, like the netting is not a separate thing, but something that we integrate, because we actually requested from the proxy for example, so I just don't want to rule out that we cannot.

C

D

If we want to do it right, yeah.

C

Okay, so just to be clear, something being out of scope doesn't mean you can't do it like as an extension or something it just means that we don't need to go there. But might I suggest we move on to the last issue because I think that's the most important one that really needs uh face-to-face time and this one c isn't clearly for well-formed enough to have a conversation because we're all confused. So maybe mary, if you could like add more text on the issue to help clarify this um tommy.

C

Could you make it uh real, quick.

E

I was just gonna say it sounds like the right thing to do here is specify that the base document for connect ip or whatever it's called, should not do address validation, but do not say anything about extensions and that, I think, will sound all right.

B

That sounds great to me. Thank you right.

C

Next slide, please.

C

All right, so this was the topic we breached a little bit at the previous itf and it's the most important one when it comes to ip proxying in the mask working group. uh Are we proxying ip packets or are we proxying ip payloads? um One point is: if you build a solution that proxies ip packets you're able to build an extension that compresses the packets, which therefore allows you to proxy ip payloads, but unfortunately you can't go the other way around.

C

If you have something that proxy ip payloads, you can't easily do ip packets, uh and I think this is the part where I hand it over to the chairs, to moderate this discussion.

Q

Yeah thanks david um excellent, so just to remind everyone um sort of what what we're trying to accomplish with the requirements doc and the purpose of this particular issue that david just mentioned, um we're trying to scope out the requirements for the solution that is, connect ip. That will eventually work on later on, hopefully, shortly after um you know, this meeting concludes and at the next ietf meeting, um the the document itself is is purely meant to to support the particular solution.

Q

It's not meant to be published as an rfc or anything, so we don't need to get it perfect um by any stretch of the means uh and uh given all the work that's went into it so far and all the discussion that's generated uh eric, and I think that the document has basically done its job in terms of by helping us scope out what should be in this eventual solution and what should not be um modular, one particular issue, and that's this, this fundamental issue that david just raised um so next slide.

Q

Please, um and that is whether or not the the base protocol should support uh proxy and payloads uh or packets. um We had a show of hands uh during the last meeting um in which the outcome clearly uh suggested that the uh support for proxima packets was uh sort of essential, um but less clear on whether or not proxy and payload should be part of the base protocol, and so this is something that's sort of orthogonal to the actual solution. We'll have to sort out this question, regardless of where we go with connect ip.

Q

um So right now, with the ongoing consensus, call on the list we're just trying to answer this specific question um next slide. Please.

Q

And so our request to the people who have an opinion on this is to please chime in on the the consensus calls going on right now, either by sharing use cases that would help justify one particular approach or the other or just stating an opinion either it's fine.

Q

Ideally we come out of this with consensus in terms of what the base protocol should do um at that point, uh we'll consider the requirements document uh complete, uh especially given the non-controversial issues that are the yeah, the simple issues that david just went through regarding uh issue fallback and whatnot. um So I'd like to briefly pause um and just ask if anyone sort of violently objects to that, uh um and if not, I think, that's that's what we'll.

Q

Q

Okay, great so again, please uh take a look at the consensus, call on the list, uh chime in with an opinion and then, when that's done, uh we can make the changes to the document. Accordingly, publish a new version and then move on to the solutions at the next itf meeting.

Q

And uh I guess, unless there's anything else, we're right at the top of the hour, so we can. We can call it here uh thanks to mike for taking notes and for david for um speaking for so long. um uh I feel like this is pretty productive and we have a number of good uh avenues. Moving forward for the issue, datagram work, as well as the ip um connect ip work. So um yes, and as eric points out, please don't forget to add your name to the blue sheet and the notes um with that.

Q

I think we got.

A

Thank you all thank.

Q

G

Thank you folks,.