Web & Networks teleconference

15 Jan 2020



Dominique_Hazael-Massieux, Chris_Needham, Larry_Zhao, Peipei_Guo, ykhuang, Piers_O_Hanlon, Dario_Sabella, Sudeep_Divakaran, Song_Xu, Eric_Siow, Louay_Bassbouss, Qiao, Zoltan_Kis
Sudeep, Song


Agenda review

Sudeep: happy new year to all IG members
... a few updates about upcoming meetings
... followed by two guest speakers: Dario Sabella from Intel, vice chair of MEC in ETSI
... involved in several industry groups focused on edge computing innovation
... then a talk by Prof. Qiao and Wangs from Beijing University of Posts and Telecommunications
... focused on machine learning and neural networks and impact on moving some of the compute to the edge
... before these talks, a few announces of upcoming meetings in February

Web & Networks IG meetings

scribe: On Feb 5th, a review from Google on lessons learned while developing the Network Information API (implemented in some of the browsers)
... the API gives insights about network conditions
... and the Google folks will share what they learned in the process of developing and deploying that API
... On Feb 13th, a presentation by Michael Mccool, co-chair of the Web of Things Working Group
... will give insights on the intersection of service worker / web worker in the context of edge computing

MEC in action: an overview of Edge computing activities

Dario's slides

Dario: this presentation gives an overview of the topic - we won't cover everything, but the slides are further references
... this is an overview on edge computing - not an exhaustive view, but hopefully an interesting view of the topic
... there is a wide consensus on the revenue potential from edge computing
... I'm part of the standards body, vice-chairman of the ETSI MEC standard
... there are other standard bodies and industry groups covering different aspects of edge computing
... I've helped coordinate an Intel white paper covering the various standard bodies
... where you can find more relevant information
... there are many activities reflecting the need to cover many different aspects
... there are commercial products, open source projects
... in addition to ETSI, 3GPP is defining how to implement MEC in a cellular network
... The KPIs of MEC include: improved latency naturally, but there are other KPIs e.g. cost savings
... each vertical might have different needs from edge: performance is key, but not necessarily just latency
... [slide 7: where is the edge?]
... The definition of where the edge is intentionally foggy
... the answer is "it depends"
... it can be at differently level of distance from the end user
... there is a trade-off of performance & cost when scaling MEC deployments
... there is flexibility in deployment options
... [ETSI MEC]
... MEC stands for Multi-Access Edge Computing (initially Mobile Edge Computing)
... it's not only for cellular operators, but other access methods (incl wifi, fixed access)
... MEC is cloud computing at the network edge
... the standards group has participation from a wide set of participants, from the wide ecosystem
... 98 partners amont MEC members and participatns
... "MEC offers to app developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network"
... 3GPP is starting to work seriously on the topic
... we're a committed to build a consistent story across standard bodies
... [slide 11: MEC architecture]
... this is network agnostic, not based on a particular access method
... it is inspired by the ETSI NFV framework
... this produces services, but can also consume services that would exposed to other applications
... the client side can communicate through the @@@ interface that instantiates a proxy application in the MEC side

Song: I would like to know which part of the specification is the most interesting for developers

Dario: from a dev perspective, we have written a white paper and organized a webinar to address this topic
... as a developer, the information I would need to use a MEC system is given in slide 12
... developers don't need to know about the underlying infrastructure, they want to use the services
... there are different type of categories of specifications in MEC
... starting from MEC 016, UE Application interface
... and general principles for API
... (restfull, http, data structures)
... there are freely available OpenAPI representations of these APIs
... the rest of the specs are less relevant to developers directly

Developing Software for Multi-Access Edge Computing

Dario: we are not preventing that new service APIs can be implemented without standardization as long as they follow the API principles
... we're not aiming at providing the full list of APIs
... [slide 13: OpenAPI description files, MEC 0023]
... for interoperability, we have standardized a number of APIs that have been required by the industry
... the OpenAPI representations of the APIs are available on forge.etsi.org
... We have other activities in ETSI MEC beyond the traditional standardization work
... we want to engage the ecosystem - app developers aren't interested in reading specs, they want to develop their services
... that's why we've been developing Proof-of-concepts, promoting MEC via hackathons
... and MEC deployment trials

MEC Hackathon Framework

scribe: there is an upcoming hackathon in April, with an open call for developers with a focus on Android
... an example of a standardized API, led by Intel, is the MEC V2X API (vehicle-to-everything)
... this is related to automotive
... slide 16 shows the list of foreseen functionalities
... this is a stable draft
... it helps with interop across car makers and operators
... [overview of the API structure]
... one of the methods is predicted_qos - we're not standardizing who is producing that info, just how it is exposed
... [MEC use cases]
... MEC GS 002 collects our use cases - it shows the use cases supported by MEC
... there are 3 categories: consumer-oriented services (e.g. app computation off-loading)
... operator and third-party services (not directly for the benefit of the end-user)
... and network perf and QoE improvements - this can be fully transparent to the user
... [App Computation Offloading]
... This allows the MEC host to execute compute-intensive functionalities with high perf than the mobile devices, both from a time and energy perspective
... the trade-off is the cost (computing, power, time) of transmitting the data
... this has to be analyzed on a case by case basis to evaluate how useful the offloading is
... examples incl video processing, AI, ML
... app offloading could benefit from being requested from the client-side, e.g. via a Web API
... this may need a counterpart work in ETSI (not planned at the moment)
... [5GAA]
... I also wanted to touch on what we're doing in 5GAA (5G Automotive Associated) where MEC is a key technology
... this is where the predicted QoS work emerges, which was demonstrated in November

Sudeep: maybe let's keep this for discussion with Google in February

Dario: makes sense

Accelerating DNNs for the Web with Edge Computing

Prof. Qiao's slides

Qiao: the topic is accelerating deep neural networks for the Web with edge computing
... deep neural networks show great promise in providing more intelligence to Web applications
... there are typical execution schemes: javascript/Web Assembly on the client - but that requires loading heavy DNN models (e.g. ~100 MB)
... the other more common approach is to run the model on the remote cloud
... but that requires sending large amount of data to the cloud, increases computing pressure, and creates privacy concern (e.g. for home security camera)
... Mobile Edge computing is providing an important infrastructure via 5G
... it allows to reduce the burden from the core network and reduces the in-device computing cost
... so we would need to dynamically distribute the computing around the various ndoes
... the client would only need to download a small part of the model and keep the privacy-sensitive data on-device
... the challenge is how to provide this offloading in a changing network conditions
... we introduce an efficient branch to the traditional neural networks
... it can help accelerate the inference on the Web with collaborative mechanism on the edge server
... [slide 6]
... network conditions and device computing capabilities can change dynamically
... this requires a context-aware algorithm that takes into account these parameters
... we propose an adaptive framework
... with a web runtime adapter, with a model optimized for mobile users
... depending on whether a set of conditions are satisified, some of the computing is offloaded to the edge and the cloud
... [slide 7]
... Is there a better metaphor to distribute computing on the Web?
... how can we make it easier to use edge computing for web developers?
... how can we detect when using edge computing is the most efficient approach (e.g. network conditions, computing capabilities of the end device)

Sudeep: thank you - very interesting and relevant use case
... relevant both to MEC and network quality prediction
... also intersections with the WebNN work in W3C and the Web of Things work (service and capability discovery)
... we will have to continue investigating this discussion

Song: +1

Sudeep: we need to look at what kind of APIs, what needs to be down in the browser context vs in-apps
... thank you everyone

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/15 15:43:27 $