IRC log of web-networks on 2019-09-16

Timestamps are in UTC.

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