13:52:43 RRSAgent has joined #me 13:52:43 logging to https://www.w3.org/2020/09/01-me-irc 13:52:48 Zakim has joined #me 13:53:18 Meeting: Media & Entertainment IG / Web & Networks Joint Meeting 13:56:51 Present: Chris_Needham, Sudeep_Divakaran, Yajun_Chen 13:58:06 Theo has joined #me 13:58:15 takio has joined #me 13:58:21 tidoust has joined #me 13:58:21 dom has joined #me 13:58:48 sudeep_ has joined #me 13:59:39 Yajun_Chen__ has joined #me 14:00:13 kaz has joined #me 14:01:20 Meeting: Media and Entertainment IG 14:01:33 igarashi has joined #me 14:01:40 present+ Kaz_Ashimura, Ali_C_Begen, Adreas_Tai, Chris_Needham 14:02:03 Present+ Dominique_Hazael-Massieux, Francois_Daoust, Jon_Devlin, Jonas_Svennebring, Kazuhiro_Hoya, Takio_Yamaoka, Tatsuya_Igarashi, Piers_O'Hanlon, Ali_Begen, Dan_Druta, Andreas_Tai, Pierre_Lemieux, Theo, Kaz_Ashimura, Huaqi_Shan 14:02:12 present+ Dan_Druta, Dominique_Hazael-Massieux, Francois_Daoust 14:02:37 present+ Will_Law 14:02:40 present+ Huaqi, Jon_Devlin, Jonas_Svennebring, Larry_Zhao, Pierre 14:02:43 scribenick: cpn 14:02:57 present+ Piers_O'Hanlon, Sudeep, Takio_Yamaoka 14:03:14 present+ Tatsuya_Igarashi, Theo, Will_Law, Yajun_Chen 14:03:49 piers_ has joined #me 14:04:16 atai has joined #me 14:04:24 Larry_Zhao has joined #me 14:04:31 Present+ Song_Xu 14:04:34 present+ Kazuhiro_Hoya, Song_Xu 14:04:38 Topic: Introduction 14:04:47 present+ Zoltan_Kis 14:04:50 Chris: Joint meeting between M&E IG and W&N IG 14:05:02 rrsagent, make log public 14:05:06 rrsagent, draft minutes 14:05:06 I have made the request to generate https://www.w3.org/2020/09/01-me-minutes.html kaz 14:05:07 nigel has joined #me 14:05:21 Sudeep: I'll introduce our guest speaker. The topic is our network quality and prediction workstream 14:05:47 zkis has joined #me 14:05:53 kazho has joined #me 14:05:57 present+ Yasser_Syed 14:05:59 ... 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 14:06:11 present+ Zoltan_Kis 14:06:19 Agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2020Aug/0008.html 14:06:23 ... 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 14:06:31 ... Also questions and challenges. 14:06:45 ... I'd like to invite Jonas to present. 14:07:13 Present+ Nigel_Megitt 14:07:23 Jonas: There are 4 things to talk about. It's a high level walk-through 14:07:48 ... For those interested, please reach out, can discuss in more detail offline 14:07:55 Larry_Zhao_ has joined #me 14:08:15 ... First is to introduce the topic, from Fukuoka 2019, then dev tooling, and MPEG-DASH 14:08:50 ... When we look at 5G and onwards, edge computing, increasing relation between and within networks 14:09:12 ... With LPP, we want to bring an awareness in the app side, but also forward looking, using prediction 14:09:23 ... From a W3C perspective, how can we bring this to the application? 14:09:41 ... We're not trying to force any requirements for app behaviour, that depends on the app 14:10:00 ... We're targeting the main parts such as bandwidth and latency, also dynamic pricing in the network 14:10:02 Chair: Chris, Pierre, Igarashi 14:10:34 ... 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 14:10:45 ... We're not touching the actual data itself 14:11:35 ... 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. 14:11:53 ... It doesn't rely on GPS, we don't expose privacy related data outside the operator 14:12:00 present+ Nigel_Megitt 14:12:16 ... 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 14:12:38 present+ Peipei_Guo 14:12:40 ... We've seen so far, this kind of information would be available to apps anyway, by bandwidth measurement 14:13:00 Present+ Dominique_Hazael-Massieux 14:13:09 ... 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 14:13:29 ... We try to pre-fetch data if the user moves to a congested network cell or an area without coverage 14:13:50 ... We can also limit the amount of buffering if you know the connection is good. Will come back to this later 14:14:10 present+ Yasser_Syed 14:14:15 ... One challenge today is how to get wider usage - chicken and egg problem 14:14:36 ... Also, if we have multiple LPP deployments in different networks, what server to connect to? 14:14:44 Topic: Dev tooling 14:15:07 Jonas: Internally, we have different tools to emulate. We thought would be useful to have network tracing tools 14:15:33 ... We run them here as a Chromium extension. There are different tools emulate based on trace files 14:15:51 ... We have files with behaviour of the network over time, e.g., a train or car journey on a given path 14:16:02 ... We can emulate the network quality based on those traces 14:16:21 ... It's primarily for wireless networks, but could also be for wired, but that's less interesting 14:16:28 ... We have a spec for these files and tools to collect them 14:16:50 ... We're looking to see if there's interest to release these tools to the wider community 14:17:10 ... The main tool is the replay tool. In Chromium there's a network trace section in the dev tools. 14:17:26 ... You choose a trace file, and it shows a graph of bandwidth variation over time 14:17:52 ... Currently, browsers have the ability to set a static throttling. But this gives ability to vary over tyime 14:17:55 s/tyime/time 14:18:16 ... We can also use this to give forward-looking predictions from LPP 14:18:44 ... The trace file format itself is inspired by the HAR format 14:19:10 ... There is a set of trace events, time + network information 14:19:20 ... The spec proposal for that is available 14:19:49 ... We also have a tool for gathering the traces. You can run it on your own server 14:20:10 igarashi_ has joined #me 14:20:32 ... If there's interest, we could release these tools, and create a library of traces that people have uploaded from around the world 14:20:50 Topic: LPP service 14:21:22 Jonas: You can have a LPP server in the network, but how can we get wider adoption? 14:21:28 present+ Theoharis_Charitidis 14:21:40 ... Could we launch a global LPP service, if your own network provider doesn't have it? 14:21:55 ... This wouldn't have the same accuracy if the server was in the network - e.g., data on cell loads 14:22:13 ... You'd fall back to data reported from the browser (privacy impact) 14:22:43 ... We could host this, but it's not a desirable long term solution. We're interested in views on this, also about privacy aspects 14:22:58 ... We want to do it in a way that's good for the community, privacy preserving 14:23:20 ... We are looking at what LPP server to use, different schemes. 14:23:52 ... 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 14:24:38 ... If you know of a better way to do this - e.g., maybe an edge service lookup, please let us know 14:24:41 Topic: MPEG-DASH 14:25:02 Jonas: We're interested in the prediction methodology overall, not just for media streaming, but also cloud gaming, non realtime 14:25:15 ... We want the technology to fit a large number of applications. 14:25:39 ... There are things like SAND (sp?) that are more specific, but we're looking more generally 14:26:07 ... What we've done is to start with VLC media player, and then browser based players 14:26:39 ... We took the dash.js reference library, modified the example player without touching the library, and vice versa 14:27:08 ... We're changing the buffer target. We showed an example video at TPAC. 14:27:28 ... The green shows the forward prediction, the brown is target buffer level 14:28:10 ... We look at different methods and algorithms to adjust based on different scenarios. 14:28:57 ... 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 14:29:17 ... or high quality movie where you optimize for quality over buffering. Different usages have different needs 14:29:52 ... Can optimize differently. A bandwidth expectation, required bandwidth. If you're confident can meet required bandwidth, can reduce buffering 14:30:36 ... Another is for pre-buffering if we predict a gap. These behaviours can be run with different levels of aggressiveness depending on prediction 14:31:12 ... How do we allow for different streams to have different configurations? Can we use the manifest file to describe the behaviour profiles? 14:31:53 ... 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? 14:32:02 ... Could it be done more in line with the DASH standard? 14:32:32 ... Predictions are based on how the client is perceiving the network. The application's view of bandwidth depends on what it's doing. 14:32:49 ... If you're downloading large amounts data, it's different if lots of small amounts 14:33:19 ... We're looking to get feedback from DASH chunks as they're downloaded 14:33:38 ... We're interested to hear your feedback on this 14:34:08 igarashi has joined #me 14:34:11 q? 14:34:48 q+ 14:35:29 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? 14:36:18 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. 14:37:03 ... 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. 14:37:43 ... How could the service be abused? Could get false data, but this could be identified. So there'd be a best effort security mechanism. 14:38:39 Piers: How would authentication to the browser level work? 14:39:06 Jonas: That wouldn't be needed, as it's in the network. 14:39:12 Larry_Zhao has joined #me 14:39:57 ... 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 14:40:10 q+ Ali 14:40:10 Piers: How would the player library retrieve the information? 14:40:50 Jonas: We wouldn't give out any operator or client sensitive information 14:41:09 ... The request would be made from the client app to the LPP server in the network 14:41:28 Piers: And how often is the data update? 14:41:57 Jonas: Target today is on a per-second level, but we only issue updates when there's a large enough delta in the prediction 14:42:23 q? 14:42:31 Piers: How does it compare to the netinfo API? I guess predicting into the future 14:43:05 ... We're working on transport-info header where the server transports information about calculated bandwidth, we're trialing for input to DASH 14:43:16 ... This could be another source of inband data. 14:43:26 q+ 14:44:05 Jonas: Prediction could come from different sources, don't see any limitation. COuld be interesting to see how that would fit 14:44:38 Igarashi: How reliable is the prediction? Do you assume the LPP service can also use network operator metrics? 14:45:29 Peipei_Guo_ has joined #me 14:46:17 ack iga 14:46:36 nigel has joined #me 14:46:46 Jonas: Goal has been to make good predictions, the level of accuracy is much higher when we run in operator based networks 14:47:17 Igarashi: It's hard to predict human behaviour, e.g., people joining the network 14:48:14 Jonas: It's not to the same accuracy without getting information from the baseband. 14:48:37 Igarashi: Have you measured the prediction accuracy, compared with actual measurements? 14:49:10 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 14:49:34 ... Accuracy is good enough for streaming scenarios, also cloud gaming which is time sensitive 14:50:16 ack ali 14:50:28 Ali: Why would a service provider allow someone to know about network performance, what's their incentive to share the data? 14:50:55 Jonas: They're not communicating with us, you can know the network quality regardless 14:51:46 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? 14:52:00 atai1 has joined #me 14:52:01 ... The service providers may cheat on this kind of data 14:52:23 Jonas: It doesn't work if you cheat, as users would get a poor experience 14:53:11 ... You can't download information about the operator's network, only the predictions. You can get historical data already 14:54:24 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 14:55:40 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 14:56:07 Ali: How to deal with encrypted traffic? 14:56:47 Jonas: Doesn't need information about the data, we just predict based on the connection itself 14:56:51 q? 14:57:19 Ali: Are any tools available for research purposes? 14:58:20 Jonas: The trace replay tools are one way of developing and debugging behaviours, and tools for collecting traces 14:58:51 Kaz: This mechanism is applicable to media distribution, also IoT clients not just browsers? 14:58:59 Jonas: Yes, that's the intention 14:59:35 Kaz: How to manage the identifiers for users, identifiers? e.g., W3C has decentralized identifiers 15:00:20 ack k 15:02:45 kaz: btw, are the slides available publicly 15:02:58 cpn: yes, will distribute the link 15:03:04 s/publicly/publicly?/ 15:03:13 Topic: Next steps 15:03:14 ... next MEIG call will be on Oct-6 15:03:50 scribenick: cpn 15:04:01 ... We can follow up this topic on our mailing lists 15:04:02 atai1 has left #me 15:04:10 [adjourned] 15:04:15 i/btw/scribenick: kaz/ 15:04:20 rrsagent, draft minutes v2 15:04:20 I have made the request to generate https://www.w3.org/2020/09/01-me-minutes.html cpn 15:04:32 rrsagent, make log public 15:14:03 i/Agenda/https://www.w3.org/2011/webtv/wiki/images/7/79/Intel_LPP_update_W3C-Sept1.pdf/ 15:14:26 rrsagent, draft minutes v2 15:14:26 I have made the request to generate https://www.w3.org/2020/09/01-me-minutes.html cpn 15:28:49 rrsagent, stop