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