12:44:21 <RRSAgent> RRSAgent has joined #web-networks
12:44:21 <RRSAgent> logging to https://www.w3.org/2020/08/11-web-networks-irc
12:44:42 <dom> Meeting: Web & Networks Interest Group: eCDN Streaming
12:44:49 <dom> RRSAgent, make log public
12:54:13 <sudeep> sudeep has joined #web-networks
12:57:08 <cpn> cpn has joined #web-networks
12:59:34 <dom> Chair: Sudeep, Song_Xu
12:59:57 <dom> Present+ Dom_HM, Sudeep, Chris_Needham, Eric_Siow, Huaqi, Song, gs
12:59:57 <dom> Chair+ Dan_Druta
13:00:03 <dom> Present+ Shachar_Zohar
13:00:09 <dom> Present+ Dan_Druta
13:00:58 <dom> Present+ Peipei_Guo
13:01:12 <dom> Present+ Yajun_Chen
13:02:39 <dom> -> https://lists.w3.org/Archives/Public/public-networks-ig/2020Aug/att-0000/W3C-Web_Networks-eCDN-Peer5.pdf Slides: Web & Networks - eCDN
13:03:20 <dom> Sudeep: Welcome to the 11th Web & Networks IG teleconference
13:04:10 <dom> ... Shachar Zohar is with us today, from Peer5, as a guest speaker, co-founder and CTO of the company, working on reliable and scalable content delivery
13:04:37 <dom> ... P2P is one of the topics of interest for our IG, and we had a couple of presentation on similar subjects
13:05:00 <dom> ... Shachar will talk about some of the basics of enterprise CDNs and how P2P can be an answer to some of the challenges in that space
13:05:25 <Peipei_Guo> Peipei_Guo has joined #web-networks
13:05:36 <dom> Shachar: thanks for the introduction - I'm Shachar, CTO and co-founder of Peer5 which we founded some years ago
13:05:49 <dom> ... to leverage WebRTC to provide solutions in verticals around video streaming
13:06:11 <dom> ... WRT this talk, we've looking at solving problems with congestion of live event in enterprise network
13:06:14 <dom> ... [slide 2]
13:06:34 <dom> ... real-time protocols are usually used for video conferences, with very low latency (typically <1s)
13:07:04 <dom> ... this contrats with HTTP video stream (like HLS, DASH) used in other environments have higher latencies
13:07:12 <Larry_Zhao> Larry_Zhao has joined #web-networks
13:07:13 <zkis> present+ Zoltan_Kis
13:07:21 <dom> ... this works by splitting videos in segments in different resolutions and exposing these in timestamped manifests
13:07:43 <dom> ... that architecture creates latencies, but it comes with pros - no jitter thanks to buffer, no packet drops
13:07:57 <dom> ... more efficient video encoding given that there is no latency constraint
13:08:02 <dom> ... that means also better video quality at a given bitrate
13:08:14 <dom> ... it's simpler: stateless servers with cache that can be scaled easily
13:08:41 <dom> ... it's standards, interoperable and can be played on any device, can rely on industry standard toolchains and libraries
13:08:58 <dom> ... it can have network congestion baked into it - which we don't see happening for now in real-time protocols
13:09:17 <dom> ... in this talk, I'm focusing on video streaming using HLS and Dash, not videoconferencign
13:09:20 <dom> ... [slide 3]
13:09:43 <dom> ... the problem statement is when a live event within a corporate environment creates congestion in a corporate network
13:10:06 <dom> ... This is because HTTP streaming requires all the users to download their own version of the video segment given the unicast nature of HTTP
13:10:19 <dom> ... the congestion happens because of the load of the # of users watching the stream multipled by the bitrate
13:10:40 <dom> ... when it reaches the capacity of each of the network offices, it creates congestion
13:10:43 <dom> ... [slide 4]
13:10:56 <dom> ... the solution for this problem is eCDN - enterprise content delivery network
13:11:13 <dom> ... not to be confused with a CDN (from which the term is inspired) - the technology & the problems are quite different
13:11:20 <dom> ... there are 3 technologies to help solve this:
13:11:47 <dom> ... * caching - the caching proxy server will cache the segments from which users of each office location will fetch their segments
13:12:01 <dom> ... only the cache server will hit the cloud-based central server
13:12:10 <dom> ... so most of the connections avoid hitting the internet link
13:12:34 <dom> ... the problem is that it requires installing, running and maintaining such a server, which is also difficult to dimension
13:12:54 <dom> ... Another solution is to use multi-cast - each site would need to be configured to do multicast routing
13:13:02 <dom> ... That too requires lot of maintenance and configuration
13:13:19 <dom> ... Each stream needs to be set up in advance, be routed in advance for live
13:13:30 <dom> ... For large on-demand content, it becomes pretty much unfeasible
13:13:36 <dom> ... The last solution is to use a P2P architecture
13:13:43 <dom> ... in which all the users are connected between each other
13:13:59 <dom> ... and instead of hitting the cloud server, users get their segments from others in the office
13:14:11 <dom> ... it is sometimes considered less secure when a client is involved
13:14:16 <dom> ... [slide 5]
13:14:31 <dom> ... in terms of P2P technologies, there are 2 main approaches, with and without an agent
13:15:10 <dom> ... Agent based P2P technologies require installation (often a barrier in a corporate network) and it raises security questions given the reliance on a widespread single software
13:15:24 <dom> ... The agent less solution leverages WebRTC in order to create the P2P connectivity
13:15:35 <dom> ... it doesn't require any installation - it's just JS in the video page
13:15:42 <dom> ... it means significant less risks
13:15:57 <dom> ... But it means it is limited to browser APIs which makes it harder to develop
13:16:13 <dom> ... [slide 6] shows the architecture of the Peer5 P2P agentless architecture
13:16:18 <dom> ... in blue, the streaming platform
13:16:27 <dom> ... in orange, the cloud infractracture
13:16:40 <dom> ... at the bottom, the corporate network with 2 sites (possibly geographically distant)
13:17:04 <dom> ... these sites can get data from the blue part, or from other users in the side
13:17:35 <dom> ... the zoomed-in of a computer in the bottom part shows more details on how each client retrieves data in this architecture
13:17:49 <dom> ... the peer5 backend helps with discovery of other users and bootstraps the P2P connections
13:18:15 <dom> ... [slide 8] WebRTC P2P Challenges
13:18:37 <dom> ... the first issue is with segmenting offices - we don't want P2P connection among users that are not in the same office
13:18:50 <dom> ... since that would still require using the internet link (which we want to avoid congesting)
13:19:20 <dom> ... The problem has been solved acamedically using traceroutes and see which one converge
13:19:35 <dom> ... but traceroute is not exposed in the browser - that might be worth bringing in for standardization
13:19:49 <dom> ... the problems with traceroute: there are several ICMP attacks that can be leveraged
13:20:11 <dom> ... and more concerning would be the fingerprinting/privacy aspects as traceroute exposes lots of unique data
13:20:18 <dom> ... which is something we want to avoid
13:20:46 <dom> ... The mitigation would be not to enable that API by default, but only enable it when the user chooses it, or when the corporate IT department decides to expose it by policy
13:21:27 <dom> ... for users that are not aware, this would be disabled by default
13:21:33 <dom> ... [slide 9]
13:21:34 <Yajun_chen> Yajun_chen has joined #web-networks
13:21:44 <dom> ... Another challenge is P2P over virtual path
13:22:04 <dom> ... detecting clients that are tunneled VPN is critical to avoid congesting the internet link
13:22:21 <dom> ... that information is available on the device
13:22:41 <dom> ... but the problem of exposing it in the browser is similar (fingerprinting), with similar mitigations
13:22:49 <dom> ... Thanks you, and happy to get questions
13:23:10 <dom> Present+ Jon_Devlin
13:24:20 <dom> Dom: re traceroute, do you know the full traceroute output, or could you use a smaller surface of data?
13:24:53 <dom> Shachar: exposing the IP, hostnames, latency and number of hops would be required
13:26:20 <dom> Dom: how would you scope this to make palatable to IT policies?
13:27:00 <dom> Shachar: limiting it from only a single origin and to a limited target
13:27:38 <dom> Dom: have you looked into building a browser extension that would demonstrate this?
13:28:02 <zkis> q+
13:28:07 <dom> Shachar: not as a browser extension, but we have an electron PoC
13:28:41 <dom> Sudeep: re traceroute, is this about multi-sites distribution, or is this about picking the right peer in the P2P architecture?
13:28:54 <dom> Shachar: these perspectives are intertwined
13:29:04 <dom> ... we need P2P to avoid congestion over the expensive internet links
13:29:22 <dom> ... but doing P2P without taking into consideration the LAN topology, we might still overload the congested links
13:29:39 <dom> ... we need traceroute to determine which peers are in the same cluster / LAN
13:30:48 <dom> Sudeep: is there any sort of JS agent which can run in each of these peers accessing the video stream and would multicast the information with regard to their availability on the local network?
13:31:00 <dom> Shachar: something similar to what you suggested is mDNS (multicast DNS)
13:31:33 <dom> ... the multicast TTL is set to 1, which means only users in the same network segment (one hop away from the multicasting user) will receive it
13:31:48 <dom> ... but if you have multiple segments in a single office, you want them to discover each other
13:32:03 <dom> ... in any case, I don't think there is a multicast discovery mechanism within JS
13:32:21 <dom> Sudeep: we have a similar conversation in the context of discovery edge servers in the context of offloading compute
13:32:34 <dom> ... I wonder if the discovery aspect could help address this in a different way
13:32:53 <dom> Shachar: You're right that this has likely applicability here
13:33:56 <dom> Zoltan: re caching vs multicasting vs P2P ("eCDN technologies" slide)
13:34:11 <dom> ... you mentioned that having an application was an issue due to security and management perspectives
13:34:31 <dom> ... whereas in the browser, you're limited by what browsers are willing as powerful APIs
13:35:15 <dom> Shachar: from a business perspective, installing software within large customers with slow processes from security is extremely challenging
13:35:44 <dom> ... more generally, the trend is to go to the cloud, with very little appetite for installing proprietary software
13:35:58 <dom> ... so using the browser is a much more practical approach
13:36:19 <dom> ... we've been able to manage some of these challenges within the current constraints
13:36:38 <dom> Zoltan: I agree that a browser front-end is preferable for cloud-based services
13:36:51 <dom> ... I'm asking because other powerful APIs have been facing these questions
13:37:11 <dom> ... these are challenging questions in W3C
13:37:17 <dom> ... but you seem to confirm it's worth it
13:37:22 <dom> Shachar: yes, I think it's a MUST
13:37:36 <dom> Zoltan: do you have any specific proposal in terms of what API to standardize?
13:37:50 <dom> Shachar: not at this point - this is something that could be started within this IG
13:38:03 <dom> ... not sure if WebRTC would be a natural fit for ICMP/traceroute
13:41:30 <dom> Dom: re VPN, this used to be exposed in WebRTC but was removed due to safety concerns
13:41:57 <dom> ... how much of the topology can be determined from existing info (e.g. RTT, or IP name schemes)
13:42:17 <dom> Shachar: we're already some of this with pretty good level of success
13:44:16 <dom> ... in some cases, our customers provide us with a mapping of IP address but that is brittle
13:46:00 <dom> Dom: it's interesting that you can already do most of it - that may be the basis of building the case that exposing just a bit more would not create very different privacy/security surfaces
13:46:11 <dom> ... can't you get the info you need via STUN?
13:46:42 <dom> Shachar: different corporate networks may not make this practical (e.g. exposing random IP addresses, or same IP address across different offices)
13:47:47 <dom> Song: there are challenges with regard to privacy - can you explain more specifically the benefits to the enterprise customer? is it lower latency? saving costs?
13:48:13 <dom> Shachar: it's not so much about saving costs - today, corporate offices have a limited amount of bandwidth
13:48:49 <dom> ... e.g. an office may a 1Gb/s to the internet; a stream might be 2M/s - if you have a 1000 users watching that stream (e.g. the CEO talking about their networks)
13:49:01 <dom> ... this creates a 2G/s requirement, which will suffocate the internet link
13:49:22 <dom> ... this means some users won't be able to watch the stream, and other applications will also be blocked or slowed down
13:49:32 <dom> ... this is what the eCDN technologies are scoped to solve
13:50:15 <dom> Song: we are planning the Web conference for my company China mobile, with 100K people across the country
13:50:41 <dom> ... right now, some people will group in meeting rooms, others will watch from home or on their mobile phone
13:51:03 <dom> ... Would eCDN still cover this scenario, with users in these different setups?
13:52:09 <dom> ... if this would work, this would be good motivation to consider the privacy/policy mitigations
13:52:33 <dom> Shachar: P2P can be used in a hybrid environments with some people at office and others at home
13:52:47 <dom> ... e.g. by improving the situation for people on the same ISP
13:53:12 <dom> Song: as a 5G operator, we are also planning a 5G-based broadcasting or multicasting on the top of the 5G radio network
13:53:30 <dom> ... if this might be interesting in this context, let me know
13:54:55 <dom> Dom: re enterprise policy for browsers - what exists today? any convergence across browsers?
13:55:11 <dom> Shachar: Harald shared with me that there doesn't seem to be any effort on this at this time
13:55:23 <dom> ... lots of possible interesting topics for W3C here
13:56:46 <dom> ... Chrome, Edge and Firefox have their enterprise mode with centralized configuration, but they're not standards
13:56:53 <dom> ... they're not using the same registry keys
13:59:57 <dom> Dom: so I'm hearing several possible standardization topics:
14:00:05 <dom> ... * exposing traceroute/ICMP or network topology one way or another
14:00:57 <dom> ... * standardizing enterprise policies or at least a shared way to enable super-privileged APIs in specific environments
14:01:03 <dom> ... * expose NIC interfaces
14:01:26 <dom> Sudeep: thank you for the presentation!
14:02:13 <dom> ... we'll look at these ideas, also try and find a commonality with some of our other discussions
14:06:45 <dom> RRSAgent, draft minutes v2
14:06:45 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/11-web-networks-minutes.html dom
14:10:35 <dom> dom has joined #web-networks
15:28:12 <Zakim> Zakim has left #web-networks