IETF
webtrans@jabber.ietf.org
Friday, July 30, 2021< ^ >
javascript:window.alert('hi') has set the subject to: IETF 110 WebTrans WG Meeting
Room Configuration
Room Occupants

GMT+0
[18:14:36] lpardue joins the room
[18:14:40] lpardue leaves the room: Disconnected: not-well-formed
[18:14:47] lpardue joins the room
[18:31:34] Meetecho joins the room
[18:45:07] David Schinazi_web_226 joins the room
[18:45:07] Paolo Saviano_web_808 joins the room
[18:45:07] Bernard Aboba_web_592 joins the room
[18:45:12] Bernard Aboba_web_592 leaves the room
[18:45:23] Bernard Aboba_web_390 joins the room
[18:46:01] Mike Bishop_web_480 joins the room
[18:47:05] meetecho-alexamirante joins the room
[18:47:37] meetecho-alexamirante has set the subject to: IETF 111 WebTrans WG Meeting
[18:50:14] Sean Turner_web_272 joins the room
[18:51:46] Sean Turner_web_272 leaves the room
[18:51:59] Daniel Havey_web_330 joins the room
[18:52:04] Philipp Tiesel_web_947 joins the room
[18:52:53] Eric Kinnear_web_848 joins the room
[18:53:49] Yoshifumi Nishida_web_489 joins the room
[18:55:11] Philipp Tiesel_web_947 leaves the room
[18:55:16] Philipp Tiesel_web_612 joins the room
[18:55:56] Marc Petit-Huguenin_web_269 joins the room
[18:56:13] Lasantha Senanayake_web_716 joins the room
[18:56:43] Anatoly Lunin_web_373 joins the room
[18:56:59] Mayumi Ohsugi_web_108 joins the room
[18:57:10] tim costello_web_712 joins the room
[18:57:35] Cullen Jennings_web_593 joins the room
[18:57:58] francesca joins the room
[18:58:19] Takanori Fumeno_web_487 joins the room
[18:59:09] Martin Thomson_web_933 joins the room
[18:59:31] hta joins the room
[18:59:57] Carrick_web_207 joins the room
[19:00:02] Alessandro Ghedini_web_414 joins the room
[19:00:06] Carrick_web_207 leaves the room
[19:00:21] Carrick_web_953 joins the room
[19:00:22] Nick Banks_web_901 joins the room
[19:00:30] <francesca> sorry I am having problems connecting to the session...
[19:00:58] James Gruessing_web_761 joins the room
[19:01:28] Francesca Palombini_web_276 joins the room
[19:01:41] David Oliver_web_386 joins the room
[19:01:42] Jasdip Singh_web_346 joins the room
[19:01:47] Will Law_web_557 joins the room
[19:01:48] <francesca> here I am :)
[19:01:54] Sofia Celi_web_956 joins the room
[19:02:01] Dragana Damjanovic_web_353 joins the room
[19:02:01] Hiroyuki Goto_web_994 joins the room
[19:02:02] Victor Vasiliev_web_260 joins the room
[19:02:09] Victor Vasiliev_web_260 leaves the room
[19:02:11] Sofia Celi_web_956 leaves the room
[19:02:12] Luke Curley_web_823 joins the room
[19:02:13] Victor Vasiliev_web_248 joins the room
[19:02:21] Alan Frindell_web_937 joins the room
[19:02:24] Ali Begen_web_985 joins the room
[19:02:51] Jana Iyengar_web_445 joins the room
[19:02:51] Lucas Pardue_web_863 joins the room
[19:02:59] Luca Niccolini_web_551 joins the room
[19:03:02] Maxim Sharabayko_web_214 joins the room
[19:03:16] Timothy Panton_web_525 joins the room
[19:03:16] David Baldassin_web_278 joins the room
[19:03:29] Phillip Hallam-Baker_web_338 joins the room
[19:03:30] Bron Gondwana_web_118 joins the room
[19:04:25] Daniel Havey_web_330 leaves the room
[19:04:29] Daniel Havey_web_548 joins the room
[19:04:33] Mirja Kühlewind_web_405 joins the room
[19:04:43] Ian Swett_web_363 joins the room
[19:04:59] Daniel Havey_web_548 leaves the room
[19:05:03] Daniel Havey_web_287 joins the room
[19:05:23] <Martin Thomson_web_933> you don't need a jabber scribe
[19:05:25] Timothy Panton_web_525 leaves the room
[19:05:33] <Victor Vasiliev_web_248> what's a jabber?
[19:05:33] Zaheduzzaman Sarker_web_269 joins the room
[19:05:43] Michel Abdalla_web_252 joins the room
[19:05:51] Jan-Ivar Bruaroey_web_255 joins the room
[19:05:55] Marten Seemann_web_428 joins the room
[19:06:02] <francesca> jabber is integrated with the meetecho chat
[19:06:07] <Bron Gondwana_web_118> Everyone's on "jabber" :p
[19:06:11] <francesca> oops sorry meetecho didn't mean to ping you :)
[19:06:20] <Jana Iyengar_web_445> the person who gave you that vaccine shot
[19:06:30] <meetecho-alexamirante> and you did it again Francesca! LOL
[19:06:31] <Meetecho> No worries Francesca! I have alarms on a whole lot of keywords anyway :D
[19:06:45] <Meetecho> You'd be surprised by the amount of pings I hear every session!
[19:06:49] <francesca> I need that list, so I make sure to annoy as much as possible! :D
[19:06:53] Timothy Panton_web_799 joins the room
[19:06:57] Timothy Panton_web_799 leaves the room
[19:06:58] Timothy Panton_web_827 joins the room
[19:07:12] <Meetecho> :D
[19:07:28] Timothy Panton_web_827 leaves the room
[19:07:34] Timothy Panton_web_698 joins the room
[19:07:53] Daniel Havey_web_287 leaves the room
[19:07:57] Daniel Havey_web_522 joins the room
[19:08:00] Daniel Havey_web_522 leaves the room
[19:08:04] Daniel Havey_web_109 joins the room
[19:08:13] Timothy Panton_web_698 leaves the room
[19:08:18] Michel Abdalla_web_252 leaves the room
[19:08:19] Daniel Havey_web_109 leaves the room
[19:08:23] Daniel Havey_web_529 joins the room
[19:08:35] Daniel Havey_web_529 leaves the room
[19:08:39] Daniel Havey_web_557 joins the room
[19:08:45] <Alan Frindell_web_937> proxygen/mvfst has an experimental implementation but it hasn't interoped or been open sourced yet
[19:08:52] Daniel Havey_web_557 leaves the room
[19:08:56] Daniel Havey_web_574 joins the room
[19:09:08] Daniel Havey_web_574 leaves the room
[19:09:12] Daniel Havey_web_121 joins the room
[19:09:29] Daniel Havey_web_121 leaves the room
[19:09:33] Daniel Havey_web_278 joins the room
[19:09:48] Daniel Havey_web_278 leaves the room
[19:09:49] Xavier de Foy_web_874 joins the room
[19:09:52] Daniel Havey_web_174 joins the room
[19:10:06] <Victor Vasiliev_web_248> That's exciting to hear
[19:10:06] Daniel Havey_web_174 leaves the room
[19:10:10] Daniel Havey_web_182 joins the room
[19:10:20] <Victor Vasiliev_web_248> I was going to ask about that, since I know some people who want a C++ implementation
[19:10:24] <Carrick_web_953> @Jana haha
[19:10:24] <Lucas Pardue_web_863> there must be some downsides though right? :)
[19:10:24] Daniel Havey_web_182 leaves the room
[19:10:28] Daniel Havey_web_440 joins the room
[19:10:32] <Martin Thomson_web_933> c++ should be an anti-goal
[19:10:34] Daniel Havey_web_440 leaves the room
[19:10:38] Daniel Havey_web_668 joins the room
[19:10:52] <Alan Frindell_web_937> mt: I also like to live dangerously
[19:10:53] <Victor Vasiliev_web_248> It's the worst language, except for all others
[19:11:09] <Martin Thomson_web_933> victor: totally the wrong analogy, it's a terrible language, period
[19:11:28] <Jana Iyengar_web_445> shall we do emacs vs vi next?
[19:11:37] <Martin Thomson_web_933> sure, the answer is neither
[19:11:43] <Lucas Pardue_web_863> "I don't want to use HTTP" seems like a valid use case
[19:11:44] <James Gruessing_web_761> (the answer is Atom)
[19:11:46] <Jana Iyengar_web_445> pico for the win!
[19:11:53] <Victor Vasiliev_web_248> Of course no, all cool kids use Atom or VSCode
[19:13:41] Daniel Havey_web_668 leaves the room
[19:14:06] Daniel Havey_web_503 joins the room
[19:14:21] Maria Sharabayko_web_617 joins the room
[19:14:37] <Martin Thomson_web_933> eye chart
[19:15:23] <Martin Thomson_web_933> 14
[19:16:06] Kirill Pugin_web_797 joins the room
[19:17:19] <Martin Thomson_web_933> are we sure that people will do that buffering?  (we haven't done it yet; it seems OK for streams, but not necessarily datagrams)
[19:17:22] Mo Zanaty_web_774 joins the room
[19:17:36] Cullen Jennings_web_593 leaves the room
[19:17:44] Kyle Rose_web_958 joins the room
[19:17:53] <Luke Curley_web_823> yeah the buffering is just to reduce a RTT on connect
[19:17:56] <Martin Thomson_web_933> right, streams don't bother me, it's datagrams
[19:19:41] <Martin Thomson_web_933> this is the right answer.
[19:19:49] Daniel Havey_web_503 leaves the room
[19:19:51] <Mirja Kühlewind_web_405> actually not discussed ;-)
[19:19:53] Daniel Havey_web_802 joins the room
[19:19:56] <Martin Thomson_web_933> right
[19:20:06] Daniel Havey_web_802 leaves the room
[19:20:10] Daniel Havey_web_327 joins the room
[19:20:56] <Martin Thomson_web_933> chairs: the names of your draft repos aren't consistent, please fix that
[19:21:15] Daniel Havey_web_327 leaves the room
[19:21:19] Daniel Havey_web_453 joins the room
[19:22:07] <Martin Thomson_web_933> best effort  is what it's gotta be
[19:22:17] <Martin Thomson_web_933> no point in inventing something complex to make this reliable
[19:22:27] Daniel Havey_web_453 leaves the room
[19:22:37] <Alan Frindell_web_937> I'm not overly concerned about the reliability of the error codes in this case
[19:23:56] Daniel Havey_web_689 joins the room
[19:26:35] <Martin Thomson_web_933> MAX_WT_SESSIONS == 1
[19:26:48] <Martin Thomson_web_933> Luke ^^
[19:27:03] <Eric Kinnear_web_848> +1 MT
[19:27:29] <Luke Curley_web_823> yeah Martin that works
[19:27:36] <Luke Curley_web_823> much better than returning a 421 or something
[19:27:37] Maxim Sharabayko_web_214 leaves the room
[19:27:52] <Martin Thomson_web_933> Luke Curley: you need to dequeue yourself
[19:28:06] <Martin Thomson_web_933> Luke: yeah, that was my thinking too
[19:28:39] <Lucas Pardue_web_863> MAX_INITIAL_WT_SESSIONS
[19:29:14] <Martin Thomson_web_933> Lucas: yeah, probably don't want a new frame to go with this
[19:29:35] Marten Seemann_web_428 leaves the room
[19:29:38] <Eric Kinnear_web_848> If you're limiting to just one does it really matter if it's concurrent or not?
[19:29:39] Marten Seemann_web_336 joins the room
[19:29:53] <Martin Thomson_web_933> Alan: I think we can use the stream states to explain it
[19:30:11] <Luke Curley_web_823> the session is active while the corresponding QUIC stream is open
[19:30:21] <Luke Curley_web_823> so yeah both sides would have to agree when it's RESET
[19:30:24] <Alan Frindell_web_937> ok
[19:30:30] <Lucas Pardue_web_863> MT: was that a "yeah, agree" or a "yeah, no"
[19:30:31] Kirill Pugin_web_797 leaves the room
[19:30:35] <Martin Thomson_web_933> Luke: unfortunately, that isn't a complete answer, but I think we can work this out.
[19:30:41] Ian Swett_web_363 leaves the room
[19:31:13] <Martin Thomson_web_933> Lucas: I would prefer to try to do the concurrent sessions thing first, but I would be OK with a frame that managed the limit (that is more flexible, but more complex)
[19:31:20] Zaheduzzaman Sarker_web_269 leaves the room
[19:31:37] <Lucas Pardue_web_863> oh I see, "yeah, maybe"
[19:31:58] Jana Iyengar_web_445 leaves the room
[19:33:17] <Martin Thomson_web_933> there are cases where you can tell that your peer is busted for sure
[19:33:24] <Martin Thomson_web_933> so MAY error for 2
[19:33:32] <Alan Frindell_web_937> +1 mt
[19:34:12] <Alan Frindell_web_937> I think MAY error for 3 is ok too.
[19:35:21] <Martin Thomson_web_933> yep
[19:36:08] <Alan Frindell_web_937> Well, maybe not.  If the client sent a new stream, then closed the original, and they are reordered, that shoudn't be a connection error
[19:36:12] <Martin Thomson_web_933> SETTINGS_MAX_CONCURRENT_WEBTRANSPORT_SESSIONS
[19:37:02] <Dragana Damjanovic_web_353> +1 MT
[19:37:05] <Martin Thomson_web_933> Alan: a general rules is that a connection error cannot be generated unless the error condition is certain (that is, if you don't know for sure, you can't close the connection)
[19:37:28] <Martin Thomson_web_933> SETTINGS_MAXIMUM_CONCURRENT_WEBTRANSPORT_SESSIONS - you need an extra long name
[19:37:50] <Alan Frindell_web_937> so maybe 3 is strictly not an error where reordering is possible
[19:37:56] Maria Sharabayko_web_617 leaves the room
[19:38:00] <Eric Kinnear_web_848> Going ahead of settings is interesting if the settings would have limited session count - what happens if you get two CONNECT requests with :protocol webtransport and then later MAX_SESSIONS==1?
[19:38:15] <Martin Thomson_web_933> Alan: it might be an error, but that error might not be detectable by the recipient
[19:38:26] <David Schinazi_web_226> @EK then you reply with 421?
[19:38:29] <Martin Thomson_web_933> 1024 bits?
[19:38:38] <Martin Thomson_web_933> weird
[19:38:42] <Eric Kinnear_web_848> Ah fair
[19:38:58] <David Schinazi_web_226> I think Victor meant 1024 bytes but forgot the QUIC encoding
[19:39:00] <Martin Thomson_web_933> David: 400 series, not 421
[19:39:09] <Martin Thomson_web_933> definitely not 421
[19:39:16] <Alan Frindell_web_937> makes sense
[19:39:20] <David Schinazi_web_226> Ah right not 421
[19:39:25] <Martin Thomson_web_933> 429 perhaps
[19:39:48] <Mike Bishop_web_480> +1 to 429
[19:40:06] <Martin Thomson_web_933> we can still use capsules, just put them in DATA
[19:40:22] Lasantha Senanayake_web_716 leaves the room
[19:40:25] <David Schinazi_web_226> Indeed I'll go say that
[19:40:29] <Martin Thomson_web_933> This is more like CONNECTION_CLOSE
[19:40:42] <Mirja Kühlewind_web_405> are you on the right mic Lucas? there is quite some noise...
[19:40:43] <Martin Thomson_web_933> CONNECTION_CLOSE is "reliable"
[19:40:49] <Luke Curley_web_823> QuicTransport used to use CONNECTION_CLOSE for this purpose
[19:40:57] Nicholas Gajcowski_web_540 joins the room
[19:41:03] <Luke Curley_web_823> and it's something that didn't translate too well to HTTP/3
[19:41:54] <Lucas Pardue_web_863> sorry I mispoke David
[19:41:59] <David Schinazi_web_226> No worries :)
[19:42:05] Carrick_web_953 leaves the room
[19:42:15] <Lucas Pardue_web_863> was trying to be breif, and mangled it. Thanks for clarifying
[19:42:22] <Martin Thomson_web_933> what happens if you get other capsules on the stream after this one?
[19:42:24] <Eric Kinnear_web_848> We're talking capsules for h2 as well so capsule here probably makes sense too
[19:42:53] <Alan Frindell_web_937> +1 mt -- need to require a FIN after that?
[19:43:21] Lucas Pardue_web_863 leaves the room
[19:43:24] <Martin Thomson_web_933> yeah, the PR has that
[19:43:27] Lucas Pardue_web_624 joins the room
[19:43:27] <Martin Thomson_web_933> thanks
[19:44:19] <Lucas Pardue_web_624> @mirja I was either on wrong mic or the noise is bad because I'm on the wrong computer :)
[19:44:47] <Mike Bishop_web_480> Not everything; QPACK doesn't use frames.
[19:44:48] <Martin Thomson_web_933> This is effectively a frame that takes up the rest of the stream?  How is this any different than having a preface?
[19:45:21] <Alan Frindell_web_937> Now I forget, but it was awkward to implement as written
[19:45:42] <Alan Frindell_web_937> it also allows adding TLV frames at the beginning in the future?
[19:46:24] <Martin Thomson_web_933> *who* should limit connections?
[19:46:51] <Martin Thomson_web_933> how about everyone?
[19:47:32] <Martin Thomson_web_933> servers are less able to identify a group of connections from the same host reliably
[19:47:59] Nicolas Kuhn_web_757 joins the room
[19:48:02] <Martin Thomson_web_933> seems like this needs further study
[19:49:16] <David Schinazi_web_226> Perhaps we say MAY throttle?
[19:49:45] <David Schinazi_web_226> Yeah just mentioning that in some Considerations section SGTM
[19:50:29] Marc Petit-Huguenin_web_269 leaves the room
[19:51:52] <Mike Bishop_web_480> #1 makes more sense; allows for optional-to-understand extensions on the contexts.
[19:52:19] Taiji Kimura_web_426 joins the room
[19:52:20] <Mike Bishop_web_480> (more sense to me, anyway)
[19:52:51] Chris Wendt_web_189 joins the room
[19:52:58] Juliusz Chroboczek_web_515 joins the room
[19:53:10] <Lucas Pardue_web_624> register_untagged_context might be more correct
[19:53:15] lpardue leaves the room
[19:53:19] Jonathan Lennox_web_116 joins the room
[19:53:28] Adam Roach_web_681 joins the room
[19:53:43] <Luke Curley_web_823> what's an example use case for contexts?
[19:53:44] Harald Alvestrand_web_954 joins the room
[19:53:44] <Mike Bishop_web_480> Yes, kind of like the default VLAN on a switch port.
[19:54:02] <Mike Bishop_web_480> High/med/low priority datagrams, so you know what to drop if you must.
[19:54:12] <David Schinazi_web_226> Example use case is an extension that adds priorities
[19:55:51] <Luke Curley_web_823> so context is for hop-for-hop while the datagram payload is end-to-end?
[19:56:01] <Alan Frindell_web_937> context is end-to-end
[19:56:04] <Mike Bishop_web_480> Context is also end-to-end.
[19:56:06] <Alan Frindell_web_937> ish
[19:56:56] <Alan Frindell_web_937> if you wanted intermediaries to use contexts for prioritization then they'd need to be able to see them
[19:57:21] <Alan Frindell_web_937> We could probably steal some time from h2 for this
[19:57:29] <Martin Thomson_web_933> I'm increasingly of the opinion that datagram contexts are not a good idea
[19:57:46] <Martin Thomson_web_933> they are application-specific signaling, not generic
[19:57:47] <Luke Curley_web_823> yeah I don't really understand the use-case for contexts versus putting that data into the datagram payload
[19:57:54] <Martin Thomson_web_933> Luke: precisely
[19:58:05] <Alan Frindell_web_937> "Compression"
[19:58:27] <Mike Bishop_web_480> @MT, there are some decent arguments for them in, say, CONNECT-IP.  But yes, you could equivalently move this field into your application layer.
[19:59:10] <Martin Thomson_web_933> right, let's go there
[19:59:10] <Eric Kinnear_web_848> Yeah, we can move that to h3 datagrams in masque
[19:59:35] <Eric Kinnear_web_848> (Just wanted to understand a little more about the philosophy there, thanks Martin)
[19:59:41] <Alan Frindell_web_937> +1 to not half-implement
[19:59:57] <Martin Thomson_web_933> Victor isn't talking about half-implementing the underlying document (with option 2)
[20:00:16] <Martin Thomson_web_933> Saying that you aren't using context ids is still using it fully.
[20:00:24] <Luke Curley_web_823> context support seems like a layer on top of HTTP/3 datagrams for applications that want to use it
[20:00:36] <Martin Thomson_web_933> the stream ID was a solution for that
[20:01:05] <Eric Kinnear_web_848> (If we need it to make progress, feel free to steal some time from h2)
[20:01:13] <David Schinazi_web_226> Alan if it's quick you can go ahead
[20:01:13] <Alan Frindell_web_937> We did say that h3 work should be a priority
[20:01:58] <David Schinazi_web_226> Given that it's only one issue left I think it's reasonable to take the GOAWAY issue to the list
[20:02:42] <Victor Vasiliev_web_248> Yeah, I kinda wanted to point that out, but I think GOAWAY would basically result in "we need more time to think about that"
[20:03:20] Marco Schrieck_web_630 joins the room
[20:03:27] Magnus Westerlund_web_267 joins the room
[20:04:32] <Mike Bishop_web_480> UDP doesn't have packets, does it?
[20:06:45] Takanori Fumeno_web_487 leaves the room
[20:06:50] Takanori Fumeno_web_263 joins the room
[20:07:06] <Martin Thomson_web_933> the stream-related frames here all alter the h2 stream state machine in different ways, which is where this gets awkward
[20:07:13] <Jan-Ivar Bruaroey_web_255> Is Datagrams a target for H2?
[20:07:26] David Baldassin_web_278 leaves the room
[20:07:31] David Baldassin_web_629 joins the room
[20:07:32] <Martin Thomson_web_933> Jan-Ivar we need to carry them somehow, so yeah
[20:07:43] <Martin Thomson_web_933> Though only for WT, not generically.
[20:07:51] <Martin Thomson_web_933> Maybe also for MASQUE, I guess
[20:07:51] <Victor Vasiliev_web_248> There's an interest in datagrams over HTTP/2, since intermediaries can convert H/3 to H/2
[20:08:05] <Martin Thomson_web_933> Interestingly, capsules in DATA is totally portable to h2
[20:08:16] <Martin Thomson_web_933> ...and http/1.1
[20:08:19] <Mike Bishop_web_480> Are any of these generically useful for HTTP/2 independent of WebTransport?
[20:08:31] <Mike Bishop_web_480> Yes, DATAGRAM transport should be in Datagram capsules.
[20:08:47] <Victor Vasiliev_web_248> Yeah, I was thinking about how this is WT_DATA/WT_WINDOW_UPDATE away from being a full thing
[20:09:14] <Victor Vasiliev_web_248> I can also unironically point out that you can run this over WebSocket
[20:09:43] <Martin Thomson_web_933> Indeed, but we are defining something parallel to websocket, not aiming to layer on top of it
[20:09:53] Rui Paulo_web_416 joins the room
[20:09:57] <Luke Curley_web_823> looks like QUIC over TCP :p
[20:10:00] <Juliusz Chroboczek_web_515> I agree, it would be good to have a clear understanding of what all of this complexity buys us over WS over TLS over TCP.
[20:10:04] <Alan Frindell_web_937> luke: it is
[20:10:25] <Luke Curley_web_823> would QUIC over TCP be useful for non-WebTransport use-cases?
[20:10:34] <Alan Frindell_web_937> juliusz: multiplexed stream semantics?
[20:10:42] <Martin Thomson_web_933> Luke: perhaps
[20:10:48] <David Schinazi_web_226> We renamed HTTP/3 Datagrams to HTTP Datagrams because the DATAGRAM capsule allows you to send them over all versions
[20:10:54] <Juliusz Chroboczek_web_515> Alan, open multiple TCP streams?
[20:10:59] <Victor Vasiliev_web_248> Well, you can always layer whatever you want over WebTransport
[20:11:09] <Alan Frindell_web_937> multiples "streams"
[20:11:10] <Jonathan Lennox_web_116> If I'm an HTTP proxy am I allowed to drop DATAGRAM capsules?
[20:11:15] <Mike Bishop_web_480> Yes.
[20:11:29] <David Schinazi_web_226> @Juliusz one-TCP-per-stream doesn't work for server-initiated streams
[20:11:29] Mo Zanaty_web_774 leaves the room
[20:11:33] Mo Zanaty_web_891 joins the room
[20:11:58] <Victor Vasiliev_web_248> <not serious> It does, just proxy your TCP over TURN</not serious>
[20:12:01] <Martin Thomson_web_933> I don't like to think about fallback to capsules, but upgrade to native capabilities
[20:12:10] <Juliusz Chroboczek_web_515> Victor, ;-)
[20:12:40] <Alan Frindell_web_937> the core question is  - are h2 streams enough of a native capability to reuse them
[20:13:23] <Mike Bishop_web_480> @MT, does that suggest there should be a way to transport streams in capsules?  That would enable WT/H1, certainly.
[20:13:27] <Martin Thomson_web_933> the answer I would give is that h2 streams aren't good enough
[20:13:28] <Juliusz Chroboczek_web_515> Personal, uneducated opinion — let's forget that H2 ever happened, and use H3 with fallback to WS and HTTP/1.1.
[20:13:51] <Martin Thomson_web_933> fixing h2 streams to carry the necessary semantics isn't worthwhile
[20:14:35] <Alan Frindell_web_937> writing a new flow controller and stream manager on top of h2 doesn't enthuse me
[20:14:57] <Victor Vasiliev_web_248> Is flow control over TCP actually particularly complicated?
[20:15:17] <Martin Thomson_web_933> Alan is talking about having to manager inter-"stream" flow control.
[20:15:24] <Alan Frindell_web_937> raise your hand if you wrote h2 or quic flow control and didn't have bugs
[20:15:46] <Lucas Pardue_web_624> :i_love_you_hand_sign:
[20:15:48] <Juliusz Chroboczek_web_515> Alan, that's not fair !
[20:15:50] <Victor Vasiliev_web_248> I wrote one but I never tested it
[20:15:51] <Nick Banks_web_901> Alan, do you consider tuning a bug?
[20:16:10] <Alan Frindell_web_937> nick: perhaps not
[20:16:23] Ian Swett_web_121 joins the room
[20:16:23] <Martin Thomson_web_933> Alan, I might be able to say that, but you have to allow for "not done yet"
[20:16:32] <Nick Banks_web_901> We had a number of tuning related issues, but no functional bugs in QUIC FC
[20:17:00] Phillip Hallam-Baker_web_338 leaves the room
[20:17:07] <Nick Banks_web_901> At least no known bugs :D
[20:18:12] Ali Begen_web_985 leaves the room
[20:18:15] <Luke Curley_web_823> QUIC flow control felt complicated but kind of magically worked for me
[20:18:19] Ali Begen_web_133 joins the room
[20:18:28] <David Schinazi_web_226> Until we have more widespread deployments a lot of us are in "haven't found the bugs yet" territory
[20:18:59] <Martin Thomson_web_933> David: that is the baseline state, so maybe it's not so bad
[20:19:28] Ali Begen_web_133 leaves the room
[20:20:59] <Mirja Kühlewind_web_405> So turtles all the way down...
[20:21:17] <Victor Vasiliev_web_248> Flow control over TCP doesn't require connection-level flow control, and doesn't have to deal with async issues
[20:21:18] <David Schinazi_web_226> To the mic lines!
[20:22:41] <Juliusz Chroboczek_web_515> Does anyone understand what's the advantage of that over H3 over QUIC over UDP over TURN?  Especially in the case where the TURN endpoint is colocated with the server?
[20:23:03] <Victor Vasiliev_web_248> TURN directly?
[20:23:17] <Victor Vasiliev_web_248> TURN has a lot of problems, notably port exhaustion
[20:23:27] <Victor Vasiliev_web_248> It's also not a client-server protocol
[20:23:45] <Mirja Kühlewind_web_405> yes, what we need is adding one more protocol to the stack ;-)
[20:23:55] <David Schinazi_web_226> Given deployment models, we'll want this to live over regular QUIC since that's what everyone is shipping
[20:24:12] <Martin Thomson_web_933> the stream state machine in h2 is a nightmare
[20:24:27] <Alan Frindell_web_937> maybe its only ugly in rust
[20:24:45] <Martin Thomson_web_933> our implementation is C++, so you might see how we might be biased against touching it
[20:24:46] Nils Ohlmeier_web_665 joins the room
[20:25:05] <Dragana Damjanovic_web_353> :)
[20:25:06] <Victor Vasiliev_web_248> I actually don't remember us having a state machine
[20:25:16] <Alan Frindell_web_937> aha that explains some ;)  This could be the lever you need to justify a rewrite in rust then ;)
[20:25:28] <Juliusz Chroboczek_web_515> It looks to me like everybody is sharing my distaste for H2.  H3 is a breath of fresh air — are we really reviving the H2 zombie in order to meet the needs of some enterprise and academic networks, even though there are a number of UDP-over-TCP proxying technologies that avoid that need?
[20:25:38] <Martin Thomson_web_933> Alan: anyone who advocates for rewrites doesn't really understand engineering
[20:26:11] Marten Seemann_web_336 leaves the room
[20:26:15] Marten Seemann_web_141 joins the room
[20:26:17] <Victor Vasiliev_web_248> Well, everything is a rewrite, the difference is just how big is a thing being rewritten
[20:26:48] <Martin Thomson_web_933> Victor: rewrites "just because" is just a source of risk
[20:27:12] Taiji Kimura_web_426 leaves the room
[20:27:47] <Martin Thomson_web_933> porting h2 state machine to h3: let's take one of the worst parts of h2 into h3
[20:28:35] <Martin Thomson_web_933> or rather: let's forward port the bug in version 2 we fixed in version 3
[20:29:00] James Gruessing_web_761 leaves the room
[20:29:14] <Martin Thomson_web_933> backporting bug fixes (as Alan has suggested) is a good idea, but not if you have to keep bugwise-compatibility at the same time
[20:29:35] Milton Kashiwakura_web_337 joins the room
[20:30:49] <Martin Thomson_web_933> maybe not "no interest", but "insufficient interest"
[20:31:56] <Victor Vasiliev_web_248> I want to point out that TCP layer is also for DC-internal traffic
[20:32:23] <Lucas Pardue_web_624> I've pretty pessimistic about fringe h2 stacks ever supporting something that requires too much tinkering
[20:32:38] Marten Seemann_web_141 leaves the room
[20:32:42] Marten Seemann_web_678 joins the room
[20:33:38] <Martin Thomson_web_933> Alan: you are
[20:35:04] <Alan Frindell_web_937> +1 to DC use case
[20:36:07] <Martin Thomson_web_933> on top of HTTP, version agnostic, please
[20:36:20] <Martin Thomson_web_933> then we build HTTP version-specific optimizations
[20:36:35] Adam Roach_web_681 leaves the room
[20:36:36] <Dragana Damjanovic_web_353> you could also use H2 streams and build an application on top of H2 that implements/mimics H3 semantics, e.g. reset/stop_sending. In that case you can reuse flow control
[20:36:51] <Lucas Pardue_web_624> I feel like it would be easier to convince someone to let me consider considering "on top"
[20:36:58] <Martin Thomson_web_933> I have no real desire to use h2-native capabilities
[20:37:27] <Martin Thomson_web_933> a one-line change might be something that would change my mind
[20:38:18] <Mike Bishop_web_480> Is there actually a performance difference to running in H2 streams versus inside the body?  It's all in-order reliable either way; the rest is just spelling.
[20:38:38] Dmitry Afanasiev_web_925 joins the room
[20:40:20] Nils Ohlmeier_web_665 leaves the room
[20:40:25] Jasdip Singh_web_346 leaves the room
[20:41:32] Marco Schrieck_web_630 leaves the room
[20:42:50] <Martin Thomson_web_933> wow, if we are at the point where an extra hash-table hit is breaking things, we are doing pretty well
[20:43:19] <Alan Frindell_web_937> for rpc over http i've been theree
[20:43:25] <Martin Thomson_web_933> native QUIC might be better than webtransport in those cases
[20:43:26] <Luke Curley_web_823> ye Twitch is all HTTP/1.1
[20:43:35] <Luke Curley_web_823> we skipped HTTP/2
[20:43:39] David Baldassin_web_629 leaves the room
[20:43:53] <Alan Frindell_web_937> QUIC may be too expensive, at least right now
[20:43:53] <Martin Thomson_web_933> if the reason you are using webtransport is holb and similar, then going to TCP might be counterproductive
[20:44:51] <David Schinazi_web_226> I can see a common deploying of WT be h3 from client-to-frontend then h1 front-to-backend
[20:45:05] <David Schinazi_web_226> Since HOLB is much more impactful on the WAN
[20:45:05] <Mike Bishop_web_480> +1, David.
[20:45:28] <Martin Thomson_web_933> I'm leaning toward extended CONNECT with :protocol being the basis of the design for all of these.  Not that new methods are a big deal, though.  Pick one.
[20:45:40] <Victor Vasiliev_web_248> Yeah, H/1 or H/2 for -to-backend
[20:45:47] Milton Kashiwakura_web_337 leaves the room
[20:45:53] Milton Kashiwakura_web_224 joins the room
[20:48:20] <Martin Thomson_web_933> In practice, the bytestreams for each of these protocols will be implemented independently, so it won't matter THAT much that we unify, but we unify it all anyway.
[20:48:36] Nicholas Gajcowski_web_540 leaves the room
[20:49:16] <Lucas Pardue_web_624> +1 MT
[20:49:30] <Juliusz Chroboczek_web_515> What should I read in order to learn more about Extended-CONNECT?  Extra points if I can learn about the controversy.
[20:49:50] <David Schinazi_web_226> Cutting the queue after Mike
[20:49:55] <Martin Thomson_web_933> We can fix the status
[20:50:05] <Martin Thomson_web_933> proposed standard
[20:51:07] <Lucas Pardue_web_624> maybe you got confused with expanded connect? ;)
[20:51:46] <Juliusz Chroboczek_web_515> It's quite likely.  The last slide of the previous presentation was quite obscure for me.
[20:52:10] <Mike Bishop_web_480> RFC 8441
[20:52:52] <Juliusz Chroboczek_web_515> Thanks, Mike, it's on my to-read list.
[20:52:55] <Mike Bishop_web_480> HTTP approved it what felt like fairly quickly, and not everyone feels like it was "in the spirit" of CONNECT.
[20:53:33] <Mike Bishop_web_480> Plus CONNECT is the odd method out to begin with.
[20:53:34] Kyle Rose_web_958 leaves the room
[20:53:36] Nick Banks_web_901 leaves the room
[20:53:36] <francesca> Thanks David and Bernard!
[20:53:37] Will Law_web_557 leaves the room
[20:53:37] Rui Paulo_web_416 leaves the room
[20:53:37] David Oliver_web_386 leaves the room
[20:53:38] Xavier de Foy_web_874 leaves the room
[20:53:39] Alan Frindell_web_937 leaves the room
[20:53:39] Bernard Aboba_web_390 leaves the room
[20:53:43] Ian Swett_web_121 leaves the room
[20:53:43] Philipp Tiesel_web_612 leaves the room
[20:53:43] Dmitry Afanasiev_web_925 leaves the room
[20:53:43] Chris Wendt_web_189 leaves the room
[20:53:44] Mike Bishop_web_480 leaves the room
[20:53:44] Mayumi Ohsugi_web_108 leaves the room
[20:53:44] <Lucas Pardue_web_624> thanks all
[20:53:45] Harald Alvestrand_web_954 leaves the room
[20:53:45] Dragana Damjanovic_web_353 leaves the room
[20:53:46] Milton Kashiwakura_web_224 leaves the room
[20:53:46] Jonathan Lennox_web_116 leaves the room
[20:53:47] Jan-Ivar Bruaroey_web_255 leaves the room
[20:53:48] Daniel Havey_web_689 leaves the room
[20:53:49] francesca leaves the room
[20:53:53] Luke Curley_web_823 leaves the room
[20:53:53] Francesca Palombini_web_276 leaves the room
[20:53:54] Victor Vasiliev_web_248 leaves the room
[20:53:56] tim costello_web_712 leaves the room
[20:54:01] Mirja Kühlewind_web_405 leaves the room
[20:54:08] Eric Kinnear_web_848 leaves the room
[20:54:09] Mo Zanaty_web_891 leaves the room
[20:54:14] Rob Hamilton_web_557 joins the room
[20:54:14] Magnus Westerlund_web_267 leaves the room
[20:54:17] <Juliusz Chroboczek_web_515> Mike, if there's any extra explanation you think you can usefully give me, mail at jch@irif.fr.  (If not, no bother, I'll do my reading.)
[20:54:34] David Oliver_web_828 joins the room
[20:54:38] Hiroyuki Goto_web_994 leaves the room
[20:54:41] Juliusz Chroboczek_web_515 leaves the room
[20:54:55] Rob Hamilton_web_557 leaves the room
[20:55:04] Anatoly Lunin_web_373 leaves the room
[20:55:32] David Schinazi_web_226 leaves the room
[20:55:32] Paolo Saviano_web_808 leaves the room
[20:55:32] Martin Thomson_web_933 leaves the room
[20:55:32] Alessandro Ghedini_web_414 leaves the room
[20:55:32] Bron Gondwana_web_118 leaves the room
[20:55:32] Luca Niccolini_web_551 leaves the room
[20:55:32] Lucas Pardue_web_624 leaves the room
[20:55:32] David Oliver_web_828 leaves the room
[20:55:32] Takanori Fumeno_web_263 leaves the room
[20:55:33] Marten Seemann_web_678 leaves the room
[20:55:33] Yoshifumi Nishida_web_489 leaves the room
[20:55:33] Nicolas Kuhn_web_757 leaves the room
[21:03:01] Meetecho leaves the room
[21:03:38] meetecho-alexamirante leaves the room
[21:07:58] hta leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!