Network Quality Monitoring and Prediction
Network Quality Monitoring and Prediction work stream
Objective: Understand how Network Quality parameters can assist Web applications and build a roadmap to enable its adoption
The following themes have been identified to guide our initial exploration:
- understanding what are the existing APIs available, how effective are they and if can they be extended?
- what are the precise requirements or considerations for new network hints API definition?
- will API or parameters identified meet the 'litmus test' criteria set related to Data Integrity, Privacy, Trust and Transparency?
Work mode
Proposal: A 1 hour call monthly (or biweekly, if needed) that starts with a 20-30 minutes presentation, followed by 20 minutes discussion, and 10 minutes dedicated to identify follow up discussions required and next steps.
Stakeholders
- telecommunication operators
- cloud-computing providers
- browser vendors
- network infrastructure solution providers
- (OS vendors?)
- application developers
- CDN providers
Themes
Use-Case and Requirements Analysis Phase
- Prepare Use-case list & start Requirements gathering
- Evaluate existing API and evaluate possible extensions
- e.g. Network Information API, Background Fetch/Sync API
- Learnings from previous attempts in other areas (W3C, IETF, etc.)
- WebRTC
- Media and Entertainment
- others
Challenges to explore in sketching these use cases:
- what use-cases can benefit from network quality information?
- what are the existing APIs available and how effective are they?
Potential topics of presentations:
- Invite W3C members to present use-cases and requirements
- Invite W3C members from various CG/IG/WG to present information about Network linked API supported today
API Parameters Benefit Analysis
- Study API and parameter considerations and cost-benefit analysis
- API benefits
- Optimization goals
- Information types
- Application focus (is it per client or per application)?
- Accuracy and benefits
- Security implications
- Privacy considerations
- Architecture Analysis
- Device side Architecture: Network Hints utilized directly by WebApp versus implemented inside Browser Framework
- System Architecture: New interfaces and entities involved, deployment aspects
Challenges to explore in sketching these use cases:
- how does client-part be able to get information about network quality ?
- can client-part benefit by getting advance information about network quality in a specific mobile path?
- how does the Web application use such network hints for improving application Quality of Experience?
Potential topics of presentations:
- Value of specific parameters or APIs and any test results.
- Present architecture recommendations (if any) for TAG review
Liaisons Interaction Phase
Focus areas:
- Share findings with other W3C groups like Privacy IG, WebRTC WG, WebTransport CG etc.
- Expert inputs from other Standards groups, exchange ideas
- ETSI, 5GAA, etc.
Documentation Phase
- Consolidate information gathered and capture in a whitepaper
Prototyping Phase
- Study new API and parameter considerations and Benefit analysis
- Evaluation of sample reference networking APIs
- Analyse feasibility to extend Developer Tools for application performance testing
- Discuss interoperability aspects
Lessons and Questions
Scope
- The primary goal of the workstream is to study use-cases that can benefit by using network quality information, either instantaneous or predicted values, to adapt to varying network conditions.
- The secondary goal is to identify requirements, both from application or network perspective, such that the right network quality parameters are monitored and used to improve the quality of experience of the use-case.
- The workstream also discusses similar existing APIs introduced for this purpose in web browsers in the past and also in different layers of the software stack or operating systems in mobile and personal computer laptop devices.
Where does Network Quality Monitoring fit in Web Application context?
Applications today don’t have any direct information about the network conditions obtained via network service providers or internet service providers. Applications which see value in adapting to changing networking conditions make measurements using solutions deployed at the endpoints, where it probes the network quality by tracking packet response arrival rates and other similar means. There are already existing proposals within W3C where such API have been defined and implemented. Some of the network quality measurements are handled within the application layer or gathered from servers that make similar measurements from the remote end. These solutions have drawbacks and hence there is scope for further enhancements.
This is where Network Quality Monitoring study can help to lot to identify new parameters, where these can be sourced from and how they can be utilized by applications running in the devices or on the cloud to improve QoE. These can also be called “hints” from the network to the device. The reverse is also possible where the network gets “hints” from the applications, so that it can allocate resources in a balanced manner.
How does Network Quality Monitoring help?
Network “hints” can be used by applications in various ways. The “hints” could be instantaneous ones or predicted ones which give an early insight about the future network conditions. With such information, the application can take necessary steps to ensure user experience is not adversely impacted, such as by additional advanced buffering or lowering bandwidth utilization to maintain real-time operations, etc. This can vary depending on the type of applications e.g. video streaming or online gaming or video conference calls.
What are the key guiding principles to follow when defining solutions?
We need to consider hyper scale solutions with : - Broad applicability and availability globally on multiple network technologies - Guaranteed integrity of data - Minimal exposure of personal identifiable information (PII) - Clear user engaged consent
https://www.w3.org/2019/09/17-web-networks-druta-hints.pdf
What should be our focus?
Focus must be on solutions that provide “hints” to and from the network layer in-order for the Applications to inform and be informed on:
- Network conditions
- Network access availability
- Technology support (radio, etc.)
The rational for this is that “hints” are
- Not guaranteed to be available
- Can be ignored – no contractual obligation if no mutual benefits
- Can be used to proactively adapt the application to network conditions
- Can reliably convey application characteristics
What is meant by Network Link Performance Prediction?
Network “hints” can be about the network conditions in the near future. Wireless networks especially have significant challenges around the wide variations in bandwidth at any given point in time. This has been illustrated using a real example by the Intel team who presented a solution called Link Performance Prediction, at TPAC, Fukuoka 2019. The slides presented are available at . Ref: https://www.w3.org/2019/09/17-web-networks-lpp.pdf
Networks are “best effort” today and this limits types of services allowed. Having a more deterministic insight helps applications to be in control. This includes current and near future link performance. Parameters can be of many types, such as bandwidth, latency, cell load, etc. Another example of similar study is done in ETSI Multi-Access Edge Computing group where a concept call Predictive QoS is being introduced. This was presented in the Web & Networks IG meeting and more details are available at https://www.w3.org/2020/03/20-web-networks-5Gaa-predictive-qos.pdf
Predictive QoS data is provided by the MEC infrastructure to applications. An example from the automotive industry was presented.
What kind of solutions are we looking at and what has been tried so far?
If we look at the work done in W3C so far, the Network Information Web Platform Incubator Community Group defined a few API which are currently implemented in some browsers. These API can get round-trip-time data, network bandwidth and type information. More details about this API are available at: https://wicg.github.io/netinfo/
The API defined provides the following “hints” to the application:
- Connection Type (WiFi, Cellular, BT, Ethernet, etc)
- Network Information (Downlink Max datarate, datarate, RTT, etc)
The usage of the API, the challenges and areas of improvement was presented by Google Team in the Web & Network IG. More information is available at: https://www.w3.org/2020/02/05-web-networks-Network-Quality-Estimation-in-Chrome.pdf
On the same lines, we would like to study more if there any other such APIs which can give insights into the current and future network conditions, what kind of parameters to consider, etc. are areas we would like to incubate ideas and along the way solicit effective solutions.
What are the next generation use-cases that have strong dependencies on networking performance?
n the IG meetings, members brought forward several upcoming use-cases which rely on efficient and effective use of network resources for enhance QoE. Some of these use-cases have been documented in github during our early meetings in Q3 ‘2019. They are available at https://github.com/w3c/web-networks/issues
Use cases that can benefit most from this:
- TBD
What is the status of NetInfo API in current browsers?
Several browsers have implemented the Network Information API and are been used by applications. The diagram below gives a high-level picture of the browsers supporting it, marked in green boxes.
(source)
Can you explain with examples how NetInfo API is helping web applications?
In our 6th Interest Group meeting, Google team provided as statistic of the webpages used this API. Over 20% of webpages across all platforms used this [4] as of December 2019.
What are the challenges to adopt NetInfo API in current browsers?
There are couple for challenges that need to be addressed to scale up the scope and usage of such APIs. They are:
- Multiple browser platforms and each differ in availability of APIs
- Algorithms don’t have all the necessary information of radio state to make accurate measurements
- There must be no overhead to measure network quality.
- The APIs must ensure privacy of users are safeguarded.
- Need to ensure the network quality estimates are responsive enough to fast varying networking conditions
What are improvements possible to improve adoptability of NetInfo API?
How does Network Link Performance Prediction work?
What are the parameters that are of interest for Network Link Performance Prediction?
Some of the early thoughts shared by Jonas and Jon Devlin from Intel who presented this idea are captured in the following slide. This needs more discussions and feasibility analysis within the Interest Group.
