RE: Minutes from W3C M&E IG / W&N IG call 1 September 2020

Thank you, Chris for the meeting minutes. Hope the joint meeting was beneficial to MEIG IG, just as it was for our W&N IG members.

Dear all,

We had 3 topics presented in our Joint meeting. As Chris mentioned below, if you would like to follow-up on any topic, you can use the Web & Networks IG's public mailing list [3].

Alternatively, if you prefer using Github, we have created github issues corresponding to the 3 topics where you can add your questions/suggestions. 

1.  Developer tools - Real Network Emulation Extension in Browser Tools and Trace Format Specification Proposal
https://github.com/w3c/web-networks/issues/17

2. Discovering Server that provides predicted network condition info
https://github.com/w3c/web-networks/issues/18

3. Network : Application usage of network condition predictions
https://github.com/w3c/web-networks/issues/16

Please feel free to use either channel as per your convenience.

Best Regards
Sudeep	
Co-Chair, Web & Networks IG

-----Original Message-----
From: Chris Needham <chris.needham@bbc.co.uk> 
Sent: Tuesday, September 1, 2020 9:22 PM
To: public-web-and-tv@w3.org; public-networks-ig@w3.org
Subject: Minutes from W3C M&E IG / W&N IG call 1 September 2020

Dear all,

The minutes from today's Media & Entertainment Interest Group and Web & Networks Interest Group joint call are now available [1], and copied below.

Thank you to Jonas Svennebring for joining us and presenting an update on Network Link Performance Prediction. The presentation slides are available at [2].

I recommend we hold follow up discussion on the Web & Networks IG's public mailing list [3].

Kind regards,

Chris (Co-chair, W3C Media & Entertainment Interest Group)

[1] https://www.w3.org/2020/09/01-me-minutes.html
[2] https://¯www.w3.org/¯2011/¯webtv/¯wiki/¯images/¯7/¯79/¯Intel_LPP_update_W3C-Sept1.pdf
[3] https://lists.w3.org/Archives/Public/public-networks-ig/

W3C	– DRAFT –

Attendees

Present
    Andreas_Tai, Ali_C_Begen, Chris_Needham, Dan_Druta, Dominique_Hazael-Massieux, Francois_Daoust, Huaqi_Shan, Jon_Devlin, Jonas_Svennebring, Kaz_Ashimura, Kazuhiro_Hoya, Larry_Zhao, Nigel_Megitt, Peipei_Guo, Pierre_Lemieux, Piers_O'Hanlon, Song_Xu, Sudeep_Divakaran, Takio_Yamaoka, Tatsuya_Igarashi, Theoharis_Charitidis, Will_Law, Yajun_Chen, Yasser_Syed, Zoltan_Kis

Regrets

Chair
    Chris, Igarashi, Pierre

Scribe
    cpn, kaz

Contents
    Introduction
    Dev tooling
    LPP service
    MPEG-DASH
    Next steps

Meeting minutes

# Introduction

https://¯www.w3.org/¯2011/¯webtv/¯wiki/¯images/¯7/¯79/¯Intel_LPP_update_W3C-Sept1.pdf

Chris: Joint meeting between M&E IG and W&N IG

Sudeep: I'll introduce our guest speaker. The topic is our network quality and prediction workstream .... At TPAC 2019 there was a presentation from Jonas. It's relevant for web apps on mobile phones. Conditions don't necessarily guarantee high throughput, it's time varying .... The Intel team came up with LPP as possible solution. This meeting will give an update on what they've done, tooling for web developers .... Also questions and challenges.
.... I'd like to invite Jonas to present.

Jonas: There are 4 things to talk about. It's a high level walk-through .... For those interested, please reach out, can discuss in more detail offline .... First is to introduce the topic, from Fukuoka 2019, then dev tooling, and MPEG-DASH .... When we look at 5G and onwards, edge computing, increasing relation between and within networks .... With LPP, we want to bring an awareness in the app side, but also forward looking, using prediction .... From a W3C perspective, how can we bring this to the application?
.... We're not trying to force any requirements for app behaviour, that depends on the app .... We're targeting the main parts such as bandwidth and latency, also dynamic pricing in the network .... We do this by having an LPP service in the network, at the service provider. You have a normal data link between client and server .... We're not touching the actual data itself .... We do this by getting input from the cells you're connected to, etc. Typically targeting 3GPP connections, but nothing precludes using it with other connections such as wifi. It's agnostic from a client point of view.
.... It doesn't rely on GPS, we don't expose privacy related data outside the operator .... It was discussed at TPAC whether aspects of the prediction could pose a privacy concern - e.g., if you have a good connection or not .... We've seen so far, this kind of information would be available to apps anyway, by bandwidth measurement .... One of the key examples we have is media streaming. A media server gets predictions from the LPP server, and the client adjusts how it gets media from the server .... We try to pre-fetch data if the user moves to a congested network cell or an area without coverage .... We can also limit the amount of buffering if you know the connection is good. Will come back to this later .... One challenge today is how to get wider usage - chicken and egg problem .... Also, if we have multiple LPP deployments in different networks, what server to connect to?

# Dev tooling

Jonas: Internally, we have different tools to emulate. We thought would be useful to have network tracing tools .... We run them here as a Chromium extension. There are different tools emulate based on trace files .... We have files with behaviour of the network over time, e.g., a train or car journey on a given path .... We can emulate the network quality based on those traces .... It's primarily for wireless networks, but could also be for wired, but that's less interesting .... We have a spec for these files and tools to collect them .... We're looking to see if there's interest to release these tools to the wider community .... The main tool is the replay tool. In Chromium there's a network trace section in the dev tools.
.... You choose a trace file, and it shows a graph of bandwidth variation over time .... Currently, browsers have the ability to set a static throttling. But this gives ability to vary over time .... We can also use this to give forward-looking predictions from LPP .... The trace file format itself is inspired by the HAR format .... There is a set of trace events, time + network information .... The spec proposal for that is available .... We also have a tool for gathering the traces. You can run it on your own server .... If there's interest, we could release these tools, and create a library of traces that people have uploaded from around the world

# LPP service

Jonas: You can have a LPP server in the network, but how can we get wider adoption?
.... Could we launch a global LPP service, if your own network provider doesn't have it?
.... This wouldn't have the same accuracy if the server was in the network - e.g., data on cell loads .... You'd fall back to data reported from the browser (privacy impact) .... We could host this, but it's not a desirable long term solution. We're interested in views on this, also about privacy aspects .... We want to do it in a way that's good for the community, privacy preserving .... We are looking at what LPP server to use, different schemes.
.... Initially, a simple lookup service the client can connect to. It can give you a link to a registered LPP service based on your IP address .... If you know of a better way to do this - e.g., maybe an edge service lookup, please let us know

# MPEG-DASH

Jonas: We're interested in the prediction methodology overall, not just for media streaming, but also cloud gaming, non realtime .... We want the technology to fit a large number of applications.
.... There are things like SAND (sp?) that are more specific, but we're looking more generally .... What we've done is to start with VLC media player, and then browser based players .... We took the dash.js reference library, modified the example player without touching the library, and vice versa .... We're changing the buffer target. We showed an example video at TPAC.
.... The green shows the forward prediction, the brown is target buffer level .... We look at different methods and algorithms to adjust based on different scenarios.
.... There could be better variables to use. What we've seen, is depending on the type of streaming, e.g., sports where you want minimal buffering, or optimizing for low data consumption in social media .... or high quality movie where you optimize for quality over buffering. Different usages have different needs .... Can optimize differently. A bandwidth expectation, required bandwidth. If you're confident can meet required bandwidth, can reduce buffering .... Another is for pre-buffering if we predict a gap. These behaviours can be run with different levels of aggressiveness depending on prediction .... How do we allow for different streams to have different configurations? Can we use the manifest file to describe the behaviour profiles?
.... Another thing: could the manifest be used for inband or out of band events. Currently we drive predictions over a separate channel, out of band?
.... Could it be done more in line with the DASH standard?
.... Predictions are based on how the client is perceiving the network. The application's view of bandwidth depends on what it's doing.
.... If you're downloading large amounts data, it's different if lots of small amounts .... We're looking to get feedback from DASH chunks as they're downloaded .... We're interested to hear your feedback on this

Piers: Is there any authentication needed to access the LPP, to retrieve data on network locations? Also, what about the granularity and accuracy of predictions - how specific are they to IPs, how often updated?

Jonas: There's the case with the LPP server in an operator network. In this case we know who you are, which cell you're connected to. So here we make predictions for you specifically. It sohuld be well secured from a privacy point of view.
.... Outside the network, it's less accurate and reliable. If you're in a specific position, you can be connected to different networks, e.g., mobile and wifi. This would then be less secure, as you could spoof your location.
.... How could the service be abused? Could get false data, but this could be identified. So there'd be a best effort security mechanism.

Piers: How would authentication to the browser level work?

Jonas: That wouldn't be needed, as it's in the network.
.... The only metric you could get would be the client's position or network via IP. The script itself couldn't get base-band info from the phone

Piers: How would the player library retrieve the information?

Jonas: We wouldn't give out any operator or client sensitive information .... The request would be made from the client app to the LPP server in the network

Piers: And how often is the data update?

Jonas: Target today is on a per-second level, but we only issue updates when there's a large enough delta in the prediction

Piers: How does it compare to the netinfo API? I guess predicting into the future .... We're working on transport-info header where the server transports information about calculated bandwidth, we're trialing for input to DASH .... This could be another source of inband data.

Jonas: Prediction could come from different sources, don't see any limitation. COuld be interesting to see how that would fit

Igarashi: How reliable is the prediction? Do you assume the LPP service can also use network operator metrics?

Jonas: Goal has been to make good predictions, the level of accuracy is much higher when we run in operator based networks

Igarashi: It's hard to predict human behaviour, e.g., people joining the network

Jonas: It's not to the same accuracy without getting information from the baseband.

Igarashi: Have you measured the prediction accuracy, compared with actual measurements?

Jonas: Yes, we've run trials together with SKT in Korea. I can't share details right now, but we have data that we're using to improve .... Accuracy is good enough for streaming scenarios, also cloud gaming which is time sensitive

Ali: Why would a service provider allow someone to know about network performance, what's their incentive to share the data?

Jonas: They're not communicating with us, you can know the network quality regardless

Ali: For example, I have a home connection from two service providers, I can pick the one I like. But does this become a bit more public with this kind of information?
.... The service providers may cheat on this kind of data

Jonas: It doesn't work if you cheat, as users would get a poor experience .... You can't download information about the operator's network, only the predictions. You can get historical data already

Ali: If video playback stalls, could be in the network, wifi, upstream server. If the tool allows me to identify the service provider, could lead to awkward situation, hence question about incentives

Jonas: The main usage isn't wired connections, the dynamics are mainly around mobile networks. In such a scenario, you're running out of CDNs. Streaming from somewhere remote, not from local CDN

Ali: How to deal with encrypted traffic?

Jonas: Doesn't need information about the data, we just predict based on the connection itself

Ali: Are any tools available for research purposes?

Jonas: The trace replay tools are one way of developing and debugging behaviours, and tools for collecting traces

Kaz: This mechanism is applicable to media distribution, also IoT clients not just browsers?

Jonas: Yes, that's the intention

Kaz: How to manage the identifiers for users and devices? For example, W3C has decentralized identifiers that could be managed by blockchains .... Maybe you're using IP address-based identification at the moment, though

Jonas: yes, that is the current approach

Kaz: BTW, are the slides available publicly?

Chris: yes, will distribute the link

# Next steps

Chris: next MEIG call will be on Oct-6

Kaz: We can follow up this topic on our mailing lists

[adjourned]

Received on Friday, 4 September 2020 11:42:35 UTC