13:58:30 <RRSAgent> RRSAgent has joined #web-networks
13:58:30 <RRSAgent> logging to https://www.w3.org/2021/11/30-web-networks-irc
13:58:49 <dom> Regrets+ ChrisNeedham
13:59:09 <dom> Present+ Sudeep, LarryZhao, Huaqi, Dapeng
13:59:14 <dom> Regrets+ MichaelMcCool
13:59:20 <dom> Present+ SongXu
13:59:54 <dom> Present+ JakeHolland
14:01:08 <dom> Slideset: songslides
14:01:10 <dom> scribe+
14:02:38 <sudeep> sudeep has joined #web-networks
14:03:01 <dom> Present+ PierOHanlon
14:03:26 <dom> Present+
14:04:35 <dom> Topic: Intro
14:04:43 <dom> Sudeep: welcome to our 20th web & networks IG
14:04:47 <dom> Present+ Yajun
14:04:57 <dom> ... hope everyone is safe
14:05:06 <dom> ... this meeting is meant to capture the TPAC summary
14:05:26 <dom> ... we would like to invite you to share your thoughts on how TPAC went, capture some of the input and actions
14:05:28 <dom> Present+ DanDruta
14:05:48 <dom> [slide 2]
14:05:54 <dom> ... we will cover 3 main topics: games in the games CG
14:06:07 <dom> ... edge computing - some work done by Max in this space
14:06:55 <dom> ... piers will share his thoughts about network conditions & monitoring
14:06:58 <dom> s/piers/Piers
14:07:10 <dom> ... Song will cover the key essence of these topics
14:08:08 <dom> [slide 3]
14:08:18 <dom> Topic: TPAC debrief
14:08:26 <dom> Subtopic: Coordination with Games CG
14:08:50 <dom> Song: Jeff reported the interest from the games CG on exploiting low-latency from e.g 5G network
14:09:02 <dom> ... the CG hasn't been too aware of our work
14:09:12 <dom> ... we're reaching out to them to get their use cases and requirements
14:09:23 <dom> ... ideally, we would like to get real data from game vendors
14:09:50 <dom> ... China Mobile is running a game company, my colleague Huaqi is working on use cases analysis on that
14:10:26 <dom> Sudeep: are there any other member here with interest on topics related to Web gaming?
14:10:35 <dom> ... the games CG is looking at trends from a Web development perspective
14:10:41 <dom> ... we're trying to bring the networking angle
14:10:49 <dom> ... and its impact on the quality of experience
14:11:06 <dom> ... anyone with an interest in sharing perspectives in this space?
14:11:29 <dom> ... if you find relevant people, please let us know
14:11:43 <dom> Subtopic: Edge Computing
14:11:45 <dom> [slide 4]
14:12:12 <dom> Song: another feedback we got from TPAC was to make sure the Web platform is not left behind as new network capabilities emerge from edge computing
14:12:31 <dom> ... we already have use cases and requirements, but no active incubation in this space
14:12:58 <Larry_Zhao> Larry_Zhao has joined #web-networks
14:13:25 <dom> ... we need to strengthen the incubation in this space; Max is leading the way
14:13:25 <Larry_Zhao> Larry_Zhao has left #web-networks
14:13:35 <dom> ... we also need to explore potential breakthrough in this space
14:13:39 <cyj_> cyj_ has joined #web-networks
14:13:46 <dom> ... Max and Michael will brainstorm the next steps
14:14:15 <dom> -> https://w3c.github.io/edge-computing-web-exploration/ Client-Edge-Cloud coordination Use Cases and Requirements
14:14:30 <dom> Subtopic: Network conditions and monitoring
14:14:44 <dom> Song: we need to hear from the latest evolution of the network info API
14:14:53 <dom> ... Piers will give a talk on network info from edge servers
14:15:04 <dom> ... while keeping in mind the risks around privacy and fingerprinting
14:15:06 <dom> [slide 5]
14:15:17 <Larry_Zhao__> Larry_Zhao__ has joined #web-networks
14:16:02 <dom> Jake: re TPAC - thanks for the mention of the Multicast work!
14:16:23 <dom> ... there was a mention of supporting the CG as the right place to work on multicast
14:16:44 <dom> ... is there any ongoing liaising that I should be doing from the multicast CG side?
14:17:11 <dom> Sudeep: did you get any new member through TPAC for the CG?
14:17:26 <dom> Jake: a bunch of new people came to the TPAC meeting; don't think they've joined the group after that
14:17:30 <dom> ... our next meeting is tomorrow
14:17:46 <dom> ... various follow ups have happened at IETF
14:18:34 <dom> Sudeep: I guess this topic still needs further socializing within the web dev community, like edge computing
14:18:59 <dom> ... is there any specific short term action we can take? I suppose you've already done outreach
14:19:46 <dom> Jake: at IETF, the feedback focused on lack of browser interest
14:20:13 <dom> ... there are also security concerns that were raised
14:20:29 <Karen> Karen has joined #web-networks
14:20:54 <dom> ... the right browser folks may not be engaged at IETF
14:21:08 <dom> ... so my ask might be to establish the connections with these folks
14:22:31 <dom> Song: in terms of multicast scenarios, there may be an overlap with edge computing
14:23:50 <dom> Jake: several ISPs have expressed interest in multicast - more wouldn't hurt; but the key is getting at this stage is getting browsers interest
14:24:53 <dom> Sudeep: the privacy concerns - do they go away from multicast is used in settop boxes?
14:25:32 <dom> Jake: the privacy concerns are actually at the network level; keeping the issue out of the browser doesn't help solving them
14:27:44 <dom> dom: we should be careful in distinguish issues around security & privacy, they hurt in different ways
14:27:57 <dom> i/Jake: re TPAC/Subtopic: Multicast
14:29:32 <dom> Topic: Network Information & Edge Computing
14:30:00 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2021Dec/att-0000/W3C-NetworkHints.30nov21.pdf
14:30:08 <dom> [slide 2]
14:30:26 <dom> Piers: what are the metrics, where do they come from?
14:30:54 <dom> [slide 3]
14:31:48 <dom> Piers: the state/timing information gives a view on the network state from the receiver or sender perspective
14:32:09 <dom> ... at the kernel level, TCP_INFO gives a bunch of congestion info
14:32:25 <dom> ... as part of the BBR, there is a new delivery rate estimation as part of the kernel
14:32:35 <dom> ... a sister draft to the BBR draft, from IRTF
14:32:58 <Karen_> Karen_ has joined #web-networks
14:33:50 <dom> ... from the app level, QUIC as a transport info api with similar info to tcp_info
14:33:59 <dom> ... likewise, you get info from WebRTC
14:34:04 <dom> [slide 4]
14:34:30 <dom> ... in the BBC, we're interested in streaming media, so trying to find metrics to help with media quality
14:37:25 <dom> [slide 5]
14:37:39 <dom> ... in terms of server metrics, we would be interested in sharing information available only on the server
14:37:52 <dom> ... e.g. sender cwnd
14:38:05 <dom> ... it could also provide information not directly available to the client, e.g. the rtt
14:38:49 <dom> ... the congestion window is available through APIs e.g. in nginx, appache traffic server, via an http header or inline with the data
14:38:52 <dom> [slide 6]
14:39:10 <dom> ... the cache-status-header has per-cache metrics
14:39:24 <dom> ... one of my draft to IETF proposes a Transport-Info header
14:39:38 <dom> ... The W3C server timing API provides some information to the client
14:39:59 <dom> ... CTA-WAVE has ongoing work via the Common Media Server Data, with media-specific delivery info
14:40:04 <dom> [slide 7]
14:40:35 <dom> ... we did some test - a server that includes transport info via a proxy, profiled for consumption by a dash player
14:40:37 <dom> [slide 8]
14:41:15 <dom> ... the error of the bandwidth estimation is much lower when using transport info
14:41:44 <dom> [slide 9]
14:42:04 <dom> ... among the issues with that approach is ensuring the client is directly connected to the server
14:42:17 <dom> ... with HTTP2/3 flows can be coalesced
14:42:44 <dom> [slide 10]
14:43:17 <dom> ... discussion at TPAC around rebooting the network info API with a smaller scope, but still not very popular outside of chromium
14:43:29 <dom> ... and giving very rough info in any case
14:43:42 <dom> ... Resource Timing API is not very useful for streamed media
14:44:18 <dom> [slide 11]
14:45:40 <dom> [slide 12]
14:46:12 <dom> ... in terms of potential API improvement - streams API would benefit from a data buffer arrival timestamp
14:46:53 <dom> ... Could e.g. resource timing be extended to cover media delivery?
14:48:02 <dom> [slide 13]
14:48:37 <dom> Jake: did you measure the impact on the quality of experience?
14:48:42 <dom> Piers: we did, but that's more involved
14:48:54 <dom> ... it depends on which algorithm you use
14:49:20 <dom> ... on VOD, the benefit isn't as strong
14:50:00 <dom> ... in low latency areas, it depends on which algorithm you use - you get benefits, but not always as clear you would expect, but likely due to to the algorithms themselves
14:52:33 <dom> Jake: is there a common place to follow these discussions?
14:53:02 <dom> Piers: CMSD in CTA-WAVE; the analysis will be published soon, but hasn't been published yet
14:53:18 <dom> Jake: I'll watch this space
14:53:56 <dom> ... would be worth bringing to MOPS in IETF
14:54:16 <dom> ... can you elaborate on the privacy questions that were raised?
14:54:55 <dom> Piers: exposing accurate information about a client connection that may allow to fingerprint that particular device, which may allow to infer where they are
14:55:26 <dom> ... but we didn't lay them out in details
14:57:42 <dom> dom: information could be used to say whether someone is at home / office / in transit
14:58:06 <dom> ... possibly even at the room level with very detailed info and impact on e.g. wifi connection
14:58:26 <dom> Piers: not sure if this exposes any new info though compared to what you can measure with JS, but just more efficiently
14:58:52 <dom> ... Another issue was around coalesced flows that would allow to infer activity happening separately
14:59:10 <dom> Jake: I guess some of the noise of obtaining the info directly from JS might be seen as a good thing from that perspective
14:59:57 <dom> Topic: Edge computing
15:00:07 <dom> Max: I haven't updated the draft use cases draft recently
15:00:16 <dom> ... ByteDance has expressed interest in contributing
15:00:35 <dom> ... will try to gather more momentum from other companies
15:00:40 <dom> ... toward a possible charter
15:00:45 <dom> ... please get in touch!
15:01:13 <dom> Sudeep: sorry we're out of time, we'll also run another dedicated session on the topic
15:02:21 <dom> ... Our next meeting will likely be in January, with Max & Michael to dive on edge computing
15:03:16 <dom> Present+ PeipeiGuo
15:03:24 <dom> RRSAgent, draft minutes
15:03:24 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/30-web-networks-minutes.html dom
15:03:31 <dom> RRSAgent, make log public