[00:15:03] brong leaves the room
[20:59:03] Eric Kinnear joins the room
[21:10:21] dschinazi@jab.im joins the room
[21:23:53] hta joins the room
[21:27:54] kbarabad joins the room
[21:46:11] mnot joins the room
[21:46:24] ek joins the room
[21:55:24] Cindy Morgan joins the room
[21:56:15] petereyee joins the room
[21:57:38] Dan York joins the room
[21:59:04] <ek> I can hear
[21:59:24] <ek> pleasantly faint
[22:00:10] <hta> elevator-music ugly, though....
[22:00:57] <hta> (wonder if elevator music would be more tolerable if they invested more than 10c in the speakers)
[22:01:14] tfpauly joins the room
[22:01:23] hardie joins the room
[22:01:36] Barry Leiba joins the room
[22:01:36] brong joins the room
[22:01:39] Jonathan Lennox joins the room
[22:01:50] <Eric Kinnear> https://etherpad.ietf.org:9009/p/notes-ietf-107-webtrans?useMonospaceFont=true
[22:01:56] msk joins the room
[22:01:56] Cullen Jennings joins the room
[22:02:03] xdf joins the room
[22:02:22] <Barry Leiba> Oh, can we turn the noise off?
[22:02:23] m&m joins the room
[22:02:30] Atarashi Yoshifumi joins the room
[22:02:30] adam joins the room
[22:02:35] <tfpauly> Yes please
[22:02:36] <dschinazi@jab.im> That's intentional so folks can test their audio, we'll turn it off before starting
[22:02:42] wseltzer joins the room
[22:02:51] <Jonathan Lennox> Does the music have a license such that the YouTube recording won't get a copyright strike?
[22:03:07] <Barry Leiba> Oh, is that "music"?
[22:03:09] <Jonathan Lennox> (Possibly it's butchered enough by WebEx audio that the copyright bots won't be able to find it…)
[22:03:23] <Cullen Jennings> we are obfuscating the audio quality such they will not get a strike
[22:03:28] <adam> maybe someone should just be reciting Hamlet's solioquy.
[22:03:36] <dschinazi@jab.im> The YouTube recording of the meeting starts when the meeting starts, and at that point I'll stop the muzak
[22:03:39] Peter Wu joins the room
[22:03:40] dragana joins the room
[22:03:43] <dschinazi@jab.im> You volunteering adam?
[22:04:07] <adam> I'm afraid it would be done in an incredibly morose tone if I did it.
[22:04:07] <Cullen Jennings> However, once we are recording, we could all sing happy birthday to someone
[22:04:09] Alexey Melnikov joins the room
[22:04:16] <adam> Think Alan Rickman as Snape.
[22:04:34] cabo joins the room
[22:04:41] Magnus Westerlund joins the room
[22:05:05] Martin Thomson joins the room
[22:05:07] <adam> With the number of folks we have joining these calls, it seems like we should have fairly good odds that _someone_ is celebrating their birthday
[22:05:14] afrind joins the room
[22:06:02] Steve Donovan joins the room
[22:06:07] Bernard Aboba joins the room
[22:06:21] <cabo> I hate to think I might get stuck in an elevator with this quality of music reproduction
[22:06:38] <Bernard Aboba> Can everyone see the slides and hear the elevator music?
[22:06:42] <Peter Wu> Bernard Aboba, could you change the background color of your notes in Etherpad?
[22:06:44] <Peter Wu> and yes
[22:06:48] Philipp S. Tiesel joins the room
[22:06:55] sfuerst joins the room
[22:06:58] lpardue joins the room
[22:07:01] <Peter Wu> (yes to both, can see slides and hear the elevator music)
[22:07:16] dontcallmedom joins the room
[22:07:24] <Alexey Melnikov> Recite RFC titles starting from RFC 1?
[22:07:35] <Peter Wu> clarification: can you change the background color to a brighter, more readable variant? You can do it in the top-right corner
[22:07:38] lsawyer joins the room
[22:07:43] xp29srs joins the room
[22:08:12] csperkins joins the room
[22:08:34] tim costello joins the room
[22:08:39] <cabo> dschinazi@jab.im: Since 2011, musak is a registered trademark of Mood Media <https://en.wikipedia.org/wiki/Mood_Media>
[22:08:46] <lpardue> Good evening everybody, I will be your jabber scribe for this session. If you have a question that you would like relayed from jabber to WebEx please send a message with the "mic" prefix
[22:08:51] <Jonathan Lennox> Whenever I need random text to read I usually go to en.wikipedia.org and read whatever today's featured article is.
[22:09:06] <Jonathan Lennox> Though today it is "virus" so that may be a poor choice
[22:09:07] Mirja joins the room
[22:09:22] <tfpauly> https://ietf.webex.com/ietf/j.php?MTID=m730d59fbafc6d18db1f05b3d9b759a18
[22:10:08] <wseltzer> so this is ersatz muzak?
[22:10:21] Greg Wood joins the room
[22:10:30] watson17 joins the room
[22:10:32] Godfred Ahuma joins the room
[22:10:35] <mnot> Please stop the music; it's not pleasant with encoding errors...
[22:10:35] Karl joins the room
[22:10:37] Ross joins the room
[22:10:51] <hardie> A reminder:  it is a pain to get a copyright strike on the IETF youtube channel; if you are playing music, please make sure you own the rights.
[22:11:23] Steve Todd joins the room
[22:11:30] <brong> mnot: it needs to be interrupted every 30 seconds to create the full hold experience
[22:11:38] Alissa Cooper joins the room
[22:11:40] <Martin Thomson> Bernard appears to have a corner of the screen occluded by a chat app or notification or similar
[22:11:44] <brong> so you think the call has been picked up, but not really
[22:11:48] <watson17> Anyone have the blue sheet link?
[22:11:57] <brong> https://etherpad.ietf.org:9009/p/notes-ietf-107-webtrans?useMonospaceFont=true
[22:12:14] spencerdawkins joins the room
[22:12:51] martin.duke joins the room
[22:12:59] Mo Zanaty joins the room
[22:13:04] <watson17> thank you
[22:13:05] Ben Schwartz joins the room
[22:13:07] <hta> we should get bert wijnen to record some out-of-copyright saxophone music for use in times like this :-)
[22:13:11] Chris Wendt joins the room
[22:13:27] Shuai Zhao joins the room
[22:13:31] Mike Bishop joins the room
[22:13:34] <Jonathan Lennox> s/out-of-copyright/creative-commons licensed/.
[22:13:34] <lpardue> Good evening everybody, I will be your jabber scribe for this session. If you have a question that you would like relayed from jabber to WebEx please send a message with the "mic" prefix. I will echo the slide number here e.g. "slide N"
[22:13:39] <lpardue> slide 3
[22:13:57] mglt joins the room
[22:13:58] <msk> "You have the right to remain silent  ..."
[22:14:17] xp29srs leaves the room
[22:14:18] <adam> "...and if you don't, then don't be a jerk."
[22:14:27] <lpardue> slide 4
[22:14:32] <Alexey Melnikov> msk: I like your version, but I also know that you like saying this :-)
[22:14:55] <msk> Alexey: I will encourage all of my WGs to use it.  :)
[22:15:05] <lpardue> slide 5
[22:15:08] <lpardue> slide 6
[22:15:11] ekr@jabber.org joins the room
[22:15:48] Zahed Sarker joins the room
[22:15:51] xp29srs joins the room
[22:16:04] <watson17> were we just told not to startle the iguanas? or am I hearing things?
[22:16:22] <Jonathan Lennox> watson: yes we were!
[22:16:25] <cabo> You heard it :-)
[22:16:48] kaduk@jabber.org/barnowl joins the room
[22:16:52] <adam> Always good advice
[22:16:54] nygren joins the room
[22:16:59] <lpardue> slide 7
[22:17:10] joshco joins the room
[22:17:17] <Bernard Aboba> Yes, please do not startle the iguanas.  They have been falling from the trees in Florida.
[22:17:19] carrickdb@jabber.hot-chilli.net joins the room
[22:18:21] <Bernard Aboba> Dominique Hazael-Massieux on W3C chartering of a WG for WebTransport.
[22:18:34] <Bernard Aboba> There is a github repo and so you can file issues and PRs there.
[22:18:55] <wseltzer> https://github.com/w3c/webtransport-charter
[22:19:04] <lpardue> slide 8
[22:19:21] <lpardue> what is IP for contribution to the charter?
[22:19:24] <lpardue> slide 9
[22:19:50] <lpardue> slide 10
[22:20:17] Chris Wendt leaves the room
[22:20:18] <lpardue> slide 11
[22:20:36] Chris Wendt joins the room
[22:20:44] <adam> Bernard Aboba: And, above all, do not collect fallen iguanas. https://fm1019.radio.com/blogs/matt-malone/florida-man-fills-car-with-frozen-iguanas
[22:21:09] <brong> you're not the boss of me, I can collect iguanas if I want
[22:21:12] <lpardue> slide 12
[22:21:36] <Martin Thomson> brong shows how tasmanians and floridians have so much in common
[22:21:36] Ben Schwartz votes for "WebSocket 2.0"
[22:21:50] <brong> TxSockets
[22:22:07] <lpardue> dwebsockets
[22:22:11] <lpardue> slide 13
[22:22:24] <Jonathan Lennox> quebsockets
[22:22:46] <lpardue> slide 14
[22:22:59] <watson17> Iguanas: not just for breakfast anymore
[22:23:32] <Ben Schwartz> We really need a name for the TLS core.  Maybe "TLS core".
[22:23:43] bhoeneis joins the room
[22:23:43] <msk> mt++
[22:23:47] <ekr@jabber.org> How about "TLS Core"?
[22:23:50] <ekr@jabber.org> LOL
[22:23:51] <lpardue> sounds complicated
[22:24:06] <Martin Thomson> how does TLS continuously validate consent to receive?
[22:24:11] <ekr@jabber.org> It does not!
[22:24:41] <Ben Schwartz> It does!  (TLS is the thing that includes TCP, which does this.)
[22:25:01] <ekr@jabber.org> Ben: depends how you define consent, one guesses
[22:25:02] <lpardue> slide 15
[22:25:06] <adam> Am I hearing a need for ICE? ;)
[22:25:23] <ekr@jabber.org> Consider the case where you instantiate a TLS connection to an IP that then goes offline
[22:26:02] <lpardue> slide 16
[22:26:21] <Ben Schwartz> By going offline I hereby consent not to receive.
[22:26:34] <ekr@jabber.org> Ben: the issue is that you're still sending data
[22:26:38] <ekr@jabber.org> Up to the TCP window.
[22:26:46] <ekr@jabber.org> because RSTs will not be sent
[22:26:49] <Martin Thomson> more to the point, what about when you give your IP to someone else, can you keep that TCP connection alive?
[22:27:11] <lpardue> slide 17
[22:27:44] <hta> I think one windowfull of data is regarded as "we can handle that". Just like the data you can send before circuit-breaker kicks in when using webrtc.
[22:27:46] <lpardue> slide 18
[22:28:21] merm joins the room
[22:28:35] <kaduk@jabber.org/barnowl> Clearly we need to introduce Victor to MPLS transport?
[22:28:38] Pete Resnick joins the room
[22:28:45] <ekr@jabber.org> Let's call this a VPN
[22:28:51] xp29srs leaves the room
[22:28:59] <lpardue> Victor's Protocol Notation
[22:29:04] <lpardue> slide 19
[22:29:05] <kaduk@jabber.org/barnowl> How does it protect my privacy, ekr?
[22:29:13] <ekr@jabber.org> It's virtually private, ben
[22:30:37] <lpardue> slide 20
[22:32:07] xp29srs joins the room
[22:34:22] <brong> Peter Wu: I'm not sure that both editing is working!
[22:34:27] <brong> I just got force reconnected
[22:35:32] <Martin Thomson> I also support adoption.  The requirements parts are mostly solid.  I have concerns about the composition of transports in the overview piece.
[22:35:45] <ekr@jabber.org> I also support adoption of this draft.
[22:36:38] <kaduk@jabber.org/barnowl> schmansport sessions?
[22:36:40] <hta> Session transport!
[22:36:41] <spencerdawkins> Is there an agreed upper interface for QUIC that is not HTTP/3?
[22:36:48] <carrickdb@jabber.hot-chilli.net> +1 on what Mark said
[22:36:49] <ekr@jabber.org> WebSockets/2
[22:36:49] <brong> SPLITTERS
[22:36:54] <carrickdb@jabber.hot-chilli.net> about "transport"
[22:37:07] <dschinazi@jab.im> Spencer: draft-ietf-quic-transport ?
[22:37:24] <mnot> @brong LOL
[22:38:03] <afrind> seems like you could prioritize datagram flows vs streams, and you probably want to
[22:38:21] <Martin Thomson> How this composes multiple transports might be an API question; I don't think of this as something that needs protocol design for.
[22:38:42] <tfpauly> Indeed. The protocols are just elements to combine
[22:39:04] <tfpauly> The composition of the transports below the API and how to fail between them is a bit more of a TAPS question (had to say it)
[22:39:18] <carrickdb@jabber.hot-chilli.net> alternatives to "transport": relocation, ferrying, shipment
[22:39:18] <Martin Thomson> I know that there will be a desire to have happy eyeballs or something for composition, but let's not go there.
[22:40:01] <nygren> Are there controls here on being able to prevent two datagrams from ending up in the same QUIC packet?  (eg, anti-affinity?)  Use-case would be for implementing FEC schemes.
[22:40:05] <msk> hah ferrying
[22:40:13] <spencerdawkins> dschinazi - I guess I'm not sure why you'd want to do QUIC if you've got HTTP/3, and why you'd want to do HTTP/3 if you've done a mapping on QUIC :-)
[22:40:21] <lpardue> between the plumbing and TAPS, you have Faucets
[22:40:28] <Jonathan Lennox> Clap your hands if you believe in ferries
[22:40:45] <carrickdb@jabber.hot-chilli.net> @lpardue I like that
[22:40:47] <tfpauly> @lpardue, well played
[22:40:57] <martin.duke> @spencerdawkins QUIC gives you uni streams and DATAGRAM, no?
[22:41:00] <Martin Thomson> nygren: ouch, but a good question
[22:41:06] dkg joins the room
[22:41:36] <brong> Jonathan Lennox: it's too soon for cruise ship jokes
[22:41:54] <lpardue> +1 nygren, please file an issue ;)
[22:42:05] <spencerdawkins> @martin, I'm assuming that you guys understand this better than I do ...
[22:42:09] <lpardue> slide 21
[22:42:35] <lpardue> ooh new slide deck, slide 2
[22:42:43] <brong> I expected a discussion on accepting it, but I guess that was taken as read!
[22:43:28] <lpardue> slide 3
[22:43:32] <mnot> This is less a "mapping onto" h2 and h3 than it is "attaching to" or "braiding into" or something. I.e., it's not being expressed in terms of the semantics of HTTP, it's being added to the underlying connection. Sort of like a parasite...
[22:43:36] <Martin Thomson> brong: I don't think that we can effectively assess consensus in this medium
[22:43:53] <Bernard Aboba> We'll bring the consensus question to the mailing list.
[22:44:04] <kaduk@jabber.org/barnowl> mnot: sorry, name's already taken draft-toomim-httpbis-braid-http
[22:44:08] <brong> Martin: yeah fair
[22:44:10] <lpardue> @mnot assymilated
[22:44:11] <dschinazi@jab.im> @brong: we'll take the question of adoption to the list, apologies I should have said that before moving on
[22:44:21] <mnot> "borg'd" would also be acceptable
[22:44:24] <brong> dschinazi@jab.im: all good :)
[22:44:27] <afrind> mnot: do you think of WebSocket also as a parasite?
[22:44:33] <spencerdawkins> @mnot, thank you, as always ...
[22:44:33] <lpardue> slide 4
[22:44:37] <mnot> it's a very simple creature, so...
[22:44:47] <tfpauly> Doesn’t make it less parasitic
[22:45:11] <lpardue> slide 5
[22:46:05] <lpardue> slide 6
[22:47:12] <lpardue> slide 7
[22:47:47] <Jonathan Lennox> How many RTTs is it to establish a WebTransport Stream?
[22:48:09] <kaduk@jabber.org/barnowl> The same number as the number of licks it takes to get to the center
of a tootsie roll pop?
[22:48:09] <lpardue> erm, slide 7 (again)
[22:48:36] <lpardue> slide 8
[22:48:41] <Jonathan Lennox> kaduk: no one knows because no one's managed to do it yet?
[22:48:49] <Peter Wu> Jonathan, according to the base draft it can be 0-RTT. Not sure about the H2 mapping
[22:48:54] <lpardue> slide 9
[22:49:34] <lpardue> slide 10
[22:50:12] <afrind> The server can piggyback WebTransport stream creation on the response to the CONNECT (0.5 RTT).  The client could optimistically piggypack a WebTransport stream creation with the Connect Stream, but that might not work.
[22:50:13] <lpardue> slide 11
[22:50:25] xp29srs leaves the room
[22:50:47] <Bernard Aboba> WebTransport API doesn't support 0-RTT currently.
[22:50:48] <lpardue> i give up, the numbers are screwed
[22:50:58] <tfpauly> It was a noble effort, lucas
[22:51:02] xp29srs joins the room
[22:51:13] <dschinazi@jab.im> The slide numbers on Eric's slides think different
[22:51:19] <Bernard Aboba> Numbers will be back to normal in the next preso
[22:51:43] <nygren> For datagram anti-affinity interface : https://github.com/WICG/web-transport/issues/109   (I assume this needs to start out as an API issue)
[22:51:43] <dschinazi@jab.im> The rest of the presentation slides use an increasing ordering
[22:52:00] <Peter Wu> slide 12 (lucas, please continue?)
[22:52:15] <Peter Wu> slide 13
[22:52:44] <Peter Wu> slide 14
[22:52:57] <hardie> This does not, of course, guarantee that they follow the same path, only that they go through the same hops for client, proxy, and server.  Other aspects of the path could easily vary.
[22:53:31] <nygren> Slides are unreliable datagrams.  Ordering not guaranteed.
[22:53:58] <lpardue> oh its not wtfheaders?
[22:54:17] merm leaves the room
[22:54:20] <kaduk@jabber.org/barnowl> No, those are for webtransport framing, not normal webtransport
[22:54:35] <Jonathan Lennox> Is it one connect stream per transport stream, or one connect stream per http/2 connection?
[22:54:36] <ek> WebTransportFraming, eh
[22:54:37] <Martin Thomson> mnot: you don't get return routing affinity with a pinhole driven by the client (what Eric is saying, I guess)
[22:55:00] <afrind> one connect stream per web transport session
[22:55:21] <Jonathan Lennox> So one connect stream can set up multiple transport streams?
[22:55:38] <Bernard Aboba> Yes.
[22:56:10] <Jonathan Lennox> What happens if you have a reverse proxy that wants to fan out different transport streams to different destinations?  That breaks the "transport stream follows the connect stream" model.
[22:56:32] <afrind> transport streams inherit the routing from the connect stream
[22:56:51] <Bernard Aboba> Jonathan - do you want to get into the queue?
[23:00:09] <afrind> wtheaders is for streams too, not just datagrams
[23:04:09] <Martin Thomson> Ben Schwartz: the setting is necessary in order to get the frame, as described
[23:04:22] <lpardue> the problem is the :protocol pseudo-header is a breaking semantic change that needs negotiation
[23:04:49] <Martin Thomson> the colon prefix on "colon-protocol" turns into an emoji for me
[23:04:54] <tfpauly> Which is fantastic
[23:05:00] <brong> :p tocol
[23:05:14] <Jonathan Lennox> I presume the concern here is using WebTransport for MASQUE - you don't want a server to leak to an unauthenticated user that it's a MASQUE server
[23:05:22] <Martin Thomson> colon-pro has a totally different emoji
[23:06:34] <Ben Schwartz> Jonathan Lennox: Yep.
[23:06:59] <Martin Thomson> lpardue: not having the streams visible at the transport layer feels wrong
[23:07:18] <lpardue> true
[23:07:41] <Ben Schwartz> lpardue: Its existence, yes, but every new value of it?
[23:07:47] <hta> Breakdown.s orry.
[23:08:02] <lpardue> but it feels like the debate we had with datagram flow id
[23:08:03] <dragana> lpardue: it is making it even more parasitic
[23:08:05] <brong> hta: if you want we can speak it to the MIC for you
[23:08:31] <hta> mic: where is the origin carried? And is it associated with the stream or with the connection?
[23:09:02] <dschinazi@jab.im> Lucas I'll ask you to read that after Eric's answer
[23:09:10] <lpardue> ack
[23:09:55] carrickdb@jabber.hot-chilli.net leaves the room
[23:10:46] <Martin Thomson> does CONNECT follow CORS?  I didn't think that it usually did.
[23:10:54] <lpardue> resuming slide numbers!
[23:10:57] <lpardue> slide 39
[23:11:11] <lpardue> slide 40
[23:11:19] <hta> what was the answer? I was messing with the sound system and lost it.
[23:11:20] <Eric Kinnear> Counting is hard 🙂
[23:11:25] <Martin Thomson> FWIW, I don't want to preflight these
[23:11:30] <brong>     * Eric: believe it is associated with the connect stream    * Victor: it's a header on the connect stream. Follows CORS.
[23:11:37] <Martin Thomson> hta: the answer was that the CONNECT carries the origin header field
[23:12:02] <hta> that means if we satisfy the overview doc's requirement on multiplexing multiple origins on one transport, we have multiple CONNECTs active.
[23:12:21] <Martin Thomson> yes, that would achieve a multiplexing and coalescing goal
[23:12:29] <Jonathan Lennox> Not just multiple origins, multiple paths, yes?
[23:12:49] <Martin Thomson> more likely multiple paths than origins
[23:12:54] Chris Wendt leaves the room
[23:13:00] Chris Wendt joins the room
[23:13:10] <Eric Kinnear> Yeah, if you're defining the endpoint as including the path then you end up with 1 connect per
[23:13:15] <lpardue> slide 41
[23:13:25] <hta> if I talk to geni.com and yahoo.com, and both are front-ended by cloudflare, do I need 2 transports to cloudflare or one?
[23:13:46] <Martin Thomson> hta: as a matter of client policy, you could allow one connection or two under this
[23:14:20] <Martin Thomson> one reason to avoid coalescing is to break linkability, but it's weak in the absence of IP masking of some sort
[23:14:33] <Jonathan Lennox> If I talk to my-ript-server.example/signaling and my-ript-server.example/media, how many connect streams do I have?
[23:14:42] <Martin Thomson> Jonathan Lennox: yes
[23:14:53] <lpardue> slide 42
[23:14:57] <brong> Jonathan Lennox: 7 streams
[23:15:16] <lpardue> slide 43
[23:15:16] <brong> (probably)
[23:15:28] <Jonathan Lennox> 7?
[23:15:34] <Jonathan Lennox> (Or was that sarcasm?)
[23:15:38] <lpardue> slide 44
[23:15:51] <brong> yes, guaranteed both ends are buggy and have reconnected many times
[23:16:05] <Jonathan Lennox> Oh, well, yes
[23:16:08] <Martin Thomson> if you are using HTTP for signaling, then you likely have no need for CONNECT for that
[23:16:11] <spencerdawkins> This is what I was hoping we'd talk about. I'm glad I didn't ask questions at the mike before.
[23:16:11] <brong> sarcasm doesn't work very well over text
[23:16:27] <Martin Thomson> but you might have multiple media streams in play, each with different paths involved
[23:16:40] <lpardue> slide 46
[23:16:49] <Martin Thomson> But that all assumes a particular question to what Victor is asking now
[23:16:56] <Martin Thomson> and the question we are hearing is very important
[23:17:01] <brong> can we just define QUIC over TCP/HTTP and then define this over QUIC only?
[23:17:09] <tfpauly> Noooo
[23:17:14] <Pete Resnick> :-o
[23:17:17] <Jonathan Lennox> Maybe I need my-ript-server.example/media/audio and my-ript-server.example/media/video.  Or even receive my-ript-server.example/media/Jonathan and my-ript-server.example/media/Martin
[23:17:18] <lpardue> slide 47
[23:17:30] <Martin Thomson> we could totally MASQUE this
[23:17:36] <tfpauly> Yes, yes we should
[23:17:48] <brong> encapsulate, encapsulate, encapsulate
[23:17:55] <lpardue> MAQUERIPTransport
[23:18:04] <Martin Thomson> then we do QUIC over HTTP/2 and we need just one protocol in this WG
[23:18:10] <mnot> So, to be clear, RIPT over WEBTRANS over MASQUE. Over H3. Over QUIC.
[23:18:13] <lpardue> slide 48
[23:18:17] <Eric Kinnear> It's all quic all the way down
[23:18:28] <afrind> over websockets
[23:18:30] <Martin Thomson> and at the bottom, TCP
[23:18:40] <mnot> over a crappy TLS VPN
[23:18:41] <spencerdawkins> @eric, I think it's headers all the way down ...
[23:18:53] <mnot> over sat
[23:18:59] <dschinazi@jab.im> MASQUE has a fallback to h2 so that could be the indirection layer :D
[23:19:00] <hta> Jonathan, you want _vp8._srtp._udp.jonathan.ript-server.example.com for ultimate CORS.
[23:19:01] <kaduk@jabber.org/barnowl> We don't need any room in the packet for payload, right?
[23:19:07] <Martin Thomson> "my PMTU is 7, what happened?"
[23:19:17] <mnot> That _would_ free things up, @kaduk
[23:19:18] <Pete Resnick> 🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢🐢
[23:19:20] <brong> it is sat here
[23:19:33] <spencerdawkins> @Martin, your PMTU is bigger than mine ...
[23:19:46] <martin.duke> @Martin Thomson with QUIC's 1200B limit there is a practical limit on all this encapsulation
[23:19:47] <nygren> Only a few days left to define WebTransportFrames over carrier pigeons.
[23:20:04] <Martin Thomson> martin.duke: not if you take Christian's suggestion
[23:20:09] <brong> turns out IETF last day silliness transcribes to virtual just fine
[23:20:20] <lpardue> slide 48
[23:20:26] <Alexey Melnikov> brong: indeed!
[23:20:28] <spencerdawkins> Or carrier pidgeons over WebTransportFrames ...
[23:20:30] <lpardue> 49*
[23:20:44] <tfpauly> Fragmenting pigeons isn’t pretty...
[23:21:02] <Jonathan Lennox> HTTP/3 over QuicTransport
[23:21:05] <lpardue> Pidgeon too big
[23:21:19] <Jonathan Lennox> Since that's the only "existing protocol over QUIC"
[23:21:38] <lpardue> you forget siduck
[23:21:39] <spencerdawkins> I believe I heard that the IESG and IAB aren't meeting after the last virtual session. Thank $Deity for that!
[23:21:39] <Martin Thomson> I wonder how many CONNECT implementations would actually handle a redirect
[23:21:56] <Jonathan Lennox> Or websocket implementations?
[23:22:05] <kaduk@jabber.org/barnowl> spencerdawkins: you heard correctly
[23:22:06] <Magnus Westerlund> Well, the PMTU over avian carriers likely require IPv6 jumbograms to utilize.
[23:22:09] <Alexey Melnikov> spencerdawkins: we are doing this on Monday
[23:22:22] <lpardue> slide 50
[23:22:37] <spencerdawkins> @Alexey, that was a wise move ...
[23:23:30] <ekr@jabber.org> What's the difference between 2 and 3?
[23:23:35] <lpardue> 1
[23:23:39] <Alexey Melnikov> spencerdawkins: Indeed. We should be well rested by then ;-)
[23:23:51] <Martin Thomson> ekr@jabber.org: how hard we think about it
[23:24:06] <lpardue> slide 51 (questions)
[23:25:00] dkg joins the room
[23:25:30] <ekr@jabber.org> For very large values of 2?
[23:25:45] <kaduk@jabber.org/barnowl> mnot, you're saying you don't have a magig HTTP wand you can wave
around like the magic crypto wand I have?
[23:26:02] ek leaves the room
[23:26:32] <mnot> please duplicate and ship to me
[23:26:47] <kaduk@jabber.org/barnowl> I'll get to work on the banach-tarski right awya
[23:26:49] <lpardue> I think it is better to assert, if you've already done websockets over HTTP/2 then this is a simpler problem to solve
[23:27:09] Ross leaves the room
[23:27:48] <mnot> If we *don't* do either of the HTTP transports, the Fallback transport has a purpose, obviously
[23:27:55] <Ben Schwartz> Why do we need Http2Transport instead of plain old WebSocket?
[23:28:07] <Ben Schwartz> Ah
[23:28:39] <mnot> QuicSockets
[23:28:51] <dschinazi@jab.im> WebQuic?
[23:28:59] <mnot> QuicWeb
[23:29:06] <kaduk@jabber.org/barnowl> One True Protocol?
One protocol to rule them all?
[23:29:08] m&m leaves the room: Disconnected: closed
[23:29:17] <dschinazi@jab.im> ...And in the drakness encapsulate?
[23:29:21] m&m joins the room
[23:29:28] <mnot> QuicTransport + Fallback is easier to start with.
[23:29:36] mcr joins the room
[23:29:44] <Martin Thomson> I have been convinced that if we do h3 over QUIC, then h2 is the obvious path from there for TCP
[23:29:54] <spencerdawkins> I am SO with EKR on that.
[23:29:56] <mnot> Right. It's either left column or right column.
[23:29:58] <Martin Thomson> but the complexity hit there is mammoth
[23:30:13] <mnot> There is a lot more complexity on the right.
[23:30:23] <mnot> And, risk. All you get is the ability to pool.
[23:30:27] <Martin Thomson> this wtheaders thing is amazingly complex
[23:31:08] <mnot> Realistically, it would be a while before many implementations/deployments would support it in h3/h2
[23:31:10] <afrind> I don't think it's so complex - it's not really any different than server push
[23:31:16] <martin.duke> I'm somewhat unclear on the difference between 'QUIC Transport" and an application that just runs over QUIC
[23:31:19] <mnot> oh, that helps, Alan!
[23:31:22] <lpardue> HHAHAHA afrind
[23:31:24] <Martin Thomson> afrind: way to slam dunk that argument!
[23:31:29] <Zahed Sarker> I will go for the dedicated column as from the discussion it seems easier option to begin with..
[23:31:30] <hardie> @afrind  possibly not your winning argument, given the success of push.
[23:31:35] <spencerdawkins> Not that we have a TAPS working group, but would the API allow an application to run over either Http2Transport or Http3Transport, with no changes?
[23:31:50] <afrind> yeah.  Maybe I meant "not more complex than sending an H2 push promise"
[23:32:03] Karl leaves the room: Disconnected: closed
[23:32:16] <nygren> Might also be worth thinking about non-web use-cases as well.  (ie, which would something like envoyproxy or TAPS prefer to build on?)
[23:32:41] <watson17> some APIs
[23:32:54] <Zahed Sarker> webtrans for non-web use case?
[23:33:06] Karl joins the room
[23:33:13] <mnot> (httpbis virtual interim seems increasingly likely, based on discussion this week)
[23:33:28] <dschinazi@jab.im> mnot: awesome
[23:34:27] Karl leaves the room: Disconnected: closed
[23:34:30] <Martin Thomson> I don't know how to thread the needle between QUIC, HTTPBIS, WEBTRANS, and MASQUE here.  So much overlap.  As much as we are all the same people, having the pieces land in the right places is surprisingly hard.
[23:34:33] <nygren> masque being an example.
[23:34:57] <mnot> Making things generic and reusable while actually shipping is the target
[23:34:58] <watson17> and making sure RIPT doesn't mean we do it all twice...
[23:34:59] <tfpauly> Very much agreed, Martin
[23:35:23] <lpardue> @Martin Thomson: no doubt we'll want to do WebTransport or RIPT via an HTTP proxy
[23:35:33] <dschinazi@jab.im> I agree as well. This is surprisingly tricky but I'm cautiously optimistic
[23:36:01] Bernard Aboba leaves the room
[23:36:22] Bernard Aboba joins the room
[23:36:40] <Martin Thomson> for me the more complex option needs a lot more motivation
[23:36:44] <Cullen Jennings> RIPT have some idea of what they want but may not care much how muchy you get ther
[23:36:58] Karl joins the room
[23:37:01] <nygren> +1 to mnot.   (ie, being able to use the same building blocks and server infrastructure for things that aren't just web browsers is valuable.  For example, there's a blurry lines in the API space)
[23:37:01] <Martin Thomson> Cullen Jennings: that's helpful
[23:37:08] <Bernard Aboba> @cullen could you get into the queue and give us your perspective?
[23:37:11] <lpardue> CONNECT, RELIABLE, UDP, DATAGRAM
[23:37:47] <brong> CONNECT, RECONNECT, UNCONNECTED, DISASTER
[23:37:56] rayatarashi@jabber.today joins the room
[23:38:06] tim costello leaves the room
[23:38:17] <mnot> The DATAGRAM draft is going forward
[23:38:33] <mnot> How it's mapped into H3 is still TBD, but being discussed
[23:38:45] <Magnus Westerlund> Well, we have chartered the QUIC WG to do datagram. Now the work just now need to complete.
[23:38:52] tim costello joins the room
[23:39:04] dkg leaves the room
[23:39:09] mglt leaves the room
[23:39:13] <Jonathan Lennox> Is there need to map DATAGRAM to H3, other than WebTransport?
[23:39:19] <Martin Thomson> to be clear, those drafts are a long way from what you need to get webtransport
[23:39:28] <Jonathan Lennox> The semantics of unreliable HTTP are at best perplexing to me
[23:39:41] <mnot> That's what needs discussion.
[23:40:11] <afrind> There are lots of ways to do partially reliable HTTP, some of which don't use datagram at all.
[23:40:19] <Bernard Aboba> Yes, performance requirements would be very useful.
[23:40:20] <spencerdawkins> @Jonathan - ya think? (reaches for popcorn)
[23:40:49] <Jonathan Lennox> Well, we got it working for SIP - you can just re-use that infrastructure! I'm sure that'll be fine.
[23:40:55] <lpardue> @Victor: please send some more details,. Given the state of QUIC/H3 analysis tools, I'd like to know how you debug WebTransport
[23:40:55] <nygren> One way is that when you can't get adequate throughput or too much queueing you start dropping discrete units.  But building useful things on that opens up lots of cans of worms.
[23:40:59] <Cullen Jennings> The semantics of most unreliable stuff turn out to be surprisingly simple …
[23:40:59] <afrind> We (Facebook) have an implementation that uses partially reliable QUIC streams based on Igor's old draft
[23:41:25] mcr leaves the room
[23:41:30] <Martin Thomson> afrind: yeah, that's a pretty good model...for some use cases
[23:41:56] <lpardue> slide 1 :D
[23:42:06] <Eric Kinnear> Lol thank you Lucas
[23:43:39] <afrind> I think we should separate adding datagram support to h3 / webtransport and partially reliable HTTP
[23:44:04] <Martin Thomson> afrind: oh good, because mnot thinks the opposite
[23:44:46] wseltzer leaves the room: Stream reset by peer
[23:44:53] <afrind> :D
[23:45:10] <Martin Thomson> I was worried that we would run out of things to fight about
[23:45:11] tim costello leaves the room
[23:45:22] <afrind> mt: i was never worried.
[23:45:34] <Martin Thomson> </sarcasm>
[23:45:46] Dan York leaves the room
[23:45:50] <spencerdawkins> So WebTrans is ALWAYS going to request the last slot?
[23:45:58] <brong> WT over XMPP
[23:46:23] <Jonathan Lennox> I don't think it was the last slot before we went virtual, was it?
[23:46:46] <spencerdawkins> Did the last session end early? :-)
[23:46:53] <Eric Kinnear> +1 to what MT just said
[23:46:59] <Ben Schwartz> (FallbackTransport over H2 would still be pooled)
[23:48:18] csperkins leaves the room
[23:48:53] <Martin Thomson> this is why I think that QuicTransport might be better than H3Transport
[23:49:33] <hta> I found it very informative to learn that the H2 mapping requires upgraded H2 servers at every point in the path.
[23:49:38] <watson17> does the additional handshake not matter?
[23:49:46] <Martin Thomson> but I recognize the desire to find ways to fit this in with HTTP more, because QuicTransport oil to HTTP water
[23:49:51] <lpardue> thank you all
[23:49:55] Steve Donovan leaves the room
[23:49:56] msk leaves the room
[23:49:57] petereyee leaves the room
[23:50:02] Atarashi Yoshifumi leaves the room
[23:50:02] <Martin Thomson> watson17: setup costs don't concern game developers much
[23:50:05] tfpauly leaves the room
[23:50:10] m&m leaves the room
[23:50:11] dontcallmedom leaves the room
[23:50:16] watson17 leaves the room
[23:50:16] <Peter Wu> bye! Thanks Bron for notes!
[23:50:19] sfuerst leaves the room
[23:50:21] xp29srs leaves the room
[23:50:21] lsawyer leaves the room
[23:50:24] Zahed Sarker leaves the room
[23:50:28] martin.duke leaves the room
[23:50:29] <brong> Thanks Peter!
[23:50:29] xdf leaves the room
[23:50:30] Cullen Jennings leaves the room
[23:50:31] Steve Todd leaves the room
[23:50:32] <brong> likewise
[23:50:36] Cindy Morgan leaves the room
[23:50:40] Jonathan Lennox leaves the room
[23:50:45] Alissa Cooper leaves the room
[23:50:46] Magnus Westerlund leaves the room
[23:50:52] Mirja leaves the room
[23:50:59] kbarabad leaves the room
[23:51:03] csperkins joins the room
[23:51:20] Chris Wendt leaves the room
[23:51:45] Martin Thomson leaves the room
[23:51:50] Eric Kinnear leaves the room
[23:51:52] Peter Wu leaves the room: Disconnected: BOSH client silent for over 60 seconds
[23:51:53] Ben Schwartz leaves the room
[23:52:37] dschinazi@jab.im leaves the room
[23:52:48] csperkins leaves the room
[23:53:11] rayatarashi@jabber.today leaves the room
[23:53:18] cabo leaves the room
[23:53:57] Barry Leiba leaves the room
[23:56:05] cabo joins the room
[23:56:12] mnot leaves the room
[23:56:16] Karl leaves the room
[23:56:18] cabo leaves the room
[23:57:39] csperkins joins the room
[23:57:47] nygren leaves the room
[23:57:53] csperkins leaves the room
[23:58:18] dragana leaves the room: Disconnected: Replaced by new connection
[23:58:37] Mike Bishop leaves the room
[23:59:45] Philipp S. Tiesel leaves the room