- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 21 Jul 2022 16:09:10 +0200
- To: "'public-networks-ig@w3.org'" <public-networks-ig@w3.org>
Hi, The minutes of our meeting held today (Jul 21) are available at: https://www.w3.org/2022/07/21-web-networks-minutes.html and copied as text below. Dom Web & Networks Interest Group 21 July 2022 [2]Agenda. [3]IRC log. [2] https://lists.w3.org/Archives/Member/member-networks-ig/2022Jun/0001.html [3] https://www.w3.org/2022/07/21-web-networks-irc Attendees Present ChrisN, DanD, Dapeng, Huaqi, LarryZhao, Louay, Louay_Bassbouss, MichaelMcCool, PeipeiGuo, Song, Sudeep Regrets - Chair DanD, Song, Sudeep Scribe cpn, dom Contents 1. [4]Edge Computing Workstream 2. [5]TPAC planning 3. [6]Updates on other topics Meeting minutes Sudeep: our focus will be on edge computing today given the current momentum behind this topic … our goal is to identify next steps, in particular towards TPAC … we'll also talk about the upcoming TPAC 2022 … and a summary of our existing & new topics in the IG Edge Computing Workstream [7]Edge Computing Exploration github repo [7] https://github.com/w3c/edge-computing-web-exploration/ [8]Client-Edge-Cloud coordination Use Cases and Requirements [8] https://w3c.github.io/edge-computing-web-exploration/ Max: I've updated the document based on the comments from the last meeting … I'll review these updates … and Michael sent a PR earlier today that we can also discuss … We've identified editors (separately from contributors) … the co-editors are Michael, Song and myself … There was also a request to highlight the benefits of offloading to the cloud or edge in the use cases … which we've done through use cases - e.g. in the Machine Learning use cases involve really intensive computing which depending on the underlying hardware may imply very different outcomes … e.g. whether they have a GPU or not Michael: maybe a section summarizing the benefits would be useful Max: +1 Max: another comment was a suggestion to refine the gap analysis … it now emphasizes what the current specs cannot support Michael: I think the bullet points in section 5.2 may deserve to be a section standing on its own Max: let's iterate on this indeed Max: another update is about the the conclusion & way forward section (8.3) … we list 2 options: divide the work across existing relevant Working Groups, … or we establish a dedicated Working Group for this problem … the 2nd option helps with a unified architecture - we can coordinate with other groups as needed … if we agree this is the right approach, we could proceed with writing a charter Michael: I think we need to list the potential deliverables … this would help establish which may need a new Working Group … it's quite likely this would be needed, but there will also be a need to coordinate with other groups Sudeep: we also need to identify the stakeholders who would need to support the work & a potential charter <McCool> (since I interrupted so much, I will be quiet for a while ;) cpn: I think we still need to improve the understanding of requirements before proposing a WG … the exploratory work may not be a good fit for a WG Dom: Agree, CGs are more a place for the exploration … Overall I think mapping proposed solutions to new specs or changes to existing specs, protocols, APIs, there's room for pre-standardisation work max: I agree with your points - this needs further work before proposing a WG … a CG sounds like an interesting option Song: +1 on iterating in the IG or in a CG to draw a clearer picture of what we need to build … having a single group would help making progress rather than split across groups Michael: +1 on more incubation; I think the document itself also needs more iteration … getting more and broader input on it would be good … a W3C workshop might be a good way to achieve this … a CG would be one way to do so but it has downsides, but an IG is already a good fit Dom: I agree having a single group would be more comfortable … When we get to the right stage for standardisation, I expect we'd need to split it across multiple groups … e.g., WASM work going to that WG … We should look at it as a collection of useful pieces, rather than something that must be adopted all together … An option 1 approach may be more likely to get to where we want … On getting broader input, the first thing to do would be to publish as an IG note, which signals the group wants input on it … When the PR is merged, are we ready to get broader attention on the document? … For TPAC, I was thinking more of an informal workshop, could lead to a formal workshop later … Use TPAC as a way to gather presentations on the topic, prerecorded, different perspectives, to add to our thinking … Relevant to how edge computes intersects with the web. A formal workshop probably needs a bigger sense from the community Michael: I think the document needs a bit more work before being published as an IG note - but I think we could there by the time of TPAC sudeep: +1 on gathering input from beyond the group … a mini-workshop or a breakout session at TPAC might help with that … this sounds like pre-requisites before a WG max: I can look into creating a CG if there is support sudeep: there will be demos from Max, Louay around edge (not necessarily edge offload) … maybe we should look at organizing a formal workshop before the end of our charter … and use TPAC, this document as drivers toward that Piers: any input from existing companies that provide edge services such as cloudflare, fastly … (beyond Alibaba that presumably has some as well) Max: Alibaba has an edge service, but not an implementation of the proposed solution which would need more standardization support Dom: I hope we could attract those companies to a workshop … I agree they're critical to making this successful, we need at least two Michael: +1 - we need to plan on how to attract these companies which have solutions pretty similar to what is being discussed … we should make sure the stakeholders listed in the business categories need to be well-represented Louay: our demo is focused on edge in the context of 5G … we showed it at the Media Web Symposium - I plan to record it as a demo Dom: Breakouts are more limited this year, 1 hour for broad visiblilty, but probably not 2 hours … Could have a longer timeslot for the TPAC meeting, that could be used for demos, or discussion … The number of people would be more limited, but would give more leeway for scheduling TPAC planning Sudeep: WNIG meeting on Sep 13, then breakouts on Sep 14 Michael: afternoon slots won't work well for remote participation to breakouts Sudeep: maybe that points toward doing the mini-workshop post TPAC Dom: The last breakout slot at 4:30 could be possible for people in Asia? Sudeep: our agenda at TPAC will be structure around updates to our workstreams, with plenty of time for open discussion (with room for a possible guest speaker) … it'll be posted on the wiki Updates on other topics Piers: the work on monitoring in IETF is on hold, but there is work happening in CTA WAVE around this Chris: I'm talking with that group in the context of the Media & Entertainment IG - let's approach them together <McCool> (sorry, I have to go, another call with SDW...) Sudeep: not much progress on link performance prediction; haven't seen much progress on priority control either … on Edge Computing, good progress on our offloading; not seeing lots of progress in intersection between MEC & Web … Not much anew on network emulation either … New topics have emerged recently: exposing network slicing (which are now exposed e.g. in Android) … We also received feedback from the Games CG on the network APIs gap e.g. for download progress information Dom: the Winter CG is looking at making browser APIs into non-browser runtimes such as node, deno, cloudflare worker … possibly interesting overlap with our offloading explorations Sudeep: also potential interest around multicast receiver for Web using edge nodes Minutes manually created (not a transcript), formatted by [9]scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC). [9] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 21 July 2022 14:09:14 UTC