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