Internet Engineering Task Force 110, 8 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF110-WEBTRANS-20210308-1600

Description

WEBTRANS meeting session at IETF110
2021/03/08 1600

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

A

But we can hold on for a few more minutes to give people time to trickle in and then we'll get started shortly.

B

Is my volume all right.

B

A

All right, but you're cutting out.

B

Is this better? Yes,.

A

B

So far so good say a few more words victor, just in case one two, three, four, five, six, seven, all right!

B

Okay, thank you.

A

If our other presenters wanna just say hi to test their microphones, that's probably a good idea as well.

C

Hey this is: will law good morning how's this.

C

A

They're showing up as unmuted, but I didn't hear anything.

D

Likely because I didn't say that much.

A

Oh okay, now we can hear you cool.

A

A

By the way for everyone speaking, it sounds like uh miraco still has this bug where it requests the microphone only when you unmute, which means that it takes a few seconds for the microphone to start opening. So once you click just wait for a bit and then start talking, otherwise, the beginning will be clipped down.

C

David, this is willow repeating my mic test. I was pretty sure it was too short. Last time. Can you just confirm this is okay, yeah.

E

E

Are we still waiting or do we want to get started.

A

Probably good to get started.

A

E

Sure this is the web trans working group meeting at ietf 110.

E

A few meeting tips this session is being recorded.

E

You need a data tracker login to attend, but it's automatic, so you don't need to fill in the blue sheets. You can join the session jabra via the data tracker meeting agenda. Just click on that.

E

Please use headphones or an echo canceling speakerphone to avoid echo and state your full name before speaking, so we can get it in the minutes.

E

uh Just a few little tips on meet echo, you enter the queue by pressing the hand, raise your hand button and you leave by pressing it again.

E

When you call on you enable your audio to be heard and, as david said, it may take a few seconds to actually turn it on and you enable it by unmuting and disable by muting. You can also enable view video, it's separate from audio and not required.

E

So here's the note rel, which is a reminder of itf policies and that's in bcp 79. Please read it and there's definitive information listed in the documents below. If you want advice, you can talk to the chairs or read these a little bit.

F

A

E

A

uh Sorry uh on the previous slide, I just also, as usual, want to uh highlight the atf world of conduct which this meeting is operating under er we've never had any issues in the web trans-working group in the past, but let's keep it this way, always be nice and polite and need to listen to other perspectives.

A

Great thanks. Thank you.

E

um So uh the agenda is up. There is a uh ether pad which we'd like people to take notes in uh and the jabber room. um I believe we have a volunteer for javascribe.

E

That right and no takers is that true.

A

I don't remember if anyone has already volunteered, please speak up now. All right, ellen friendel is uh in the jabber as jabra jobscribe. Alright, thanks alan. uh We do need minutes, though, could we have uh one or two volunteers? Please.

A

All right, so our canary will uh will do some note-taking, but he's also presenting. Could someone be back up and uh that way it's always easier when there are two people.

A

A

We are waiting to have a volunteer, otherwise we're not going to start the session. I know we all know to do people but come on please. This is how we do business.

E

Wanna draft somebody david uh lucas, just volunteered. Thank you so much. Thank you very.

A

E

You're a gentleman and a scholar all right, so here's the agenda- we've gone through most of the preliminaries from the chair, uh we'll have a w3c update from will and victor will talk about web transfer of http 3. uh eric will cover http 2 um and then the chairs will wrap it up so over to will.

C

Okay, thank you good morning. This is: will law from akamai I'm also joined by dub 3c uh co-chair yanuvara brewery from mozilla, so you can all read faster than I can talk, but I'll go through these bullet points. We just have two slides here on a quick update, a couple of key decisions in prs following the last iet update on november 16th. So at that point there was the ietf single transport decision.

C

So we've echoed the ramifications of that through the w3c removal of quick dash transport as an option, while also, while maintaining the web transport constructor the removal of mixins to concentrate on a more concrete api, around http3 mapping of web transport methods to quick protocol actions. Datagrams are now at duplex stream. In other words, they have a readable and uh writable interface, considering making a similar change on the bi-directional uni uh streams put so that their symmetry and so that we can support a stream of streams functionality back pressure available on datagrams.

C

Now the app can set a time window which it flushes stale data from the underlying queue. The web transport example has been updated to use more modern javascript, using 408 methods and piping. It's for a pretty clean data flow through the system and then there's been much smaller housekeeping fix some races, algorithm updates, etc. I'll pause at this point. Do you have questions on any one of these bullet points.

C

Okay, I hear no questions next slide, please bernard or david.

C

So we have some issues currently debatable. We don't have resolution on these, but to give you some flavor of what's being discussed first, is to make sense stream and receive stream a subclass of writable stream and readable stream. There's arguments for and against this in terms of pooling, um there's a request for a constructor argument to web transport.

C

So you can decide if your connection is going to be dedicated uh or shared with other http 3 flows and there's complications around that, obviously, because even though the application might want it, both the the operating system on both the client and the server also have to support that and how to get that information back to the app some debate about which stats we can provide and which stats we should provide, especially in the face of pooled connections, work around defining error codes and also work around some generic interface names and if we're we're, hogging generic interface names and we should make them more specific and then.

C

Lastly, a request from the w3 side to the ietf. Can the scheme to be used for web transport connection be finalized? We had a work group call our last one on march 2nd. We didn't have a call for consensus on this, but I can report that those president bernard david, victor yatakan martin, who I think are on today's call as well- have expressed a preference for https, uh no more input from our side than that, but we do request uh if possible, that the scheme be finalized. So we can proceed with the api.

C

Thank you, questions on the slide or any other questions for the w3c team.

C

Okay, david back to you, then thank you. Thank.

E

You all right so we're going to turn it over to victor for web transport over http.

B

B

uh good morning, everyone, I'm victor vasiliev. I work for google and I'm the editor for web transport http draft, which we adopted in the time between the last interim and this meeting.

B

So now that we adopted the draft, there are lots of issues we need to solve and all of those issues are on github and if you haven't you're, welcome to you're encouraged to go to this link and comment and because there are lots of issue open issues.

B

uh So my goal for this meeting is to get us to the state where we figure out the most important issues that prevent us from shipping. An interoperable version of web transport over http free uh and the primary reason for that is chrome is currently shipping uh web transport over quick as an origin trial and we're basically under incentive to unship that as fast as possible, uh so that we no longer use something that is uh deprecated.

B

uh So let's go over issues the next slide.

B

So the first issue is uh the syntax for server initiated by directional strings. The current syntax is roughly whenever you open a stream which is server initiated and bi-directional.

B

You just assume that the stream belongs to a web transport session. You put the session id in the front of the stream, and then you put application payload on both sides uh and.

B

We do that because http free does not define any specific semantics for what were initiated by directional streams. In fact, it explicitly pencils uh and we allow those. So there is an observation that if we just find them this way, we will not be able to use them for anything else, uh so the proposal is to make them use essentially the same syntax as client-initiated bi-directional streams, which is a sequence of frames.

B

So I wonder, if do people have any.

B

G

Hey there, alan from dell from facebook, so uh aren't client initiated bi-directional streams identified by them being a connect request. uh They already they have, they have a frame jab. I'm sorry, I'm.

G

A

You're in the queue go.

H

Ahead, I mean this is okay, so um it looks like the client originated once look like they have a frame type, but they don't technically have a frame type. You just have a frame type and then it just it's the rest of the string and the same would apply here. Is that right.

B

uh Yeah so like, I would separate the that's a separate questions as a separate issue that I actually think is next slide, but the what's the proposal here is that we should make the client initiated and server initiated, behaves the same.

H

Sure I think that's reasonable as long as they're distinguishable from up from other types of streams for the client.

G

Side, ellen yeah, so do we want or need- and maybe this is not a question for web transport, but do does there need to be sort of a datagrams falls under this as well, which is that, like everybody who wants to extend uh server initiated bi-directional streams uh in http will also face the same decision right and if we want to encourage all extensions to sort of follow the same thing. So different extensions can be de-multiplexed in the same kind of way. So I don't know if there should be.

G

You know, sort of general guidance for extension riders so that um that we don't have to keep redoing this in every http extension.

B

B

A

Are you speaking victor because we're not hearing anything.

B

No, uh I I'm asking if you're the next person kid.

A

Oh yeah, no, I ended myself so not speaking as an individual. I think it makes sense that, like similar to datagrams, where we have a draft, that is just how do you use datagrams of http 3, because the original http 3 specification doesn't have semantics for them.

A

Maybe what one thing we might need here is an incredibly short draft, which is: how do you use server, initiated bidirectional streams with http 3 and it carries the setting, because all of these things need one and then it's you use h names and that's it, and then we reference that from um from this document, would that make sense.

B

uh Yeah that would make sense. I not completely sure separate draft is required as long as we pick an approach that is compatible with what is with further extensibility.

A

That's true, that's reasonable, as as long as uh we maybe we have. We tie it to a different setting from the web transport setting, so it's possible for any other extension to http 3. To do this without having to have a dependency on web transport itself.

B

Yeah, I'm not even sure it's that it's like as long as the two extensions do exactly the same thing, which is use frames, sequence of http frames, you're, fine,.

A

They are, but I'm saying like in terms of dependency on what settings the other extension needs to send all right.

I

Ian sweat is next in the queue hey, um I'm not completely sure you even need to talk about settings in all circumstances.

I

It seems like this is more a case of uh you know how how does one extend http 3, and I think if we make this decision, which is totally sensible, um other people are probably going to want to make a similar decision book because it's also sensible and because it's compatible with this um I mean we could write a separate document, but given their wide variety of use cases out out there. This is this is more a case of like it's best practice not to hog all the um server initiated, bidirectional streams.

I

Right I mean- and this is this is the obvious way to do so. That's um that I can see. So I don't know I mean if this already existed and hp3 wasn't so far along. I would say we could show this in the existing section. That's already there, but at this point yeah, I don't know. Maybe martin has the thought on where'd she go, but I I should say I don't think it really matters. I think either way we should move forward with um a consistent design here.

I

Just matter do we need to also stick that decision somewhere else.

J

H

I was, I was going to say exactly what ellen just put in the chat, which is um we don't really own. Http, 3 and we'd have to talk to the people who do in order to get that to happen. I think it's probably best if um the http is working group defines a doc a generic document. The document should probably also describe what it is to use a client-initiated, bidirectional stream as well.

A

I mean the, I think the core http 3 document specifies how um client initiated streams work, that they have, they carry frames and then that's left to extensions to do different frames. Isn't it.

H

I think it says that they carry requests which are comprised of frames right, so that that sort of level of generic use is probably something that it's sensibly done. There, obviously with people from this working group going over there to do the work but yeah.

A

That makes sense. Okay, as as chairs, I can take an action item to reach out to the uh http working group chairs to see how they feel about this and what we should uh do about this work, because it sounds like our options include having this part of this document having this part of a separate document, that's in web trans or having this part of a separate document, that's in http, um because similarly, the datagram document uh ended up in mask not in http at the request of the http chairs.

A

So this I could see that happening as like this document being in web trans as a potential option. At the end of the day, these documents are pretty short and simple. um As long as we get them done, I don't have a strong opinion for where they live.

I

uh Allen is next in cube.

G

Yeah there's one more uh point that I raised on issue 23, which is not totally related to how bi-directional streams work exactly it has to do with the fact that unidirectional streams are identified by a stream type and bidirectional streams are identified by a frame type but other than if you ignore that those two things are different kinds of types they otherwise look the same at the beginning of the stream, and you know I have an implementation of the current draft and I end up taking advantage of the fact that they look the same.

G

But if anyone ever actually added a frame type with the same identifier as the unidirectional stream type, then my beautiful symmetric implementation would break, and so- and I think this is a little bit of a weirdness that came out of how http 3 decided that there are stream types and frame types. And we you know those decisions have been made, uh but it might be nice to reserve the unidirectional stream type number in the frame type space.

G

uh I can. Maybe maybe we can put that on a separate issue if it's not directly related here.

A

uh Thanks ella, I think uh let's have bernard and I circle back with other chairs, to see where we want this particular work to land, and I think that'll be a great issue for that document. Whenever it shows.

A

B

Okay, so the next issue is the use of type value frames and how exactly are they are defined so the way we are currently defining a frame that converts a http request stream into web transport stream is by introducing a type value frame where you have type, and then you don't have any length, because the entirety of the rest of the stream's body is assumed to be the value and we and so currently all defined http free frames have a tag, length, type length and value.

B

But we in when we talked about this in quick working group, we agreed that extensions could potentially define type value without length uh and the original intent was to make a data frame that would go to the end of the stream. So you would need to so. You could avoid extra level of framing.

B

And on the issue discussion, it was not clear whether people believe that land can be admitted or whether the length is always has to be there, but you can set it to zero and ignore it for those kinds of frames uh and the question here is: should we we currently don't have land? Should we edit.

A

David, uh so speaking as a as an individual here, I I personally think that this would be a useful feature. That's like generically in h3 uh that we had talked about, which was uh if the frame length is zero. The the frame goes to the end of the stream. uh We there was discussion of adding that uh into uh issue b3, but that got to turn down at some point.

A

um Maybe this is something we could do generically, but that would have to see if people are okay with that http or if we want to do something. That's just specific for the web transport frame.

B

Type, yes, so do people have other opinions.

B

I

In uh yeah, I I don't have that strong opinion on this, although I did have a mental model that this was what we were going to do for extensions like this, to use type value without an explicit length or a length of zero. um But this is another thing where, if there was some magical document that the hp working group produced about hp3 and how you should do extensions, uh we it'd be kind of nice to show what we think is the best practice into that document.

I

um I'm fine for this to go either way at the moment. I don't think it either way. This is like kind of a weird special case, um because in one case you don't have a um a length or in the other case you have a length of zero and in both cases, if you don't understand what the type is, uh your parser will immediately fail. So um you know the these. These frames that we're talking about are special. In some sense, they are not standard uh hp, uh three frames that that exist elsewhere.

I

So that's kind of why, in practice I think either can work.

B

G

uh Yeah I mean, I think, just recognizing that either you know either as possible. Again like I do, have an implementation, and so I had to go and write special code to handle frames that have no length so, but it was like you know three lines of code or something it was not ridiculous, and I I do view them as mostly equivalent.

G

um You know, and even if we wanted to say, have an extension to the extension frame that had other things in it. Besides, you know, then you would have to add a length there. So there's maybe a reason why you could just start it with length 0, but then, even if there was an extension to it, it would probably have to be another frame type anyway. So I don't think that really matters either. So I don't know we can just pick one or decide what best practices.

B

J

Hello, can you hear me.

B

J

Okay, uh lucas party from cloudflare um I'm kind of confused by this, because my implementation, if it saw an extension frame with a code point, it didn't understand, would wanna like just ignore it and then move on to the next frame. But I don't know how long the frame is to ignore. So maybe I'm just missing something here, but I don't see how I can ignore a thing that I don't know what it is, but it doesn't have a length.

B

uh I think my answer is this: in general, this is like why we define a setting and you don't send that frame without a setting. So if you set a setting, you promise that you will not ignore web transport frame.

J

But if I don't set the setting- and you send me one then you've broken.

B

J

Connection, I I don't know.

B

Yes, that's why you're you're not supposed to send it if it's not negotiated.

J

Sure, but but the current hp 3 extension story is that we just ignore unknown frames, so um yeah yeah we in a in a perfect world. This shouldn't happen, but I can't detect that from a generic hp, 3 implementation, because I don't implement web transport. So I don't know what you're.

J

B

Yeah, I I mean, I guess my answer is it's like it will be a fatal error for to sense that frame when you're. Both parties have not negotiated web transport, and I think the text explicitly pro tells you to not do that.

B

uh Anyways martin.

H

Oh, I think yeah. I was just going to answer lucas here that there's general provision in h2 and h3 for settings that change the way the protocol behaves completely. So in this case you would have a setting that says.

H

I understand that frame x means whatever it means, whether whether it's a zero length and then everything after that frame is uh something other than frames or whether it's just the frame type and it doesn't have a length whatever we decide you can have that meaning baked into a setting, and so, if you saw that frame type without the setting, it would just be a regular frame at that point. That should be ignored and it's probably going to be treated like an error by anyone who actually understands the frame type.

H

But um the idea would be that you use the setting to to ensure that you don't cause bad effects on the on the other side. I think that's completely workable. You just get to pick which outcome you want. What I did want to say, though, was that um alan's point about stream types and frame types is kind of relevant here, because the bi-directional streams are going to be just stream types more than frame types, and we can potentially exploit that somewhat.

B

And I I assume that means that slight speaks in favor of not using the length here.

H

Yeah, I don't think it. I don't think length gives you anything at this point, because a length of zero doesn't help, because what the generic parser that lucas has will do at that point is try to read the next byte as if it were framed and maybe that'll work, and maybe that won't and the result is undefined. Probably so we we have to rely on the setting here.

B

All right, thank you. Eric kinnear.

D

I think not having a length is a reasonable thing to do, and I especially like the the framing of it that martin said, which is essentially you know everything after this is, is no longer frames, um but it is worth noting that as you're trying to move this data around in the past, with earlier versions of http and http one etc uh having something that extends until finished is a little bit more annoying than knowing hey.

D

I've got about this much more coming, and I should make provision for that in my protocol stack as I'm trying to figure out how much to allocate or how much space is going to happen. So, if we're in a place like, I think we are here where what's coming next- is going to have its own structure potentially or could be otherwise defined. Then that's not such a big deal. But if we're talking about making this a super generic thing uh having something that just extends until it doesn't is kind of annoying in some ways.

B

G

Yeah, just thinking about it and listening, I I I think, I'm in favor of not having the length being the signal to say everything else on this stream is unframed, and I think maybe the the reason that makes the most sense to me is that there are frames already defined in h3, for which zero length is valid. Both data- and I think settings can be blank.

G

um So um I'm not saying that it that not having length is a signal, but I guess I like the idea of this is sort of defined as a different thing and not assigning a zero length for this frame to mean something much different than zero length for other frames means.

B

uh David, I think you're next yeah yeah.

A

I just wanted to say that, like my earlier comment about trying to do something, generic clearly doesn't work based on this conversation. So I completely take that back. I think, having something that's specific to a web transport frame with without the length, and that is keyed on a web check for a specific setting seems like the best way to go. In my opinion,.

B

H

Get the trigger word. I don't think that it's something that we can avoid in terms of generic stuff. For the bi-directional streams, I think we're going to need to have something generic for for that purpose. Exactly, but um aside from that, yes, the the frame stuff yeah, it's going to be you're going to need to know that when you see this frame type, you stop processing frames and that's going to be on a per frame type basis.

B

uh All right, it sounds like we have some form of agreement that at least the length is not helpful here. uh So we can move on to the next issue.

B

Next, oh yeah, so your eyes came so uh basically we have roughly two options: use, https or and use the new define completely new uri scheme for web transport, and that could be uri scheme for web transport over http or uh web transport sp in general.

B

uh And so, as will mentioned earlier, we had a conversation in w3c and basically there were many things said. But the short reason is that there's no particular reason to define a new uri scheme because, as far as we can tell web transport resources are just http resources. They do require custom syntax and they do require you to use uh a very specific http method. But that is not new to http oris says so.

B

We should just use https and uh that would make it work. Well, with the rest of the stack. uh The main objection was: there were subtle differences in which web transport behaves in gtp in terms of how it handles things like cookies and http off and, namely it currently does not, and at least in double ifrities draft. We it creates that it would not send either.

B

uh But I saying overall, that is a different concern from uh uh the fact from the question of how those resources are identified.

B

Does anyone have any questions for the.

B

H

H

Got in the mic line to give you support, uh this seems pretty reasonable. What to do, um uh I think notice, jonathan lennox asked you know. Why was the websocket scheme um uh is a separate scheme and uh the history there is basically you know. Ws and wss are examples of what not to do more than what to do in this case and so yeah. We should probably just treat it as a different, different method on the same https resource that we have thought about previously.

H

It would be different if we're talking about quick transport, I think, but now that we're taking this path. This is a much easier decision in my mind,.

B

All right does anyone else have anything else to say.

A

As just jumping in as chair, I'm not seeing any opposition to going with https here so um well and haven't seen any on the issue. So unless someone wants to speak up now or on the list, I think we can assume consensus on this one and move forward with https. For now.

B

Well, it does not look like we have any opposition to this. So, let's move to the next issue.

B

Oh that's so this is now so. The previous three issues were very important for interrupts those are less critical, but still important. So the first, the issue 10, is mostly reconfirming uh what we already have, uh which is we made at some point decisions that web transport would not expose stream ids, and this was originally in quick transport. That idea made the completes in web transport over quick. That idea made some sense because the ids are consistent, but when you add http- and you add proxies in the middle, this makes no sense whatsoever.

B

So uh I just wanted to reconfirm that we are not going to expose stream ideas as a part of the protocol or application surface.

B

Does anyone object to.

B

K

Oh hello, um so I made the original ticket, or at least nikhil uh works to make her make that uh original try to expose them um for some context. We wanted to know the um the ordering between different streams, so we wanted just a way of knowing the creation date more or less um and possibly, and that that's the main thing that we wanted.

K

um That's not necessarily possible now with um uh hp3 transport uh with pooling specifically, so it's one of those things that we'll just have to drop or add us a custom way of doing that within web transport.

B

uh Yeah, so I was thinking whether it is possible to preserve some way in some way to preserve ordering, without necessarily preserving uh the idea of uh the exact stream ideas like without making them referenceable and one question I have when you're interested about ordering. Do you care about relative ordering, or does this ordering need to have no gaps.

K

Well, initially, we did the thing with every odd and even one was a different type of stream.

K

Just as a way of you know, saving bytes right like instead of having an explicit header um and we were abusing the fact that quick streams are monotonically, increasing like it just plus four, every uh of the same stream type um again, that's not possible, because now, if there's a gap with web transport, you don't know which protocol you don't know if it was an http request or you don't know if it was for a different web transport session.

K

um So at least that use case doesn't work um and yeah there's no way of knowing how many streams may have been created before your stream. uh If there's packet loss or whatever um our solution is just to add a header on top of every stream and that may actually just be acceptable, just tell applications to define their own stream ids.

K

B

B

L

Hi, can you hear me yes hi? This is uh janine robert mozilla. um I just wanted to make sure that I understood that we can still, I think, ordering is going to be important in the api, because uh message framing is going to be typically hard to do for javascript developers and get it right. uh For instance, uh I I've experimented with two different ways to um wrap something we get asked.

L

A lot is how to wrap a sort of a web socket like api on top of web transport, and I pretty much see two ways to do it. One is to map it to a bi-directional stream. If you want header line blocking and the other one is to wrap it on the transport itself, where you're sending text messages as individual streams and then then, if you then send, for instance, like a large data blob, you would send that as a separate stream as well.

L

So, in those cases it seems that preserving the ordering of sending on the receiver side is critical, and I heard some things that sounded like uh I just want to clarify if we're still able to guarantee that order, or is there something in http.

B

3 that prevents that I think, if you send an explicit different streams, you're explicitly guaranteed, that order will not be preserved in which you reserve, because uh otherwise you would just have had offline blocking. If you wanted to preserve order.

L

I I'm that's you're talking about the data within the streams, but I mean the creation order of the streams. I was very happy to find in the quick spec. It says that successive streams of each type are created with numerically increasing stream ids and a stream id that is used out of order results in all streams of that type, with lower numbered stream, ids also being opened and the way I interpreted. That was, if that's true, then, if we can carry that forward to the api, if you do 408 on transport.incoming streams, you're guaranteed.

L

As long as you don't wait for completion of these streams, at least their appearance on the api should be in the order they were sent. Is that.

B

Not true, I don't believe this is true, because one since this is multiplexed, you don't know if the streams in the middle are even your streams uh and two.

B

This is a steelhead of line blocking, because if it was imagine you're doing http, you would be able to receive an entirety of http request with higher stream id and process it and send response before the previous stream, if, like only the previous stream, was lost. So from that standpoint it doesn't really make sense.

L

Well, but you can solve it, it won't be blocking because all you have to do if you get a stream idea, that is that skips that's newer than you expected yeah. The receiver can then create the underlying streams for the missing numbers and if they come in later, provide data.

B

Sure, but you don't have, as I said, the first reason is you don't have guarantees that those are web transport.

L

Streams but all right yeah, I don't know the networking stack that well so apologies, but uh if someone else could clarify that that'd be good uh yeah. I.

A

I can attempt to clarify perhaps um so. The the the important property here is so in quick, the uh when the an endpoint decides to create new streams every like subsequent call to. I want a new stream, we'll give it a higher id. um But if I'm sending, let's say let's say for bidirectional streams as the client I get like stream id12 and through my id 16, I can open stream id 12 and put some data in a packet and then in the next pack. It sends 16, but the packet with 12 can get lost.

A

So the fact that I send them in a given order doesn't mean that they'll be received in the same order on the other side and so from a web transfer perspective.

A

um I think if what you're you want is for the api to enforce this ordering, as in you know, give me the next stream will let's say, and you receive 16, but not 12, and then you say well, I'm going to wait for 12.. I think that would really diminish the benefits of quick, because the point of using multiple streams is that a loss on one stream doesn't mess up another stream.

A

So I would like speaking as an individual here, be pretty much against having that uh be a blocking relationship in the api, because I'm sure that there are applications who absolutely don't want that they prefer to get the data for stream 16. Even if 12 is on the way and might come in a bit later, uh okay and then, if sorry go ahead,.

L

Okay, but we're talking about api now and I think the api doesn't force the application to choose, because you can, you can for a weight over the incoming streams and you can decide at the apple level whether you want to download each file to completion before beginning the next one or you can download them all in parallel.

L

So the the the point at which you expose these things, since you mentioned the numbers, uh if you, if you received 16, you can create a sort of dummy 12 uh that if you were to wait for actual data on it, it might never arrive, and then you can start you create both 12 and 16 and you'll start receiving data on 16., and it becomes an app problem if it wants to wait for 12.

A

So you you could do that. What I would say is uh like so there's a bit more details by victor on the issue, but given that we're now over http 3, which is a multiplexed protocol and some of these streams might be non-web transport- we're going to need a new namespace because we're not going to want to expose the number 16 to the web transfer application, because that could leak some information about the other things that are happening under the canal on the connection.

A

And so then the question becomes, if we're all in agreement, that we don't want a blocking relationship in the api, then the question becomes: do we add this new numbering inside webtransport? Or would we just do what luke was saying? Which is we don't offer? This and applications are free to at the start of their stream? Just add a number in there and that way they can know the ordering at that level.

A

I would be inclined to given that this is pretty simple to do to push this on to applications, uh because not everyone might need it, but that's just my personal two.

A

Cents- and I see martin is behind me in the queue.

H

Yeah, so um I think you covered off most of that uh unless you want to make the application aware of the existence of things that are not for it, then you you have to accept the fact that when you get the 16 you, you know that 12 exists, but you don't know what, and so you can't signal that, because it might be for something that you don't want. The application even existed in the first place. So you can imagine you have it.

H

You have your stream of streams and you can have some some sort of tombstones where all of the the streams that that existed, but won't for you exist, but then you're still leaking to the application that they they did exist and I don't think, that's appropriate at all.

H

um Based on what we've discussed um the other way to get around this one is potentially the notion of a dedicated connection for the purposes of a given application, and at that point you can start to expose these things, because that dedicated application knows that every single stream is for it.

H

You can make that stream available to the application, even though you haven't seen any of the contents of that stream. Yet so the problem that we have with with this particular case, where you have multiple users of the same connection, is that you don't know whether this particular stream is for this particular application until you've seen the contents of it and you know it exists, but you don't know anything of the contents yet, and so that's where you end up, I I think at this point yeah like, like david, said just let's just make it.

H

The application developers lives harder, it's kind of a cop out, but it's you know that's where it's at. Unless we want to go to dedicated streams that.

A

Is bernard you're next in queue.

E

Yeah, um just just to say, I think it's worth having an issue, because there are a number of cases where uh really it is the application's responsibility, and this is one of them. It's not always clear, like people seem to be in some cases relying on things that they really need to do in the app.

E

You know an example of that also is in the api, at least we're arguing about whether to make acts visible or not, and we decided not to because it's really up to the app to handle datagram reliability, uh but not everybody's been clear about that. So uh jani vartanzi your question. If you're, if each stream is a message, you really are asking for quick to give you an unordered reliable service, and that means you do have to as an app uh have to take care of ordering yourself is the best friend on our servers.

A

uh That makes sense uh who should take the action item to follow an issue here. I think, even if we don't change the protocol, we should have text in the document that specifies which properties we're getting such as or which ones were were not. For example, the fact that streams can arrive out of.

A

A

Just uh victor, since he's the editor victor, can you take the action item to uh to follow that issue? Please.

B

Isn't this essentially like just this issue, but.

A

uh So you're you're super weak right now. Yes, this is essentially this issue, but this issue is in w3c. We probably want one in uh an itf as well. No.

B

I ever filed it as a atf issue. You should attend.

A

Oh, my bad! uh Yes, sorry all right, then we're good. Thank.

B

A

L

uh Yeah, so I just want to get clarification. I think um we're happy to work on the api part of it, but the uh I just want to understand that the language I found in the quick spec then that the under streams of lower numbers than the ones I received are not opened in http 3..

L

Is that not a property anymore?.

B

They are opened, but before we receive data we do not know which web transports they belong to. ah It's the same issue. Actually next issue is very similar in nature. I think, of course, yeah.

L

But then, um but once once you receive data and then you know which web transport it is at that point, an api could decide to open lower number uh streams for.

B

Web transport at this point here introduce point of fly head of line blocking because, if you don't have stream 12, but you have stream 16, you know that stream 12 exists, but you, if you require data from stream, 12 now you're ahead of line blocking.

L

But only the application would require data.

B

No http stack needs data to know how to write a signal.

L

But if that never arrives, then what part of web transport is blocked.

B

uh If right now, nothing, if we require streams to go in order, then all of the future streams would be blocked, because we would have to wait for every stream to order them.

A

If I might jump in with a clarification here,.

K

A

um So genevar it sounds like the feature you're asking for is hey. I received this client initiated stream and I'm happy with it, but it told me that there is some other stream that I haven't received, yet that I want to send something on if, as the server you want to send data on a stream before you've received anything on it, then why not just use a server initiated stream like the whole point of in quick in the quick mindset of client initiated stream?

A

Is that they're the kind of stream where the client's going to speak first, so in http? That's a request, for example, um and uh since web transport offers also unidirectional streams? um I think we have enough arrows in our quiver here to not require this specific feature of. I want to send first in the other direction of a stream initiated by my peer.

L

Well, I I think the model here is that uh when you create a stream every all the data inside it is um order guaranteed right. So, but if I have data- and I want to split it up into two streams- then I'm not lo- I'm no longer guaranteed the order of delivery of that data, because I could send a few bytes followed by. I could send a lot of bytes, followed by a few bytes, but the surfacing of those two on the client side.

L

It would be beneficial if we could surface them in the creation order, and I don't see that we cannot- and I don't also don't see why that would lock anything and the goal here would be to provide because framing is hard in javascript and streams.

L

As far as I understand that stream ids is an implement, an implementation of framing that applications could benefit from where we could give them these guarantees, and I don't I would like I'll work on clarifying- why I don't consider that head of line blocking, but if there's something in web transport that would block from that. uh I guess we can look at that and future issues.

A

Okay thanks, I I think if you could write up an example of like how the application does this, and maybe we can take it offline, because this sounds interesting, but um it's maybe it deserves its own conversation that might take a bit longer.

L

Right, I have a fiddle actually of I'm mapping a web socket api to e to uh web transport. I can post in chat for people who are interested.

A

Cool yeah, but please do and but if you can add as much detail as possible on the on the issue, I think this will be. uh We can keep the conversation going there to make sure we we understand what you're trying to accomplish and see if there's a need for a change here at webtrends or not great thanks all right. Thank you. uh Luke.

K

Hello, uh so I think at a higher level. This also applies this uh next issue. We're gonna cover reset stream uh is a in my use case um we're using quick for uh mobile uh platforms, or at least we have uh so android app, ios, app whatever uh and then for web transport. We want to, I mean for web support. We need to use web transport uh there's just a few quick features that we want to use or have been using that just don't map nicely to web transport stream.

K

Id is one of them uh where, on native platforms, we could use the quick stream id, because it is exposed the application, if we're using raw, quick and reset and some other other things that are more connection oriented. So that's, maybe just a higher level question is web transport trying to expose uh the quick api, or is it trying to expose a subset of it and if we're trying to have a subset of it, then a lot of these discussions can be. You know what subset.

B

uh My intuition is that it definitely has to be a subset, because I don't think we can implement like 100 percent one-to-one, perfect mapping, or I mean we could, but some of the things would have to do.

B

uh I'm not completely sure are 100 worth it, uh because quick has a lot of semantics, and some of the semantics are entirely dictated by the fact that quick is a transport protocol uh that has to handle all of the transport issues uh and but our goal is in general to implement as much of it as possible and expose as much of the semantics of quick, especially semantics, relating to ability to have things that are unreliable and avoiding head-of-line blocking as possible.

B

uh That's that's my general view. So I think the question is definitely on what's upset and the general answer is as much as possible, but we might have to make some compromises here and there.

K

B

Worth mentioning for.

K

Example that http 3 does use stream id. So if you wanted to build http 3 on top of web transport wouldn't be possible again, I don't know if that's a an issue. It's just a lot of these little things that you're limiting the application to.

B

Yeah, so I I guess- and this does leave us with general question- do we want applications to emulate that or do we want to emulate that for by ourselves.

B

And for stream ideas specifically, I feel like it is much easier to leave it up to the application with the general philosophical uh principles that some application would not needed and if they don't need it, you're just wasting bites uh and if they need it, it is not that hard to build a system. That does that, as, as you said, you just said the header in front.

B

So that's at least my perspective.

B

uh Is there anyone else? Thank you. Alan.

G

Yeah I'll go quick cause. I know we spent a lot of time on this issue. I I just I I feel like that.

G

Maybe there's an opportunity where you know we're hearing potentially from people who are using apps or written applications and they're telling us what they want from the transport and we are maybe ignoring them, because we want to build sort of the simplest thing sort of the batteries, not included version and and apps end up implementing a lot of stuff on top, and um I just want to encourage, listen to the use cases and consider maybe adding some things in the transport layer.

G

I don't want to add tons of complexity, but you know if this is one like, I don't think you're wasting a ton of bytes if applications are like so much more is possible. If you can tell us about the order of the streams in my session, then you know I would not be opposed to building that potentially into the protocol, and then you know people will use it if they need it or not. You know anyway, it's just.

G

We should be listening to what the users are asking, so they don't, every app doesn't have to implement it over and over again.

A

All right thanks alan tim. uh If it's about this issue, let's keep it short and we're cutting the um the microphone after tim here. So we can move on to the next issue, but go ahead. Tim.

F

Sure yeah, it is about this issue, but um I just wanted to say in the in the webrtc world we came across the same problem with uh and we ended up solving it with a very lightweight protocol that, like which just slots in the header, uh in your the beginning of a stream and just like, puts a couple of things in that lets. The api label a stream. So it can actually manage um that kind of behavior and I it turned out to be really really useful for the things I'm doing so.

F

I kind of if something like that was possible without having too big an overhead I'd go for.

F

B

uh Thank you, so I don't think we have arrived at the definitive agreement because well, there is definitely agreement that we cannot expose a quick stream id. But, as a question now becomes, do we want to sorry uh do we want to simulate uh something like quick uh stream ideas- and I think that's uh probably worth discussing more but probably at a later date, uh and probably not for the most immediate, interrupt interrupt draft uh issue. 31 is very similar in its root.

B

Cause is, if so, we currently expose reset stream to the application, uh and we expose the reset stream error code and the problem is, you can receive and process reset stream before you receive the data on the stream that associates the stream with a web transport session, and the question is well first of all: do we want to expose recent stream and make it reliable and the second of all? If we do that, uh how do we do that.

B

And I was wondering: if do people have opinions on.

B

B

uh Oh, I should mention, since there are actually three options there is, do not guarantee reliability or actually no you. You have to expose the fact that the stream was reset, but.

B

Anyone has anything to say for the microphone.

H

Martin, not just for you victor, I'm going to argue for the the first option, because that's far less complicated, it's exactly in the spirit of reset stream, and the only problem here is that if someone is mixing web transport streams and request streams and one of those gets reset and the header doesn't get through the header that allows the the server in this case, to identify this as a web transport stream for this particular web transport or a request or what have you, then it doesn't get to do anything with that stream.

H

It's just a stream that appeared and and had to go away again and that's fine. It just means that in those cases where the sender or the the endpoint that creates streams, uh creates a stream and then resets it too fast, then the other side never hears about that stream and and that's okay, that's perfectly fine.

B

uh Right, uh thank you. Luke.

K

So um from an application level, uh if I'm using web transport, I create a stream, I could write, I don't know a megabyte of data and then uh use the the web transport api and and close it with error code five.

K

um I I think it's it's a reasonable expectation for a developer that that error code five is going to make it to the other side, um especially if you've written data to it. But what really happens is if there's any packet loss, um that code could be dropped. uh The reset stream could win, the reset stream frame could win and because none of the data was received on the stream.

K

uh Actually more specifically, the first data frame wasn't received on the stream um you'll, just that it'll just be dropped completely, so it seems like a a poor, maybe not a poor api, but maybe something that could lead to problems where application developers just expect these codes to be reliable, but just due to packet loss they might not be, and I don't think that's an api. We want to.

B

Expose is it specifically about the reset code error code being reliable.

K

Yeah, I think it's just the code being reliable. I think the well and the fact that a stream existed.

K

um I guess this goes to the id question as well like does the receiver need to know that a stream even ever existed, um because if you reset a stream and if you receive a reset stream- and you never receive data for it- you wouldn't know what protocol it was for. As you would never know, it would exist.

B

Under third martin.

H

But one because this is physics right and so physics states that uh if you, if you use reset stream for this purpose, you don't get to learn about the code sometimes and that's just how it works.

H

And so the question is whether we we build an additional facility into the protocol in order to carry these messages or we consider the option for those people who absolutely absolutely need this to have a dedicated connection and get these messages, because that's the only way that I can see of getting these these messages through reliably and yes, you're going to lose your error codes. Occasionally too bad.

B

Can you hear me.

M

B

Okay, uh because for some reason saying that my id is gone, my question it I would say that it is possible to just make it so racist dream. Miracles always arrive if you're not pulling your connections and to some extent that's a solution.

H

I was going to say there is an option here that that does work potentially and that is to reserve uh reset stream error codes for web transport.

H

uh It gives you some ambiguity if you have two tabs in the browser sharing the same transport and you get two different web transports to each of those different tabs on that same connection, then, a reset stream will propagate to neither tab, because you can't allow cross tab communication. Like that.

H

That's the only case I can imagine being a problem.

B

Yes, but that's against the built case, because if you have only one.

N

B

Or yours yeah, that doesn't, I feel like we should regardless reserve some space for web transport error codes uh and the reason for that is so that we can distinguish web transport error codes from http error codes. Regardless of what we're doing.

B

L

Never all right, sorry, my audio is back here yeah. I just want to echo the um I think we're going to have to find some way to make these apis based on this um a little more predictable and I'm hopeful that we might be able to do so.

L

At the ipi level, but it seems like this particular one it would, uh if there's a way to, I guess, if, once you get a newer stream, you might know that there was one an earlier one that could have been reset, for example, that never existed, and but the semantics here bother me a little bit and it sounds like they're embedded in a protocol that you can reset something you can initiate something and then pull it back without the recipient ever knowing about it and that's going to cause a jump in sequence, numbers or is it too late to?

L

Is that true or is or can the read sequence number be reused in this case where it was reset before sending any bytes.

B

uh No, but as as we mentioned before, reset takes it out of a stream space for hd underlying http connection, but it doesn't, but that space doesn't really exist for individual.

A

A

All right uh and and just to add- because I saw this in in the in the chat in one of the chats- um I think just conceptually and fundamentally quick streams are not ordered. uh The fact that in quick they have a stream id that is sequential is an implementation detail of quick.

A

Maybe at the end of the day, we just need to accept the fact that they are not ordered, and that is like quick does not provide this property to upper layers and web transport does not provide this property to our higher layers.

A

um I think at this point and let's move on, I don't want to spend too much time on this specific topic, um but if there is a need for this, I think uh it would be nice for someone to articulate what the use cases that would clearly benefit from this, because, since quick doesn't offer this property for us to add this property into web transfer would be non-trivial and, as with most things, we don't want to add complexity unless we have to.

E

Can we move on to the next issue? Victor you want to keep going uh one second.

B

Yeah, I I think we're yeah. I think we should move the rest conversation to mailing lists and github. uh So this is uh so there isn't uh issues 28 and 29 are roughly the same issue, but from different perspective.

B

uh Basically, the observation is: if we is the question, do we require client and server to buffer incoming streams if they come they're associated with a web transport session? That is not yet known uh and the ants the? Basically, if we answer yes, we can let the client open streams in parallel with making establishing web transport session, which would cut down on latency and similarly uh this it is unclear how to make server streams work without doing that.

B

So I think we should buffer in both directions, uh but I was wondering if people have opinions or anything to scientists, better uh bernard.

E

Yeah, I I agree: um we've encountered this in other things, such as weber, dc and buffering, is a good idea. The only thing to keep in mind is you might want to have limits on the buffer. That's that's about it.

B

Yeah, that's I assume like as long as you don't read past the beginning of the streams, you would get flow control blocked on all of those.

B

Streams uh does anyone else have anything else to say.

B

uh Yes, we might want to limit number of streams. This is a different issue which I think is currently not uh uh here. uh Yes, that's true. uh The there is a separate issue for in general. How do we limit the number of streams uh so next slide.

B

uh Oh, this one is an interesting one and it comes from proxy so uh assume uh that, like you, are connected to a reverse proxy and the traverse proxy is connected to a back end and you receive a go away from a back end, meaning that roughly you want to indicate somehow to the application, and now somehow your reverse proxy should indicate to the application that the to to the clients that the session is being trained and it will go away soon.

B

The question is: how do we do this, and do we want to support this in protocol.

B

Do people have any thoughts on that.

G

Alan I'm trying to I'm gonna say something that martin can't disagree with. I I don't know um so. I just want to say that this is a very it's very important that we find a solution to this problem, uh because we have essentially something very similar to web transport running today uh and the application that uses it.

G

You know they have a sequence of streams that we do this over h2 today they have a sequence of streams that belong sort of as a transaction, and they need to await like when they're back-end or one of the interview meeting proxies starts draining. They need a way to we need. We need to a signal like please don't start any more new work here, but and wrap up what you're doing, but don't prevent the creation of new streams that were needed in order to complete sort of the transaction that were associated with that session.

G

So uh I I don't have a concrete proposal here, but I foresee, I think you know sending something like a go away: type frame on the connect stream of the web transport session being an adequate solution, but I'm hoping to hear other ideas. But I just want to highlight. I think it's an important issue.

B

All right, uh martin.

H

I think I'm going to agree with alan here. um It's the way that we've been conceptually our way is that new requests stop.

H

But this is not your requests, because we're talking about something that is it's it's like the next level down, and so, um when the way that I would imagine this working similar to how alan's proposed it, I think would be that the go away at the h3 layer says no more requests please, but you can continue to create web transport streams associated with existing web transport sessions.

H

Within the sessions, however, you're going to need a way to say, stop making new streams, and so then there might be a need to have some sort of uh thing like allen said on the connect stream, saying, stop making new streams and that might that might be the way to solve it. I don't actually know if that makes sense, as opposed to just giving the application some ability to to build that. That capability itself, though not enough detail yet.

B

uh Does any so, it sounds like we in general agree that we should solve this problem somehow, uh but we need to decide on specific solution and we should probably do that offline next slide.

K

B

Yeah, so this is uh so issue. 33 is roughly currently we when we have a connect stream when it gets closed or reset. uh This indicates that the web transport session is completely gone and all of the streams belonging to it must be reset, and the question is whether we should keep that semantics or whether we should uh remove it or relax it.

B

So the streams can continue to drain, even after it's closed and from my perspective, I think that semantics of everything completely going away is useful because in particular imagine you're a web application and you have a browser tab and you have an object. That's a client object.

B

uh If you, you want to be able to hard close the entire web transport session, because if you close the entire tab, there is no more data to flow. Like everything is gone, so you should be able to throw out entire web transport session uh without uh needing to do anything like a train.

B

uh But I do one understand that people might have different opinions on this uh and if you have different opinions, uh please uh uh go please say talk as to mike yeah alan.

G

Yeah, so I'm I raised this issue after I implemented or mostly implemented last week, and I found I did not need in my implementation to track all the streams that belong, which streams belong to which session sort of inside the kind of transport stack for any reason other than this reason.

G

uh So you know, but because I need to reset them when the connect stream goes away at sort of the library level. uh I would have to like keep an extra list of things which I'm and maybe sort of offer that the higher level would probably already have that and if the browser tab is going away, it can also reset those streams.

G

um So I mean I mean I see the advantage of just like. Yes, it's tied to the lifetime of connect, and I can just nuke this one thing and everything else goes away, but I don't know sort of just pushing somebody has to track that and and where? Where do you push it?

G

And I don't know I I I never know if bringing this up is an argument for or against, but if you liken this at all to the way that push works, uh you know sort of the the independent stream can go away and the life of the dependent stream is not tied to it. It was in speedy and in early drafts of h2, but then that requirement was removed and so you're allowed to sort of destroy the the parent thing and then the the child things continue with their own life.

B

I can kind of see this argument.

B

I guess the question is so. I definitely think that the browser should close uh reset the connect stream. uh It is not clear to me whether all implement we, we could relax that requirement on non-browser implementations because, as you mentioned,.

B

For the reasons you've described because now I'm thinking about uh uh how it would work in our implementation and uh like I I can see the similar thing, uh look.

K

I just want to bring up similar to a previous issue that only the creator of the stream knows that it's associated with a connection, um so it seems like whoever created the stream should close it whenever the connect stream is closed, uh otherwise, you're left in this case there might be a dangling stream that you know the other side doesn't know it's supposed to be associated with this now defunct session.

B

Yeah, I agree, and especially given that we consider things like buffering. uh You might end up in this weird situation where the connect stream is entirely created and destroyed, and now there is this like web transport stream. That is buffered and does not belong to everything and, like.

B

B

Yeah lucas makes a good observation that if we allow uh staying streams, past uh destruction of connectstream, uh that makes us less able to rely on extending connectstream for like random control semantics like sending girl ways, uh which is one thing we discussed.

B

uh So is anyone actually in the queue right now, because I, if you're, not in the cupless yeah, uh so I think for now we should keep it as is, uh and I don't want to strictly close this issue, because uh I won't to see how I will feel about it after I actually implement it.

B

uh But for now let's keep the requirement that everything gets reset once the connect stream is closed.

B

Available uh the question is: how do we talk about pooling and support negotiation for http web transport over http free pulling, and we have at least three proposals uh option. One is, I think, what uh is currently in straft, uh which is roughly we defer this entire problem to the clients and, if you're, a client, uh you should know whether the server supports bullying uh and if the server does not support bullying.

B

It will turn your request away, and this is a fairly simple model, but the problem is that it puts burden on all clients to know whether support server supports cooling or not, and the failures in non-support pulling it's fairly uh of is basically almost fatal. Well, it's not fatal. You can handle it, but uh there is option two, which is a settings negotiation uh in which both server and client agree on whether connection is a connection entirely dedicated to one web transport session.

B

If it's a regular http connection that supports web transport or if it doesn't support web transport at all- and that is described in pr25- uh and there is also proposing to have a limit on max web transport sessions- and you can just set it to one if you want dedicate it- uh and I don't think this actually entirely- does anything, because while it prevents you from pulling cloud transport with other web transport, it does not tell you anything about pooling web transport with regular http requests, but that's another option that was discussed on the issue, uh and so uh I am personally uh somewhere.

B

I I was originally wrote, pr25 and then I was convinced that option one uh is probably is much easier, but now that people have brought up that the client might not necessarily know what it's doing. I am more inclined to do option two again, uh but I do wanna know what people's opinions are on this issue.

B

uh Let's go into the queue alan.

G

Yeah, so I will I was the one who wrote the max web transport session thing and the issue, and I think I've since retracted it. I think it's a good idea so, um but I I don't think one is either. I think we need something like two where uh the server can sort of declare what it's going to support.

G

um I think pr25 is it's sort of weird: I'm not sure that the client needs to be as involved and sort of like agreeing on what to do right, like the server either can handle http and web transport at the same time or it can handle only web one web transport thing or it can handle multiple web transport things.

G

um But it seems like that, if the client, you know the client's going to make a decision about, doesn't even want to try to pool, and then it can look at the setting it got from the server and decide if the server doesn't allow pooling, then the choice choices made for it. So I'm just not sure that the design 25 it might need some more massaging there, but I think I'm more in favor of option. Two.

B

So to explain the reason 25 requires a client to signal intent. Is you want to avoid a situation where the client connects to a server and the server is basically ion supports only one web transport protocol and nothing else, but the client expects to be able to send regular http streams, uh and from that standpoint you want to avoid that. uh You want to know the client that it can't use a connection for that, uh but yeah. I understand that uh bernard.

E

Yeah, I also would like to speak for option two. I think option one would be just uh particularly if it's linked to other things in the api, like what stats you get. I just think it would be very awkward and I think option two is a lot cleaner.

B

uh You're third, uh thank you. uh Yotaka.

B

uh uh Could you repeat this again.

M

Can you hear me.

B

Okay, now we can hear you.

M

uh Yeah, I I don't understand why the client need to uh send their intention to the server, because the the client in any case need to wait for the first settings frame so that the client can do a decision making with the server support and we have developers in the intention or client's intention. So that I don't.

M

I don't know if the the the we need to have our settings from that client to the server.

B

uh I think I I think I agree with you. I that is a detail. We will need to think through more but yeah we might be able to get rid of the client signal and reduce client to only support does not support web transport, and then the server can have both pulled and allow pulling and dedicated mode.

B

uh Thank you. uh Anyone else have any any opinions for the microphone.

B

B

O

ah It works. Do you hear me yeah.

B

O

Yeah, you will need a client indication if he wants to to use that transfer or not if you want to separate http, 3 connections and transport connections to the same origin.

O

So if you want to, um if you, if you don't dedicate from a application that you want a separate connection for hd uh for http, 3 and transport, then you basically can pull them on the same one. You cannot um and a server only wants to support one of them. uh It's it's complicated.

O

I I'm not really sure uh if you want to have a server that uh listen to the same port and have the same origin and actually want a separate connection for transport and http 3 and builds the application that doesn't uh that allow polling. That will be the case. If you understand me.

O

B

Not I yeah, so the reason I want to add dedicated mode for the server is that there are web applications. There are developers who want to run only one exactly one application on their server, so it's kind of like you cannot send regular http traffic to the same connection, but.

O

But you want to have the connection to the same origin, with the same port uh on the http 3 and only transport web transport.

B

O

In that case, if application is not built to disallow pooling, uh you will need to indicate. I want to open this connection only for http 3, and I often want to open this connection only for web transport. Otherwise, the browser don't know where to send the data yeah that doesn't matter yeah we can.

O

I can try to explain that in a little issue,.

B

uh Sure uh yeah, uh the issue has much more discussion by the way I think it does that's did there is a lot of discussion on the pull request about whether we need that uh so, oh everyone is welcome to check.

B

In thank you, oh martin, you're. Next.

H

I'm I'm gonna come out pretty firmly uh against having having an explicit, dedicated flag.

H

This decision to to use http 3 means that when you make a connection you're making an http connection- and there are numerous other options available for the server to not say, accept, http requests or not accept other web transport sessions.

H

On the same connection, now, I think probably option three is okay in that sense, but um simply saying uh I'm not going to accept http request is kind of not really in the spirit of actually of using http, and so we have 421 and that will allow a server to do things like uh say, I've got a certificate for this thing, but I'm not willing just to speak for it, and you have the option of putting your web transport endpoints on a different origin, and I don't think that there's any reason why that would not work for anyone, because of the way that this is going to integrate into the security model.

H

I don't think there's any reason why you need to have the same ostensible origin for the the the web pages, the the web transport connection. So I'm sort of struggling to to justify even having a dedicated thing from the server indication, and I support utaka's point about the the use of web transport from the client side.

B

B

I can see the argument for like not needing to make it dedicated to http for not needing a separate feature to reject http requests when you can send four to one, because if you're sending http requests, you already are where you're sending them.

B

uh The question is: yes, it's more interesting the question of uh uh whether you allow pulling web transports and uh whether the server should be able to indicate that it wants to do that or not because the client currently can- and it is not clear whether the server needs to be able to signal that or not.

H

Yeah, so I think that the key point here is um resource management from the server perspective and so having a maximum number of sessions and potentially having things like. The maximum number of streams for each session would be would be useful controls to have here, but having the the level of dedicated not dedicated with http without http.

H

It is not really consistent with any of the other design decisions that we've made and probably unnecessary as well.

B

uh I agree so I feel like uh oh uh eric kinnear.

H

Eric eric conanza.

D

Well, I I just I just wanted to to I, I think the idea of having you know mac sessions and maybe max streams in session and stuff will make sense. I just wanted to clarify my understanding of what you're saying, which is it's not even so much that this is about being quick versus http, but rather we're saying someone who controls the endpoints, for this is able to set up endpoints that will respond to requests for web transport sessions or for http resources as they choose, and that doesn't need additional, explicit signaling in web transport.

D

The protocol, because, if you wanted it to go, if you wanted to say, I only will answer things like this, then only answer things like that is that kind of what you're saying.

H

Yeah I mean if you, if you wanted to make sure that you only ever got web transport uh request to a particular server, then only provide web transport links as it were to that server and then there's a good chance that that's all you'll get and if you do happen to get an http request, you can send back what is it the 406 method not not supported, or what have you.

D

D

B

uh It looks like we don't have anyone else in the queue uh it sounds like. We should continue discussion on the issue. Everyone is very much welcome to comment uh and I would say, strongly encouraged if you have an opinion. Please do it's issue 34 on github.

B

uh So- and this is the final issue we're not going to discuss here- is uh datagram flows uh and specifically the syntax to encode them and the reason where- and this is very similar to server initiated stream ids, but fortunately there is already a dedicated draft in which we can discuss that, and the draft is a musk working group which meets at the same time as this working group except tomorrow instead of today.

B

So if you have opinions on that matter, you're strongly encouraged to come there to to go to attend, admitting knitting and I think that's it for web transport over http 3. uh There are some issues related to pulling, which I did not go over, because uh I think at this very point in time we should get version without pulling uh sort out the easier issues before we talk about how we do things like research management in pooled web transport sessions, and with that by hand it back to the chairs.

E

D

D

All right, we have what appears to be functioning audio.

D

Can we go to the next.

D

Slide all right so we'll make this pretty quick. One of the main goals here is to mirror what we're doing for h3, so everything that we just talked about and decided upon or make progress on. Hopefully, we can inherit here one of the things that we'd brought up in the past as a do. We need this. How much do we need different fallbacks?

D

That sort of thing uh was what happens when quick or really udp is probably the more likely thing to struggle with firewalls initially um is blocked, and so we know that there's going to be some networks where quick doesn't work and that may be because of a misconfiguration that may be, because nobody really expected udp traffic to do anything um that may be somebody who's deliberately trying to say quick does not work here, because I don't want it because of x, principled stand, but we know that there's going to be some places where quick is blocked and our use of quick for http traffic for requesting resources in general falls back to http 2 and does that over tls and tcp, and so the question becomes.

D

We can deploy quick and have this fallback plan for http and web browsing. What do we do for web transport when this situation occurs? Next slide.

D

Please so we have a couple of different choices. um One choice is just have it fail. If you try to connect and quick is not a thing, then you don't get web transport.

D

Another option that's been brought up and discussed a bit is to require you to bring your own callback. So that means something like websockets. Would we want to implement web transport on top of websockets?

D

uh We've already been talking in this meeting about doing websockets over web transport, so we could maybe do websockets over web transport over websockets there's all sorts of interesting layering that happens there. It seems as though there's also a bit of an aversion to trying to map web transport on top of websockets, um which I think is is probably well-founded, and the third option is to fall back to running something like web transport, but over hdb2 uh next slide. Please.

D

So in looking more practically at how we would actually do that, and is it even worth doing web transport, the framework, uh which is that kind of first document that isn't the mapping over h3, defines a set of capabilities, some of which are required and some of which are optional.

D

um The kind of design philosophy behind trying to bring web transport to hb2 is make sure that we can still do all of the required things and as many of the optional things as possible, um but over h2 and obviously the the big difference here is that brings with it tls and tcp.

D

That removes the ability to be unreliable. That brings in some ordering guarantees, which previously we did not rely on and likely should not.

D

The end result of this is everything. That's required is still there, those optional ones aren't um the question becomes. Is that useful, and is that something that's worth spending time on so to the next slide?.

D

The next couple of slides talk about a couple of key design, approaches that I think would be worth taking um and- and this is something where I think we're looking for feedback of. Are these the right uh statements to make? Are these something that we want to do as a working group or not? uh The first one is, if you require an optional feature to make your use case successful.

D

That's totally fine! So if you say I'm really interested in web transport because I want unreliable datagram based, um you know not unordered packets, where I want to send this from point a to point b, and I need that and I absolutely I will take my toys and go home.

D

If I can't have it, then that's totally fine and you should be able to express that when you go to create your web transport session, you should say these are the web transport features that I require, um even if they're optional in the framework I'm uninterested in having a web transport connection.

D

If I can't have this um it's worth noting that, because we think that quick and and or udp is going to be blocked in some percentage of situations for some percentage of users, you are likely leaving them uh kind of high and dry, and so you might want to provide. If you say I have some other alternative, I can fall back to some existing thing. Then that's totally fine! You should be able to do that next slide.

D

The next step of that is is say, you're really interested in this unreliability, um but you you're not willing to say I don't want it at all. If it can't be unreliable, I'd rather have something that works. Okay, even if it's not my preferred option, um and so the second principle here is: you should always know what you got so generally we're saying this is better than not having anything, but you still want to know.

D

Maybe I'm going to make a different decision about how much I'm willing to send I'm I'm worried about kind of over committing. If I'm, if I'm unsure that that you know I might create excessive amounts of buffering, so you may want to adjust your behavior slightly uh based on what's available. But beyond that um you know. If, if you'd rather have it and it's and it's better than nothing, then you should know that you're in that situation and be able to adjust your behavior accordingly next slide. Please.

D

The third and last principle here is that web transport over h2 should look very, very similar to web transport over h3 and so we'd like you to be able to have a single api to interact with us, we'd like to solve a lot of the issues that we just spent a significant chunk of time talking about to wherever possible map. There uh map their resolutions on to this.

D

So this is not a a proposal to make web transport be done all over again for h2, uh simply the the deltas that are required in order to make it work as a fallback um for h2. So as part of that now that we've tried to leave the great transport zoo, we've rewritten the previous dock, to match pretty much exactly what's in h3. So next slide. Please.

D

So, in order to do that, um we've pretty much lifted most of what's in h3, uh it brings over web transport, datagrams and web transport stream um and there's the header block that had been in the streams is, is no longer present. For now we can discuss that as needed if there's use cases that need it, but fundamentally it's trying to match what's there so next slide.

D

Please- and I think the the the real question here is, it seems as though there's data that shows um some significant percentage of networks, we're going to see issues when, when using quick and we'd want to be able to to fall back to something doing it over h2 seems like a you know, not necessarily preferred, but strictly better than having nothing at all.

D

The current shape of how it is is something that we're clearly flexible on having adjusted it several times to to match what the current needs are. um So I think the the main question that we'd like to ask the working group is: is this something that's that's worth doing? Do we agree that applications that you know can't can't live without the things that they get from?

D

Having quick underneath should be able to express the things they can't live without, um and similarly are we uh in agreement that that modeling it after web transport over h3 with you, know, kind of a minimal delta? If possible, is a reasonable strategy to.

A

A

Go ahead, bernard.

E

Yeah, um since the interim meeting, I think I've I've gotten some information which leads me to believe that web transport of http 2 is a good idea. Just speaking for myself, one thing I learned previously if you'd asked me what the fallback strategy was. I might have said that websocket stream api might have been part of that, and basically that was a what wg streams api on top of websockets, and so I would have advised developers hey, you can create a wrapper, make it look like web transport but use web sockets.

E

My understanding is that work on that is not continuing and so that the implication for developers is they'd have to potentially write their apps twice without web transport of http, once they'd write it to the web sockets api with messages and once they'd write it to web transport, and that's very, very painful.

E

So I know also development experience with the messaging api of websockets has not been all like great lack of back pressure, so my sense is the developers I talk to. They want web transport and they would prefer one api to having to write two different. Very two. Very different.

A

Apis go ahead. Martin.

H

I'm trying to read the chat, isn't it wonderful? So um I think that your requirements are absolutely spot on yeah. I- and I think that bernard's point here is exactly the the point that's been made by myself and my colleague for a while now, which is that, if we're going to build this thing, we're going to build a tcp thing or it's not going to be any any good. So from from that perspective, I think this is. This is great work.

H

From the perspective of the technical aspects of the draft design, I threw a few things in chat. I have serious reservations about the approach that you're taking here, um and it may just be that it's 5am in the morning- and I haven't slept for a very long time, but I think that we can probably simplify this.

H

Maybe it might not be a strict simplification, but having all of the uh web transport associated streams and datagrams all packed into the one stream might be a better design because trying to integrate this with the h2 stream state machine and manage the impedance mismatch between the h2 states and the quick state you're trying to replicate, probably not going to work very well. uh Just as an example. Reset reset stream doesn't work the same way in both protocols, and so you can end up with some problems.

H

So I'm not really all that comfortable with the idea of adoption at this point, but at the same time it's absolutely the right work to be doing, and I have no problems with the people doing the work. I have every expectation. This is going to be good, but I'd like to see it just go and have some more discussion about the technical side of things before we go any further. Thanks.

A

Thanks, martin, um I'm all well, I put myself in the queue, but also so jumping in us chair. We have three minutes left, um I'm getting a sense from the comments so far, and what also I've seen from the w3c that um there's interest in this work. uh So our our main question for the working group today is um so what we chose to do for this session is take as much time as we wanted for should be we're transport of http 3 and then as time permits.

A

If we have spare time at the end, leave some for http 2.. We think that that might be a good mechanism going forward where we keep doing that and that might lead to like us adopting this document or another document for this same um question. So we want to ask the group: does that seem reasonable to people? Are we okay with uh discussing the idea of doing web transport over something that's over tcp as long as it doesn't get in the way of where transformer http 3.?

A

uh So if, if you have a problem with that, please like join the queue now and tell us what you think um we're going to keep going through the queue. But if you have technical questions about um eric's proposal, please take those to the list we're going to focus on whether we want to be discussing this in the working group and if whether or not people are interested in working on a variant over tcp.

A

So I'm not no utah. Please go ahead.

M

Comment on the bananas comment so that we are still working on with socket stream. That's all.

A

Okay, thank you. uh Jonathan.

N

um Yeah, so um I was commenting on that here too. My uh I'm a little concerned that um how much you know? Yes, there's a percentage of endpoints that don't support, uh won't, have quick working, but it's not a large percentage. So I'm a little concerned how much the code that implements this won't get exercised.

N

um So you're, which is um you know hdb2, is you know well deployed, and you know that's that you know all exists in this, but whereas this is new code in a multi-click world, um so that's which might leave a possibility for lingering bugs, including vulnerabilities.

N

So maybe this is actually a comment to the w3c and it needs to be. You know at the very least, uh javascript api. That says I don't care. If I do quick, I need for testing purposes. I need to run this and then pretending that I only think I can do is um wave sockets over hd web transportation would be two, but I just I think this is something that we need to keep an eye on, to make sure that this code can get well exercised.

A

So thanks totally agree. uh One point I'll just say in response is that my understanding of where this would be needed is not for um cases where the endpoints don't support web transport, because I expect that anyone who is interested in web transport will support over http 3. But it's for networks that block udp as eric was saying from chrome, we're, seeing like somewhere between 5 and 10 of networks that completely block qdp, and if we're saying that we have close to even five percent of um web transport traffic.

A

That goes over tcp as opposed to quick that should um uh handle that code.

N

Path, testing! Right! That's that's true, but I mean I guess my the problem is that the um that that that 10 doesn't include the web developers talking to their own web servers so when they develop their applications using web transport, they're not going to exercise that path and might suddenly get surprising things happening to them once they deploy and that 10 of people start accessing their website. So there needs to be some way that they could make sure that works.

E

N

A

E

You david, uh the five to ten percent, is weighted towards enterprise, so it's actually much higher if you're an enterprise app it's more like 15, is what we're seeing 15 to 20.

A

Cool all right, so we're we're at time. Folks, um specifically for this discussion. It clearly sounds that there's interest in discussing this, I'm not seeing any opposition to discussing this, but it sounds like adoption. It might be too early to discuss adoption. So what we're gonna say is: let's keep discussing this on the list.

A

uh Let's uh folks, please follow issues on uh so the individual draft is on github, so please follow issues there and we'll keep uh seeing how this goes and we're gonna say that it's in scope to be discussing this I mean, after all, it is in our charter and we'll keep allocating as time permits time in our upcoming interims and uh itf sessions. uh But we'll we'll kick the can down the road a little bit for adoption and bernard.

A

Unless you have some parting words, I think that's all folks, thanks everyone for coming and see y'all will probably have an interim session before the next atf, we'll figure out details on the list. Okay, all right! Thank you.

G

A

A