05:43:00 <RRSAgent> RRSAgent has joined #webtransport
05:43:00 <RRSAgent> logging to https://www.w3.org/2019/09/18-webtransport-irc
05:43:39 <JRR_Tolkien> Youenn: how would 'dropping' data happen?
05:44:15 <JRR_Tolkien> Victor_??_Google: currently no way to ignore, UDP sockets allow ignoring by not reading from buffer (overflow)
05:44:44 <nicktr> rrsagent, set logs public
05:45:12 <jianjunz> jianjunz has joined #webtransport
05:45:27 <JRR_Tolkien> Peter_Thatcher_Google: one of the goals is to apply back-pressure
05:46:02 <JRR_Tolkien> Youenn: want to send datagram above max size, what would happen?
05:46:32 <JRR_Tolkien> Victor: exception. API call will give you max size.
05:46:51 <minami> minami has joined #webtransport
05:47:44 <JRR_Tolkien> Victor: closing stream semantics can help. there are a lot of higher level apis you can provide to deal with larger messages.
05:48:53 <jungkees> jungkees has joined #webtransport
05:49:08 <JRR_Tolkien> Peter: example in explainer shows message of arbitrary size
05:49:28 <JRR_Tolkien> ???: is protocol name set in constructor?
05:50:06 <JRR_Tolkien> Victor: it's done using interface mixin. constructors may vary, but object must support WebTransport interface
05:50:45 <JRR_Tolkien> Alex_Apple: WebSocket has handshake to prevent misuse. does this have a similar mechanism
05:51:48 <JRR_Tolkien> Victor: Quic transport uses ALPN to match a specific value, without a valid value it won't work and fail the connection. Browser verifies list of domains can talk to before sending data
05:52:22 <JRR_Tolkien> Jan-Ivar Mozilla: does getWriter get a different writer every time?
05:52:55 <wonsuk__> wonsuk__ has joined #webtransport
05:53:07 <JRR_Tolkien> ??: once stream is closed it will never be used again.
05:53:20 <ricea> That was me
05:53:36 <JRR_Tolkien> full name would help :)
05:53:39 <ricea> Adam Rice
05:53:40 <nicktr> s/??/ricea/
05:54:09 <inamori_> inamori_ has joined #webtransport
05:54:37 <JRR_Tolkien> Jan Ivar: calling send datagram twice gets two streams, how do they interact (multiplex, etc.)
05:54:55 <JRR_Tolkien> Victor: should only be one stream in datagrams. they should be either sent or not sent (UDP semantics)
05:55:15 <JRR_Tolkien> Victor: Goal is to use UDP semantics with flow/congestion control
05:55:41 <JRR_Tolkien> ????: timing data was missed with WebSockets. can metrics/stats be added to API?
05:56:16 <JRR_Tolkien> Victor: some stats are there, need users to provide feedback on which stats are interesting/needed.
05:56:44 <JRR_Tolkien> ?????: ...fallback when you don't have UDP?
05:57:04 <JRR_Tolkien> Emad_Omara_Google: will it support 0-RTT?
05:57:24 <JRR_Tolkien> Victor: no support for 0-RTT. API design is hard, more complex state machine, etc.
05:57:38 <JRR_Tolkien> Youenn: will WebRTC stats be reused (applicable ones)?
05:58:13 <JRR_Tolkien> Victor: added the ones that we know are already useful
05:59:12 <JRR_Tolkien> Steve_Anton_Google: WebRTC has a lot of stats because you are not on the data layer, this should be different because you are using the networking layer
06:03:38 <JRR_Tolkien> ??: how will debugging work? what about dev tools?
06:03:57 <JRR_Tolkien> Victor: dev tools is planned to be supported.
06:05:12 <JRR_Tolkien> Amit_Hilbuch_Google: how will this interact with p2p scenario
06:05:23 <JRR_Tolkien> Peter: currently focused on Server-Client but planned
06:05:35 <JRR_Tolkien> Jan Ivar: is congestion control required?
06:05:57 <JRR_Tolkien> Victor: yes all streams are required to use congestion control.
06:06:54 <JRR_Tolkien> ??: Implemented in quic using datagram frame, data will be blocked if window is full (adding more data will cause it to be dropped)
06:07:35 <JRR_Tolkien> ???: will Keep-Alive behavior be part of the transport?
06:08:26 <JRR_Tolkien> Victor: connection will be kept open as long as it isn't explicitly closed (or garbage collected)
06:08:58 <JRR_Tolkien> David_Google: Quic has a keep-alive mechanism.
06:09:16 <JRR_Tolkien> s/???/Mark Foltz_Google
06:09:27 <JRR_Tolkien> 
06:10:42 <JRR_Tolkien> Victor: ... multiplexing mechanism is not yet clear. this is a learning from WebSockets on url leading to http assumption.
06:11:06 <JRR_Tolkien> ????: it should be easy for Http3
06:11:20 <JRR_Tolkien> Victor: for http it is easy, but for quic transport it's not as clear
06:11:56 <nakakura> nakakura has joined #webtransport
06:12:24 <nicktr> s/????/AdrianHB/
06:12:57 <JRR_Tolkien> David: next steps for this work - do people have opinions on the best plan forward?
06:13:06 <JRR_Tolkien> Jan Ivar: considered forming a WG?
06:13:27 <JRR_Tolkien> Victor: eventually it will hit a WG, but it's not ready for that state yet (no real dev feedback yet)
06:14:08 <JRR_Tolkien> Jan-Ivar: mozilla would support a working group
06:14:36 <JRR_Tolkien> Youenn: would node js or similar frameworks use the same pattern?
06:14:49 <JRR_Tolkien> Victor: have not reached out about that yet
06:15:19 <JRR_Tolkien> Youenn: node js can be used for both client and server
06:17:32 <JRR_Tolkien> Peter: any feedback for technical discussions? CC or BWE?
06:17:45 <JRR_Tolkien> ??: what happens during connection?
06:18:01 <JRR_Tolkien> Victor: we need to define how it interacts with extensions
06:18:44 <JRR_Tolkien> ??: is the expectation that the connection initiation will carry cookies?
06:19:20 <JRR_Tolkien> Victor: explicitly no, considered exposing channel bindings
06:19:42 <JRR_Tolkien> ??: is there expectation that a user gesture is required to initiate a connection?
06:20:04 <JRR_Tolkien> Victor: currently not.
06:20:21 <JRR_Tolkien> Jan Ivar: thoughts on putting this in service worker?
06:20:36 <JRR_Tolkien> Victor: should be supported in service workers.
06:21:21 <JRR_Tolkien> ?????: is this meant to be protocol-agnostic?
06:21:48 <JRR_Tolkien> Victor: there is a websocket based fallback
06:22:01 <JRR_Tolkien> ?: how does this interact with prioritization (multiplexing scenario)
06:22:52 <JRR_Tolkien> Victor: prioritization is a hard topic in http. with http3 it behaves similar to regular http streams (scheduler provides fairness). dos + fairness are concerns
06:24:16 <nicktr> rrsagent, draft minutes
06:24:16 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-webtransport-minutes.html nicktr
07:57:21 <Zakim> Zakim has left #webtransport
08:02:36 <wseltzer> wseltzer has joined #webtransport
08:02:42 <wseltzer> rrsagent, pointer?
08:02:42 <RRSAgent> See https://www.w3.org/2019/09/18-webtransport-irc#T08-02-42
09:20:57 <hyojin> hyojin has left #webtransport