<scribe> scribenick: dom
Sudeep: Web & Networks IG F2F
- planning to cover quite a few topics
... I'm Sudeep - this is our first face to face meeting
... join us on IRC
... The chairs of the group are Dan Druta, one of the founding
members of the IG
... Song Xu, from China Mobile
... I'm Sudeep from Intel
... Our staff contact is Dom, working with us on getting that
group up and running
... The mission of the Web & Networks IG is to explore
solutions for web apps to leverage network capabilities in
order to achieve better performance and resources allocation,
both on the device and network
... [Agenda for the day]
scribe: our IG is still pretty new - formally created in May, active for the last 3 months
John_Devlin: work for Intel from Texas - I'm interested in 5G and we've been working on some extensions to enable better perf
Harald: from Google, chair of WebRTC WG; working in networking for a little while
Jonas: working for Intel - very interested in helping with wireless infrastructure
Sudeep: from Intel; co-chair of the IG, have been working in networking for more than 20 years, have looked at Edge and how it can help the Web
DavidSknazi: work at Google on Chrome, in particular Quic and WebTransport - interested in seeing synergies
Dom: @@@
MarkWatson: from Netflix - media streaming needs to estimate network throughput, interested in learning what hints might be coming up
Stefan: from Fraunhofer Fokus - interested in 5G and media delivery
DanD: AT&T - one of the
reasons we're here is to get a top-down approach on what
requirements are needed and what API surface may emerge for
fulfilling these needs
... my focus has been on edge computing and related
technologies
... I'd like to see if and how this relates to this group
@@@: Amazon Prime Video, looking at streaming from an end-to-end perspective
@@@_China_Mobile: China Mobile is launching 5G, interesting in seeing how this group can support 5G services and scenarios
Song: I'm in charge of creative
5G services in China Mobile
... hope to contribute my knowledge in wireless to this
group
... co-chair of the group
@@@Huawei: would like a better understanding of the 5G scenarios
@@@2_China_Mobile: @@@
Angel_Alibaba: interested to see how the Web can be related to 5G experience and see how the Web applications layers can work with network capabilities
@@@_research_institute_from Japan: @@@
Yuki_NHK: Japan Broadcast corporation - researching transprot for next generation terrestrial TV transport
Omar_ZainTelecom: want to see the use cases for networks & carriers when it comes to Web dev
Mohammed_KoweitOffice: trying to get a feeling from the group
Takayuki_NTT: interested in Edge Cloud & content delivery
@@@: interested by 5G & Edge Computing
@@@_YahooJp: interested in videos
@@@: work in video streaming & cloud gaming
Mao: YahooJp
@@@_Google: prototyping Web Transport
Masayoshi_NHK: work on IP distribution, focus on video streaming
@@@3_ChinaMobile: interested in 5G, network slicing, edge computing
Jeff_Jaffe: W3C, interested on impact of 5G on the Web
Sudeep: I'm happy to hear a lot
of alignement between expectations and the goals of this
IG
... hopefully we will cover some today with the agenda, and
some over the course of the life of the group
... I'll give a further intro on the IG
... Then Dom will show existing related work in W3C
... after a break, Dan will give a presentation on guiding
principles for solutions in this space
... Song will cover work done in external organizations: 3GPP,
ETSI
... After lunch, Jonas and Jon will share experiences from
their work around web hints to solve media-related problems;
they also have a demo scheduled tomorrow
... after the afternoon break, our last session will be to
discuss use cases: filtering them and evaluating how to move
forward with them
... Tomorrow, we're planning a breakout session on edge
computing - how to make it relevant to Web developers
Sudeep: A few words on the IG and
why we think it is important
... 3 key problem statements
... Web apps today function more or less agnostic of network
types
... there are only limited hooks available to determine
quality/performance, despite the great variation that exists
esp in wireless networks
... 2nd problem statement: network service providers have
limited visibility to anticipate utlization and allocation of
network resources
... is there anything that apps can expose to network that
would help with optimizing resource allocations?
... Third: what better tools can be provided in browsers,
developer tools - there are tools e.g. for network
throttling
... but you can't really simulate specific network
conditions
... how can you compare apps running on the cloud vs on device
vs on edge
... Great to see the diversity of participants around the table
- wee need all these voices to find the right solutions
... The one thing we all want to solve is that waiting
experience
... Measuring Quality of Experience is hard
... Difficult to have a quantitative measure for it, but it's
clear we don't users to wait which loses business for
everyone
... This IG will not be defining specific solutions, but we
believe one approach we want to pursue is the notion of
explicit hints
... hints help from a privacy perspective
... hints can be "early", allowing prediction on
evolution
... or instantaneous, reflecting the current situation
... Keyword of this group is leveraging network
capabilities
... 5G is bringing lots of new capabilities - some relevant,
some not - one goal is to help raise awareness about these and
determine which needs our attention
... we need to determine which if these capabilities need to be
exposed to Web developers
... our charter runs until end of 2020
... please join the IG if you haven't done so yet
... Progress so far: 3 conference calls, soliciting use cases,
discussing principles of solutions in this space (Dan will
cover that)
... discussions around existing work in W3C and in other
orgs
... We've looked at Mobile/Multi-Access Edge Computing
... we had some discussion on Link Performance Prediction -
will be presented later today
... we're happy to consider new topics
... we do our work on github - so far, 11 use cases submitted
as github issues
scribe: If you want to submit use
cases, use the github template issue
... We've looked other sources of use cases
... e.g. WebRTC NV use cases include use cases on multiparty
online game with voice ommunications, mobility
... Media & Entertainment have related use cases on
broadcasting, streaming
... Web of Things have need from a latency perspective
... Looking outside, we're looking at the use cases that have
driven the definition of MEC APIs
... We'll look at our use cases later today to see if any need
emerge from our review
Dan: re our use cases, I want to
make sure participants don't feel overwhelmed
... heard lost of interest on media / video distribution
... we won't be working on all these use cases at the same
time
... we can add new ones, and we can focus on specific ones
Jeff: as an Interest Group, the
focus is to identify use cases and requirements
... and see where they get done: in the app, in standards
... if in standards, this group is not chartered to develop
standards
... but the group can help steer the work, either by spawning
Community Groups, or bringing it to existing or new Working
Groups
Dom: [presenting on past and future work in the networking layer for W3C]
...five high level categories - first is about network transfer
...look into metrics and monitoring, hints, local & private networks (not limited to applications that run in public space),
...WebSocket is a bidirection set of operations. Widely available.
...WebRTC bi-directional peer-to-peer network operations. Client-to-client as well. Works with unreliable data channels as well. Another widely used tech
...WebRTC Audio/Video is widely available on the web browsers today
...Service worker - one way to look at it is that it enables caching capabilities. It helps address some of the performance issues
... Push API enables operations that not initiated by client, but instead by the server.
...Push API is less deployed
...Background fetch is a JS API to handle large downloads/uploads in the background
...it is probably available in Chrome
....Background sync one or more periodic operations to the background. Not yest implemented anywhere
....Backpressure for network streams - useful if there is too much data being downloaded, then this method can help put backpressure to adapt networking streaming ability
...we had a few mention about WebTransport this morning
<JonDevlin> what does backpressure offer over TCP?
...WebTransport is work in progress. It works on top of QUIC.
...Connection Establishment with ICE. ICE is exposed in the WebRTC context.
...feel this is one topic this IG group can drive forward
...Resource Timing feature is widely available to find out where time is spent most during data transfers
...WebRTC Statistics is a valuable feature for monitoring
...Network Information API defined long time ago. Some of it based on heuristics and some based on measurements. It exposes high level characteristics about the network.
...there were some privacy linked concerns. Some of the API are available in Chrome, Edge browsers
...Network Error logging using HTTP headers
...Mobile Data Plan - more a case of a failure case than a success story. The idea was to expose information about what kind of data plans is being used and accordinlgy optimize the network choices and usage
...this didnt go anywhere. Something similar that came up was Google Mobile Data Plan Sharing API.
...due to privacy concerns, it didnt land in any browser. Definitely, there are lessons to be learnt from this.
...Resource hints where browser takes markup hints from apps to optimize network utilization
...we will discussing about hints with Dan today
...WebRTC DSCP helps to request for prioritization of packets. This hasnt been implemented anywhere yet
....rather not available in any browser yet
...there is an ongoing effort in second screen group on open screen protocol
...in the mixed success category. There has been some attempts to expose local network services to browser like network service discovery API. But didnt progress much due to privacy linked concerns
...there is a local network community group working on HTTPS. It would be good to check if there are any common use-cases to bring into Web & Networks IG
...W3C network consumers are - WebRTC has very significantly changed the landscape for audio video transport for the better. In the field of XR, there is a lot of study in looking at how edge can help reduce latencies
...Web of Things has lot of intersections with Web and networks IG due to common areas of interest around network latency
...predicting gaps in the network would be a topic of interest in the IG context
...W3C had organized a workshop on Cloud Gaming. It was to look at how web can enable cloud gaming by addressing the performance gaps in the network
...There was a roadmap document prepared as Web5G activity. Is it a good to continue this in this IG
dan: we should document common requirements in e.g. how background sync may need less network priority if we have network hints
sudeep: I support the idea of updating the Web5G roadmap
Harald: WebRTC showed some of the limitations of the same-origin policy, which breaks down in a P2P model
A hints based approach towards Web & Network APIs
[Example Geolocation]
Harald: confirming the user location by the network disclose sensitive information
DanD: the user would consent to get that confirmation e.g. if the content provider requires it
Harald: I had this bug with an ipv6 tunnel that confused a geo-restriction system
DanD: I get your point - I think this is a good example of minimizing data sharing for validation
Harald: validation is new information, and sensitive - it may be a good trade-off but it's not information-free
DavidSchinazi: clarification - how would this work? get the location from the network and have it exposed by the browser?
DanD: the browser collects
various data to determine the user location
... then the browser would ask the network confirmation that
this matches their location
dom: the location could be fuzzed to avoid leaking new info to operators
harald: the network is asked to attest for the location information
dand: the overall idea is to use validation/attestation as a way to reduce privacy risks
sudeep: the network operator has a rough idea of where the user is - can't you expose that attested location directly in the browser
eric: can you say more about the regulatory requirements about network-based location? if this is required, does that problem need solving at all?
dand: but that info does not have to be shared with all parties
sudeep: and that requirement doesn't exist in all countries
DanD: [slide Trust]
... the key is to build mechanisms based on trade-off rather
than trust
... Data integrity needs to apply to any solution in this space
based on past experiences
... Hence, we should focus on hints - information that can be
provided without commitment but can be used to convey
application characteristics
... this creates less strict rules on enforcement and
availability
... would like to get feedback on these principles, what
additional principles that need to be considered in this
space
Harald: hints - code is law
... if you're deploying something on a billion node that reacts
to a hint in a predictable way
... you've given some degree of control to the entity that
emits this hint
... which means you've created a new trust relationship
... back in the 80s we had this hint of the network, ICMP port
unreachable
... IRC relied on server-to-server connections, breaking their
connections created IRC splits
... hackers started abusing this to create these splits, which
led to the hint to be ignored
... then the next level of hint got used, abused, ignored
... because of lack of trust relationship
... If we design hints, we need to think: how can they be
weaponized, if they're used, how can you trust-and-verify
DanD: this is an illustration of
breaking the principle of "data integrity" since you could not
determine who was sending the hint
... I agree that there is a form of trust - but it doesn't have
to be sophisticated
Harald: I like the Web of Trust
approach, with certificate authority logs
... nothing prevents a CA to make false statements, but they
can only make false statement in their names
... and with CA logs, you can figure that a false statement has
been made and by whom
... lying has a cost
MarkW: I think that's the
intended model
... having a trust-and-verify approach
... for a service like ours, we would use a A/B testing to see
if the hints has any impact
... if there is no benefit, we would stop using it
... if it's a win-win solution, then there are good reasons why
the hints would be used
... but there needs to be some security layer to authentify the
source of hints
DanD: any other feedback? any other principles we need to consider for a hints framework?
Dom: probably worth highlighting
this lens of "trust-and-verify"
... maybe in a derived checklist we would use to evaluate hints
in this space
DanD: this would complete the "discourage cheating" principle
Sudeep: do we need to look at the different layers - app, networks?
DanD: my hope is for this IG is
to look at things from top-down
... e.g. IETF looks at use cases and requirements from a
protocol level
... looking at it from the Web layer, which actors are in
involved...
... For instance, DSCP marking was developed in IETF and is set
to get exposed to the JS layer with the WebRTC spec, and there
is now a draft in IETF on how the markings get exposed back to
the network layer
... the goal is to identify a common way to do these things
across the platform
... Dom presented this proposed API on background sync, and we
have a number of hints to indicate prioritize flows
... if some of this information can be exposed to the radio
scheduler, this can actually improve overall performance for
everyone
... I think use cases at that layer can help harmonize how we
approach these in general
... there are common themes where this hint framework can
help
Sudeep: aren't there
possibilities of hints that would be public information?
... e.g. information provided by the service provider that
isn't specific to a user, applicable to all users in a
cell
... e.g. network conditions
... "high-congestion in this cell"
DanD: this was part of an
experiment on mobile throughput guidance done by YouTube,
Vodafone, Nokia
... YouTube would use congestion information provided in an IP
optional header to adapt its streaming
... This was presented in the IETF transport area - I haven't
seen any recent updates on that
... one concern was IP Option wasn't reliable
... also, the congestion information was about the radio - if
you had backhaul congestion, this would not be conveyed
... so the message itself was not always directly useful
<hta> https://tools.ietf.org/html/draft-flinck-mobile-throughput-guidance-04
DanD: this was coincidentally using MEC to inject that hint in the IP packet
<hta> using a TCP option
Sudeep: Song will talk about liaisons and other relevant external organizations
<hta> the IAB workshop that considered draft-flinck: https://tools.ietf.org/html/rfc8462
Slides: Liaison Management Plan
Song: from China Mobile -
introducing our liaison plans for the IG
... 3 peer organizations:
... 3GPP, GSMA, IETF
DavidSinger: we need someone else than Paolo Usai for 3GPP - he's retiring, we need a liaison contact with a technical profile
Song: will find someone
else
... also looking at a liaison with 5GSA - it's a 5G network
slicing adoption
... want to see if we can share information about network
slicing
... [liaison responsibilities]
Sudeep: should ETSI be added to the list given their MEC efforts?
Song: ETSI and 3GPP work together, with 3GPP being the external interface, but I'll check for the needs to direct intersection with ETSI
Slides for Web and Networks: Status in liaison organizations and topics for TPAC
Song: look at internal and
external groups
... first one is the Network info API from W3C, last modified
in February - it enables detailed access network info used by
the device
... WebXR by the Immersive Web WG recently updated
... allows immersive apps on the Web
... WebRTC 1.0 ongoing work
... WoT Architecture published as CR in May 2018
... looking now at activities in other organizations
... first, regarding Edge Computing
... it's a platform that integrates network, storage, video
coding capabilities
... similar to CDN, it marginalizes app computation, but not
just for static content
... it enables faster response
... ETSI/3GPP have defined a full set of APIs to enable edge
computing
... this includes location, bandwidth management, radio network
info
... this is exposed as REST HTTP API
... anything that would be exposed to the browser could be work
on it
Sudeep: tomorrow, we will have a
breakout session on edge computing and how it could be used by
Web developers
... it's one big area of interest for this group
Dom: MEC is only available on one-to-one basis type of agreements with operators - is that correct?
Song: these interfaces will be
implemented by operators and manufacturers
... in some cases, it will be available to third-party
developers
... some will be reserved to internal operations
... that's part of the motivation of the uniform framework for
APIs
... they allow extensions that still conform to the
framework
... [Edge computing - ETSI MEC Framework]
... The MEC host contains the MEC platform with a virtualized
container that provides computing and storage capabilities
Sudeep: Dan, will you be covering some of the software stack for edge?
DanD: I will
... note on ETSI APIs, they're defined for the edge node - not
on the device/OS/browser side of things
... we need to be clear on where there may need to be API
surface needs in this community
... beyond the ones already defined in infrastructure / node
side of things
... We need to understand the opportunities from a W3C
perspective around MEC
Song: looking at some of the
specific APIs defined in ETSI MEC
... Radio Network information, bandwidht management, device
identity, location information, fixed access information API,
UE application Information
... see ETSI GES MEC 103
... 3GPP CAPIF provides a framework for APIs, including in
terms of format, auditing, logging
... this enables operators/manufacturers to extend on top of a
common model
... Another big topic is Network Slicing
... it enables segmenting physical networks into logical
sub-networks
... it creates new private end-to-end network with
virtualization on demand
... network slicing can provide the functionality to fulfill
the user requirements according to the delay, the bandwidth and
the access numbers
Sudeep: if network slicing comes into the picture, how would it intersect with Web apps? is this something for us to investigate?
Song: currently, there is no
concrete on network slicing - 3GPP is focused on the low-level
layer, not the app layer
... much of the network slicing functionality is not available
yet
... but at the application layer developer, we can help pushing
higher priorities on this
Sudeep: is there any work on the native side in this space?
Song: not yet - the focus has been on the low-layer
Harald: one thing I never understand: is the expectation that any app only connects on one slice?
Song: network slicing expects to use slice-templates
harald: thinking the other way around - would my browser use one network slice? several?
song: that would depend on the app
harald: as a web app, I wouldn't know this?
dom: I think that's part of what we need to figure out
song: you could imagine that a web app for a UHD service would trigger access to a UHD network slice
Lin: the current model is one app - one slice
Harald: then the browser would only get one slice?
DanD: you could image two slices
with different latency characteristics available to the
device
... the browser could then put some traffic on one slice, and
other on another slice based on their demands
... A good way to look at slices as VPN + QoS
... Web technologies should not get slice-dependent
... Slices that are available for different characteristic of
traffics - how can we make browsers slice-aware? how will they
need to authenticate to them?
... how to skip them when they're not available?
... there is a lot of hype around slicing - some entreprise use
cases make sense to me, but the consumers use cases are more
challenging
Sudeep: if we look at Media / IoT
/ real-time as use cases
... slicing would be useful for browsers as well in that
context
DanD: the browser is a platform
in itself, it's not just an app
... slicing is very network-centric - you won't have a way to
create slices from a WebApp
Harald: this reminds me of
MPLS
... a technology that seemed to be able to do a lot of things,
but ended up being only exposed to the network only, not apps
due to the challenges
... I don't want us to spend time on slices because they're
there, rather than assuming we need them
Song: network-slicing is not a
replacement for VPN
... 3GPP would consider Web as just another app - if we want to
change that perspective, we probably need to get perspective to
3GPP
Eric: The scope of this IG is not restricted to just 5G - all the various networks need to be in our scope
MarkW: spent a lot of my career
in 3GPP / QoS space
... this seems similar to this - and that never got used
... I don't know how likely this will get used
DavidSchinazi: a lot of the
network is not 5G
... we should also not constraint ourselves to the first hop
either, there is the whole network to traverse
DavidSinger: I've wasted many
years of my life on ATM, QoS, bandwidth reservation
... the social problems were never resolved - who would get the
better performances and why?
... Layering has been extremely succesful - piercing that
layering we should be doing with lots of caution
... imagine a Wifi plugged into a 3G or 4G backhaul
Song: [examples of what a networkslicing API could look like for a Web developer]
Sudeep: we need to look more into
the expected benefits / RoI of network slicing in the context
of Web browsers
... Separately, what's the status of WebTransport? Is this part
of W3C
DavidSch: it will be presented
tomorrow in the unconference
... and in the WICG meeting on Thursday
... We're bringing this to W3C and simultaneously at the IETF
for the protocol
... but this is all in flux depending on feedback we get from
the community
Sudeep: we reconvene at 2pm with some practical examples, use cases and results
Slides: Network Link Performance Prediction
Sudeep: had good discussions this
morning on what we should be shooting for in this group; what
we need to keep in mind, what has worked and what hasn't, what
we should learn from this
... Introducing Jonas and Jon from Intel, who have been working
on related topics
Jonas: Intel has been working on
infrastructure for wireless for quite a while, even if we're
not necessarily known for it
... we're trying to make sure what we provide to network
providers get more visibility nowadays
... we will start at what we see as challenges on wireless
networks, with 5G network and beyond
... we will look then as to what link prediction can help
achieve - we will be looking for feedback
... We also want to look at who would benefit from
exposing/consuming that information
... and then some considerations on how this could translate
into API requirements
... We will show a demo of this in practice tomorrow
afternoon
... What are some of the wireless network challenges?
... across 3G/4G/5G, you can get a lot of variations across
networks - the peaks get higher and higher across network
evolutions, but you still get very low pits
... with 5G mmWave, things can get even more dramatic
... given their short range
@@@_Huawei: is the variation you're pointing at within 5G or across different type of networks?
Jonas: both
... moving forward, as the data rate goes up, best-cases
improve, but poor-cases will still be pretty low
@@@_Huawei: but even in "pure" 5G, you would still get these variations?
Jonas: yes - depending on your
distance to the cell tower
... you could always deploy a lot more cells and base stations,
but that comes with a cost
... on the other side, with edge deployment, you can get very
different perceptions of the end point between
edge/CDN/cloud
... variations between hitting the edge or the cloud is going
to make that problem even stronger
... which makes it difficult to adapt the UX
... Network is clearly "best effort" today - can we make it
more deterministic, or at least more predictable?
... [Intel link performance prediction - LPP]
... We've found it difficult to solve in the 3GPP space -
applications are talking with internet protocols or W3C APIs,
not 3GPP protocols
... so our approach has been to focus on hints, leaving control
to the application
... CUrrent network status is one of the things we want to
convey, but also and maybe more importantly, give insights on
the near future which helps apps adapt
... In terms of parameters, some of the key aspects are
bandwidth, latency, but also cell load
... there can be many more, but I haven't seen as strong use
cases for them (e.g. packet loss)
... The 5G mmWave was a trigger for our work, but clearly our
work is not expected to cover only this, not even only 3GPP
networks (although that's probably where you see the most
variation)
... if you look at our scenario here, moving from one cell to
another with different level of loads and different network
characteristics
... if you know you're moving through these cells, you can
adjust your buffering and network scheduling in
consequence
... this also applies to coverage gaps, or conversely to
high-throughput cells (e.g. 5G mmWave)
... typically these cells are hard to exploit optimally unless
we help ship load to that cell
... [Intel LPP Technology]
... What we're doing: we don't think we can revolutionze the
network as it is architected today
... we have client and server communicating via the data link -
nothing changes there
... what we add is a prediction server sitting in the operators
network, providing these predictions to the client side and
also potentially to the server side
... we collect data from a range of sources on the server - we
don't expose it, but use it to build these hints /
characteristics
... these characteristics can be measured directly by the
application itself (in the future when it comes to
predictions)
... We've developed this in a way to avoid exposing privacy
data
... We had some discussion in the morning about how much
network information in itself may be privacy-sensitive
... [Example use case: media streaming with LPP]
... We're trying to ensure our solution is simple to implement
and deploy
... [Standard MPEG DASH - quick intro]
... MPEG Dash allows to chunk a media file at different quality
levels and send a given chunk based on recent measured network
performance
... DASH is reactive - which is OK for a stable network, but
not so much when there is a lot of variation
... [Demo - example of LPP pre-fetch strategy]
... this can be leveraged in multiple ways
... you could classify in e.g. 5 different levels from bad to
great
... if you determine you have a good level, you can reduce
buffering
... that's a good thing since it avoids e.g. download of data
to be thrown away
... if we get a prediction that the network is going to go down
in quality, you can start prefetching data for buffering
... for real-time video (e.g. sport), you can instead adjust
the compression rate or the quality
... [demo - dash reference JS client + LPP]
... We adapted dash.js to include LPP predictions
... when we detect a loss of network quality, we adjust the
target buffer level
... we can do that with very few changes (~30LOC) in the
library
... [Show Demo...]
... Side by side playing of videos, with and without LPP
... [3. Application usage of Link Prediction]
... [Example usage]
... here we had a mix of adapting to both low and high
connection with pre-buffering or buffer minimization
... minimizing buffer is an advantage in some but not all
cases, depending on how much you expect the user to jump around
in the videos
... it helps operators, end-users (power and data consumption),
content providers (bw costs)
... Another case is remote gaming
... it improves the UX, but you would use predictions in a
different way
... Another case is network policy usage
... [Example usage: dynamic buffer control when
streaming]
... when using the predictions, you have to anticipate the
adapatations to the network
... we've been running this with SK Tel in Korea
... the tests were done in a real base station, but in a
controlled environment for repeatability
... [Example usage: min buffer level when streaming]
... when looking at minimizing buffering, we measure data
utilization rate, and see significant improvements with
LPP
... [example usage: remote gaming frame handling with
LPP]
... the goal is to move video frames from the server GPU to the
(low performance) client slide GPU
... and send back input control data to the server
... the goal is to maximize UX by avoiding stalls and lag when
playing
... by pre-adjusting channel bandwidths
... our results are good so far
... compared to media streaming, there is no buffering
opportunity - real time is the goal
... the server side is driving the adjustment
... the idea from a privacy perspective is that client would
pass the link prediction handler to the server
... [Example usage: network policy usage]
... what else can we do with LPP?
... roughly, around 10% of network traffic is not
data-sensitive - e.g. backups, updates
... if you can communicate the network load or some kind of
network policy of what apps should do, you can shift these
needs to low-usage area/times
... e.g. for background transfer
... that helps also spread the load across cells and time
... This can also apply in enterprise coverage
... mmWave doesn't penetrate buildings, so to cover indoors has
to be deployed indoors
... in which case, it may be deployed by the building tenants
themselves rather than by operators
... in this case, being able to determine whether you're in a
pay-for network or not matters
... that's another example of how you might change your network
usage policy based on network conditions
... This can also benefit operators who can help sell capacity
at a different rate
... [Who benefits?]
... [Use case 1 - bundled video mobile plan]
Jon: one of the first use case is
for service providers to bundle prediction capability for
specific apps
... it helps provide a premium UX and optimize network
utilization
... providing network awareness and ahead of time helps
optimizing UX
Eric: even if consumers don't pay more, it helps reducing the churn
Jon: this could also apply e.g.
in stadium environment
... [Use case 2 - OTT Video Optimized Slice]
... YouTube for instance always pre-buffers content
... but there are circumstances where buffering is not needed
(not moving, high quality of network)
... if you can stop buffering, it helps reduce waiting time and
increases revenue
... [Use case 3 - mobile cloud gaming slice]
... we see lots of interest on cloud gaming and see lots of
expected growth in this space
... there is a big difference between what "gamers" want vs
mobile game users
... Prediction is needed, it's not enough to be reactive to
network conditions
... people are paying for these games subscriptions, so quality
is really important
... [Monetization options - prediction as a service]
... A maybe more controversial one: prediction as a
service
... if you know people are flying in for a game, this can help
target advertizing
... there are naturally privacy concerns - but that can maybe
be addressed through some form of aggregation
... These are just but a few of the possible scenarios - many
could also occur in the case of smart factories
Jonas: determining which services would be valuable is something that we want to help determine
Eric: from your view point as new contributors to W3C, how do you see us as a group helping in what you do, and your customers? any insights?
Jonas: it's really important to
drive functionality that has applicability, it needs to be
driven by actual domain
... we see this as a problem coming increasingly forward in the
mobile space
... network performance is bounded by physics, and monetary
ones - so we'll have to bring more intelligence in this
space
... we have started with lots of good discussions
... We want this to be easy to use
DanD: how do you transmit this prediction? what form?
Jonas: it's out of band
DanD: is it an API call? Push or pull?
Jonas: we can do both
... what we've seen as the main usage is subscribing to
updates
... the interval of sending predictions is dynamic
... there is no point to do prediction for e.g. a static
user
... we adjust the depth of the analysis based on what we
detect
... when moving, it needs very frequent updates
... we've seen subways as the most varying environment
Jon: there is lots of learnings
in this room
... we think that 5G brings new challenges given to the new
topology (frequencies, cell size)
... we hope this creates new opportunities - some times to try
again that something that failed in the past differently
eric: one thing that resonated
with me is when you said you didn't want to change the whole
network architecture
... and thus looking at an app-layer approach
DanD: if you have a constrant
expectation of QoE, you can either reduce the bandwidth or
augment the traffic
... on mobile networks, some antennas are adjusted physically
automatically to support rush hours
... I assume your prediction engine can take input from
multiple sources
David: Schinazi: have you put some thoughts on authenticating this data?
Jonas: will come to this
Song: in the case of broadcasting or multicasting by operators?
Jonas: with MBBS? that's a different since you have allocated bandwidth
Song: does it make sense to monitor the traffic from the broadcasting?
Jonas: possibly, but we've not
looked at that problem at this time
... [API considerations]
... we have views on what can be done here
... Current status of network is interesting by itself
... apps are already monitoring network quality, but that's not
trivial to do, and have a generic service to provide this can
be useful
... this doesn't prevent keeping locally maintained version of
this for big providers
... Predictions is considering changes in location - but not
just of the UE, but of the network link itself (e.g. connection
from a train)
... if we want to bring standardization in this space, we would
want to allow for a flexible approach
Dom: but you said bandwidth, latency, cell loads were key - we would probably want to start with a minimal set from a standardization perspective
Jonas: fine as long as it is
extensible
... for predictions, you need to also communicate probabilities
of evolution
... Another aspect is timeframe - forward looking, are you
looking to short/medium or long term
... the longer the timeframe, the less reliable the
prediction
... You also want to distinguish information on a client basis,
or an application basis
... Applications here in the broad sense - not as in "browser",
or even "Web app" - a given Web page may have different type of
network usage
... Another important aspect is who can get the link
predictions?
... our approach is that it should be protected and provided to
the client
MarkW: do you imagine that the browser would obtain that info from the network? or would apps obtain it directly?
Jonas: I'll come to that
shortly
... Another consideration: what are we optimizing for?
... do you want info on the most likely, the worst case, the
best case, or app-specific
Dom: are you producing all of these at the moment? is there a cost in doing this broadly?
Jonas: we can do them all - but
not every app is necessarily interested in all of these
... In terms of accuracy, there may be room for some high
levels classifications; in what we've shown before, this was
using fairly high level of details
... [W3C vs other layers]
... that's how we see this working out:
... a Web app, talks to a browser provided API, that interfaces
with IETF protocols
... the endpoint could be anywhere - in the network operator or
elsewhere
... the main change in the network we see today is that things
are getting closer to the end device
... so the further away you move from the user, the prediction
behavior become less important
... we expect also some feedback from the client side to the
operator
... e.g. the identify of the subscriber - this limits what a
Web app could do talking directly to a LPP server
MarkW: once the device is authenticated on the work, the operator provides info the device/browser, is there any reason not to expose it to the app?
DavidSchinazi: one reason not to expose it is fingerprinting
dom: [explanation of what fingerprinting is]
Jonas: this may be a reason to reduce some of the accuracy
MarkW: if that info were
available, I would definitely use it
... a challenge is getting this adopted by browsers / OS
... how do you think that would happen?
Jonas: our intention is to have the required open source enablement
MarkW: why would network operators provide this?
Jonas: Jon covered this earlier -
there is limitation in network improvements (costly to deploy
more base stations)
... network awareness helps limit the investment needed to get
an average higher throughput
Dom: has this been in standards settings yet?
Jonas: not yet - W3C is where we're starting
DavidSchinazi: how do you envision getting that information from the network?
Jonas: on the changes that needs
to be done - we already getting lots from ETSI/3GPP APIs
... so the main question is how to bring it to the end
device
... The question becomes how do you know where to get the
status/prediction from?
... we've focused on mobile networks, but this needs to be
widely applicable
... We think this should be coming from the service connection
point
... but we need to understand how this applies to e.g.
Wifi
... we could do this via some sort of DNS extension
DavidSChinazi: what do you mean by network id?
Jonas: e.g. AT&T in the US
DavidSchinazi: not all OS will provide that information to apps (incl browsers) for privacy reasons
Dom: in that case, the hook would have to be pushed to the OS level
DavidSchinazi: right - but that may get more push back
Jonas: we've been working with
Android and Chrome, where we haven't hit that issue yet
... An alternative would be to go through the operators
directly, but that are challenges to scaling that
MarkW: in the worse case, exposing a lot of data information may be equivalent to location - and hence tied to geolocation consent
DavidSchinazi: but that may be hard to understand / accept by end users
Song: we've found that some users would consent depending on the expected impact (e.g. fast games)
MarkW: I think it's a matter of explaining to the user that location is relevant to high-performance network - not sure how easy that is, but if it's needed, we need to figure it out
Jonas: Another consideration is in terms of security - we want to re-use encryption and authentication
Dom: how do you authentify that
the LPP server is indeed tied to the network provider?
... given that this could be spoofed at the e.g. DCHP
server
Jonas: we have a proprietary solution to this, but we need to look more into this from a standards perspective
Sudeep: assuming two users are nearby - would they get the same data?
Jonas: no - even two apps on a single device could get two different results?
Sudeep: but two users with the same app end point? would they get the same info?
Jonas: if they had the same phone...
Sudeep: looking at it from a privacy perspective, would there be shared data?
Jonas: no - predictions include device specific profile info
Sudeep: thank you so much
Dom: how/where would this be standardized if it is?
Jonas: the first thing would be to determine the most valuable use cases
Sudeep: we have work to do to
figure this - based on the use cases, the privacy constraints,
the overall architecture
... we'll work on evaluating interest from members to identify
next steps
Sudeep: we had good discussions
today on a number of topics
... I would like to use the remaining time to hear your
thoughts
... first, we have been looking at use cases and requirements
that derive from them
... but at some point, we need to go through the litmus test
where we look at the 3 factors: privacy & transparency,
trust, data integrity
... we also need to architectural considerations - including
the role of the cloud, browser, device, networks - we will need
to involve the TAG team on these discussions
... and derive from all this deliverables for the IG e.g. white
papers
... I want to use this an opportunity to plan for the upcoming
6 to 8 months
Song: what is the TAG?
Sudeep: TAG is the Technical Architecture Group - we had planned to invite them today, but didn't have already anything to convey to them today
Dom: we had a TAG observer earlier during the hints discussion fwiw
Song: in terms of output, what kind of architectural outcomes do you expect?
Sudeep: maybe some kind of white paper or recommendation
Song: draft specifications?
Dom: we can create separate CGs/WGs to build specs once we have identified good candidates
Song: if we need to build a CG/WG, do we need approval from W3C?
Dom: CGs can be created very easily (only need 5 supporters); WGs are much more involved
Sudeep: in our process of going through these various considerations, we need to involve other SDOs
Dom: my view is that we need to
go in depth in some of the topics we've looked at - e.g. LPP,
Edge
... trying to build architectures that scale, and hear from the
right communities to fulfill these views
... we should drive requirements, check which technical spaces
they point to (e.g. LPP, Edge) and deep-dive on these
... including analyzing their privacy & security impact
Song: China Mobile is running a
gaming service
... In terms of broadcast, we will be broadcasting Winter
Olympic Games in 2022
... the 4K UHD broadcasting service
... in terms of challenges: our subscribers base is huge, so
this implies high concurrent streaming
... I heard NHK is looking at 8K streaming service
@@@_NHK: we stream mostly through fiber
Sudeep: any particular challenge from a browser perspective?
Song: in China, most of the
mobile users are using WeChat
... most of the video content is going to be present in a
mini-app (an HTML5-based app)
... this is the first portal for mobile users in China
... the HTML5 UX impacts directly broadcasting for Winter
Olympics
... For most marketing companies, promotion will also be done
in HTML5
Sudeep: can you identify requirements that need to be derived from this?
Song: we will have field tests in
the future
... testing at large scale, in all locations is difficult - we
want to ensure streaming is smooth even in rural areas
... the requirement is to enable UHD streaming across all HTML5
applications across the whole country
Sudeep: this is about real-time streaming vs on-demand video
Song: for 4K broadcast, we need
to think about latency and launch time
... [explaining mini-apps]
Sudeep: what I'm sensing is that streaming use cases are of high interest
Jonas: background fetch is
another space that would be interesting to map to network
awareness
... offloading the macro network helps
... being able to specify in a background fetch a hint of what
kind of optimization you're looking at would be useful
... Gaming and Media are fairly similar from a LPP perspective,
but background fetch is very different
Sudeep: We haven't touched about
the topic of browser tools - I'll bring this up in a call
... Today we have throttling and simple network emulation, but
having possibliities to test in more detailed network profiles
would be useful
Sudeep: we have learned about
today; great to meet you all
... let's continue to work on requirements emerging from use
cases and evaluate solutions