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