<sudeep> https://www.w3.org/2019/07/31-web-networks-PrinciplesForWebNetworks.pdf
<sudeep> https://www.w3.org/2019/07/31-web-networks-TheviewfromtheEdge.pdf
<scribe> scribenick: dontcallmeDOM
DanD: we wanted to briefly
introduce the concept of edge computing and how it relates to
things developed alaredy in the cloud & networking space
and how it may impact the Web
... I gave this presentation a couple of months ago to the Web
& Networks IG
... if you're interested on the topic, check it out - we're
tackling issues related to how to expose network features to
the Web layer
... [slide the view from the Edge]
... [basic idea of edge computing]
... historically, functionality has been split between client
and server
... this has gone back and forth depending on evolution of
computing power available on device and the capacity of the
network
... this has evolved over the past 3 or 4 decades
... what we have now is the introduction of a 3rd piece in the
architecture
... adding to client and server the edge, which can sit
anywhere between the two (if at all)
... it's close to existing concepts, CDN, proxy browsers
... but compared to those, these are for static resources
... The edge is both an architectural and a deployment paradigm
shift
... from a developer perspective, the edge piece can both be
the client and the server
... the edge is defined by the administrative boundaries
... and it is associated with the network and data center
topology
... a lot of the elements that (from a network operator
perspective) consitute the network can be virtualized
... most of our network is moved to IP which frees real instate
in geographic footprint
... if you're familiar with central offices where switches used
to be, they are now facilities that are closer to the user and
can serve as data centers
... [use cases - a 3 dimension approach]
... you have to look at use cases through different
lenses
... from a functional perspective, from a control &
management perspective, from a location placement
... latency is definitely a key aspect since bringing
functionalities to the edge help with reducing latency
Michael: privacy would another requirement
DanD: this is not so much about
requirements for edge apps as much as characteristics of apps
that can benefit from edge computing
... Edge computing is also relevant now in the context of the
deployment of 5G, with a disaggragation of functions in the
network,
... network slicing can also create useful
characteristics
... and a push to the edge among cloud providers
... An example on how this is relevant to the Web
community
... assuming a Web app runs on the client that has a lot of
workload on the client, you may want to find an edge node to
shift your processing
... assuming a component has already been deployed in edge
infrastructure - how would a client find it? how does it verify
it satisfies the requirements for the app?
... how does it adapt to mobility circumstances?
... how does it adapt to congestion load on the node?
... this is mostly done as an agent to the OS at the
moment
... WebApps could take advantage of these scenarios
... Assuming you've deployed your app on edge nodes e;g. in a
cloud platform - how do you figure out the best one to find,
how do you transition?
... this type of APIs might be worth exposing from the UA
... I don't know how this woudl be done, what security
implications this would imply
... we want feedback and input on these questions
... ETSI Multi-Access Edge Computing provides APIs at the
infrastructure level
... incl network conditions, location - but this is for the app
running on the edge
... it doesn't involve the browser per se
... Another initiative is the Akarino project from the Linux
Foundation
... it's an integration open source project that provides
blueprint integrated hardware and software for specific use
cases
... e.g. IoT, RAN deployment
Michael: there are many edge
computing stacks under development
... In terms of use cases, there was browser offloading
... but there are also non-browser use cases, eg.
orchestration
... some are compute-intensive, some not
... also questions around data movement is a
consideration
... you gain in compute but raises the time to transfer data
back and forth
... We have an existing thing in W3C that could be extended to
support this
... for instance ServiceWorker
... or PWA
... Micro-services are also related
QQT: the CDN is classical in
network architecture
... we're exploring distributed networks, e.g. P2P CDN
... if a browser want to support a P2P CDN, it needs a P2P
API
... how does the browser support a P2P network distribution
system?
DanD: to design P2P + edge,
finding the peers is something you would want to do very
quickly
... finding the closest peer to you shouldn't involved going
out to a far away data center
... when you design a P2P artchitecture, instead of going peer
to server to peer, you could query an edge piece to find that
information
... that would be a way to leverage the edge in a P2P
network
QQT: if we find a peer node, how
do we connect to it?
... some nodes doesn't support HTTP, just UDP/TCP
... e.g. bittorrent
DanD: what you put on the edge is
up to you
... you have your own application that runs on the edge
node
... it hosts your piece of the app
... you make it work
Michael: another way to look at
it is the edge as a set of available functions
... the question becomes what protocols can be made
available
... the browser is mostly client-server model
... whereas things-based projects are more peer-to-peer
... Instead of looking at edge from a full-stack perspective,
we can also look at it from a more functional perspective
DanD: for P2P, WebRTC could be used
QQT: WebRTC brings too much for this
Michael: WoT supports multiple
protocols
... we have a scripting API but we don't have a deployment
model for it
... I've been wondering if this would be a good place to put
that
QQT: WoT is closer to the edge
Michael: we want to have an environment to run the code
Sudeep: is the question how do we
discover the edge and we can use WoT protocols to do that
... and once we discover the edge, how do we offload?
Michael: discovery is one
problem
... another is management: how do I install some code and
control it at run time?
... another is a provisioning environment
DanD: Akaraino may actually solve
this
... Blueprints go higher or lower in the stack
Michael: from a high level, what
gaps can W3C help in this context?
... without looking at specific stacks, what is W3C strength?
what is the gap? what is the problem we can solve?
... we have the Web developers community, a certain collection
of APIs that we can evolve
... can they be expanded to account for the edge?
... we also need to under the business models
DanD: one thing I do want to
point out - I keep mentioning that an app would need to be
edge-aware, not edge-dependent
... you need a fallback in case an edge node cannot be
found
Michael: there are various
mechanisms that we could extend
... e.g. considering serviceworker: you could transparently
pushing it to the edge if available; if not, fallback on client
serviceworker
... another approach would be microservices: the server could
push some of its microservices to the edge
... but that is no longer in W3C's scope
DanD: if you want to push this to serviceworker, it would need to be partly transparent to the developer
Michael: I think that's one
option that should be considered and developed
... not clear if this would be fully transparent, or with an
hint, or with more developer control
SOng: it's not just about
discovering the edge node
... how can a Web developer invoke some interface to do
discovery, connection?
... based on my experience from an operator perspective, the
edge computing will support most services
... for Web/HTTP requests, we need to speak with the
infrastructure provider
... if not, there is no direct communication yet
... we need to get operators and device makers to support that
- as soon as possible
QQT: is there a way to access an
edge node from HTTP?
... from the browser?
DanD: Once you know where it is, you can use the browser HTTP stack
QQT: but the edge node IP address can change all the time
DanD: if I understand the
requirement, you would try to find an edge node to find a local
peer
... the edge node is an IP address
... to which you ask the best peer
... and then you shift your communications to it
QQT: the results would provide some IP address then?
DanD: right
QQT: and we would use it to
access to the edge node, with what protocol?
... HTTP? the problem is that we can't use HTTPS due to domain
matching
DanD: this isn't different from a deployment to the cloud
Dom: but how do you map an IP address to a domain-based certificate for TLS?
Michael: there is COmmunity Group
that has been looking at this
... this has been bugging us for a while in Web of Things
... it's difficult to get support for this in browsers
... a local CA would work but can't work in browsers
Dom: I don't think we have an answer to this at this time - it feels like a major challenge from a deployment perspective
DanD: coming back to our broader
discussion
... it would be interesting to look at what W3C could do
... with Michael's serviceworker approach, would this be like
an edge browser after previous cloud browser?
... would we need to define what a client would look
like?
... and what APIs it would expose?
Michael: fwiw, I think this only
solves a specific use case: browser offloading
... another issue is that serviceworker are very limited in
terms of what APIs they can use
... for instance, having access to AI on the edge based on what
is under development would be important
... ServiceWorker doesn't have filesystem support
... e.g. for persistent
dom: cloudflare has a product
with a serviceworker-based deployment for its cloud
infrastructure
... which sounds interestingly similar to what we've
discussed
... combined with the advent of Web Assembly on client/servers,
lots of interesting opportunities
... although lots of unknowns
DanD: one unknown would be to
understand what features would be available to this "edge user
agent"
... WebGL? WebML? others
Michael: not sure if serviceworkers would have access to them
Dom: maybe not now, but they could be adapted to new contexts
Michael: WebAssembly can be
thought as containers
... so this may be an opportunity for W3C to get into that
space
... The other question is discovery - if I find a node, how do
I deploy code to it?
chunming: several years ago, W3C
had generated a note about Cloud Browser architecture
... where a lot of the browser rendering was done in the
cloud
... if we have edge in the middle, can we offload some of the
browser tasks (e.g. time consuming calculation to the
edge)
... e.g. to help battery, or better performance
... Another question - we heard of applications (e.g. AR or VR
scenarios)
... currently all the rendering happens in the device
... but there are use cases where e.g. AI detection tasks would
be running in the edge
DanD: the cloud browser was
mostly focused for set top boxes for media
... it was to offload the settop box to the cloud e.g. for the
fancy navigation
... in the end, the idea is the same
... between cloud browsers, split browsers with user
interactions, proxies - this was done e.g. 20 years ago by
Opera
... they did caching, transcoding, mapping between technologies
to save bandwidth
... the concepts are very similar
... they had a browser running in the cloud
... if you think of what properties you want to offload to the
edge, you can start identifying what an edge ua would look
like
... and then you have to juggle between where to run these
APIs
... if you tackle this problem by looking at how to run Web
technologies to the cloud (closer or further), the question is
what can be run with what security considerations?
... e.g. how to ask user permission?
Dom: I would start with simple
e.g. offloading computing
... follow up could happen in the Web & Networks IG
... otherwise, or when we're ready to experiment/prototype, we
could move to a dedicated CG to play with ServiceWorker
... the IG is probably the right place to explore the overall
landscape
Michael: WoT would want a lot more and very different things from the edge
Dom: agree, but we probably want to start with low hanging fruits
Michael: for WoT, you would want to install persistent orchestration service - setting new functionalities, now moving things up or down
DanD: if people are interested,
please join us in the Web & Networks IG
... we'll work on clarifying that particular topic and identify
concrete next steps
... it seems there are ideas, probably not clear yet but worth
exploring
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/question/paradigm shift/ Succeeded: s/appN/app?/ Succeeded: s/uA/UA/ Succeeded: s/@@@Baidu/QQT/ Present: Chunming WARNING: Fewer than 3 people found for Present list! Found ScribeNick: dontcallmeDOM Inferring Scribes: dontcallmeDOM WARNING: No "Topic:" lines found. WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]