Meeting minutes
Slideset: songslides
Intro
Sudeep: welcome to our 20th web & networks IG
… hope everyone is safe
… this meeting is meant to capture the TPAC summary
… we would like to invite you to share your thoughts on how TPAC went, capture some of the input and actions
[slide 2]
… we will cover 3 main topics: games in the games CG
… edge computing - some work done by Max in this space
… Piers will share his thoughts about network conditions & monitoring
… Song will cover the key essence of these topics
[slide 3]
TPAC debrief
Coordination with Games CG
Song: Jeff reported the interest from the games CG on exploiting low-latency from e.g 5G network
… the CG hasn't been too aware of our work
… we're reaching out to them to get their use cases and requirements
… ideally, we would like to get real data from game vendors
… China Mobile is running a game company, my colleague Huaqi is working on use cases analysis on that
Sudeep: are there any other member here with interest on topics related to Web gaming?
… the games CG is looking at trends from a Web development perspective
… we're trying to bring the networking angle
… and its impact on the quality of experience
… anyone with an interest in sharing perspectives in this space?
… if you find relevant people, please let us know
Edge Computing
[slide 4]
Song: another feedback we got from TPAC was to make sure the Web platform is not left behind as new network capabilities emerge from edge computing
… we already have use cases and requirements, but no active incubation in this space
… we need to strengthen the incubation in this space; Max is leading the way
… we also need to explore potential breakthrough in this space
… Max and Michael will brainstorm the next steps
Client-Edge-Cloud coordination Use Cases and Requirements
Network conditions and monitoring
Song: we need to hear from the latest evolution of the network info API
… Piers will give a talk on network info from edge servers
… while keeping in mind the risks around privacy and fingerprinting
[slide 5]
Multicast
Jake: re TPAC - thanks for the mention of the Multicast work!
… there was a mention of supporting the CG as the right place to work on multicast
… is there any ongoing liaising that I should be doing from the multicast CG side?
Sudeep: did you get any new member through TPAC for the CG?
Jake: a bunch of new people came to the TPAC meeting; don't think they've joined the group after that
… our next meeting is tomorrow
… various follow ups have happened at IETF
Sudeep: I guess this topic still needs further socializing within the web dev community, like edge computing
… is there any specific short term action we can take? I suppose you've already done outreach
Jake: at IETF, the feedback focused on lack of browser interest
… there are also security concerns that were raised
… the right browser folks may not be engaged at IETF
… so my ask might be to establish the connections with these folks
Song: in terms of multicast scenarios, there may be an overlap with edge computing
Jake: several ISPs have expressed interest in multicast - more wouldn't hurt; but the key is getting at this stage is getting browsers interest
Sudeep: the privacy concerns - do they go away from multicast is used in settop boxes?
Jake: the privacy concerns are actually at the network level; keeping the issue out of the browser doesn't help solving them
dom: we should be careful in distinguish issues around security & privacy, they hurt in different ways
Network Information & Edge Computing
Slideset: https://
Piers: what are the metrics, where do they come from?
Piers: the state/timing information gives a view on the network state from the receiver or sender perspective
… at the kernel level, TCP_INFO gives a bunch of congestion info
… as part of the BBR, there is a new delivery rate estimation as part of the kernel
… a sister draft to the BBR draft, from IRTF
… from the app level, QUIC as a transport info api with similar info to tcp_info
… likewise, you get info from WebRTC
Piers: in the BBC, we're interested in streaming media, so trying to find metrics to help with media quality
Piers: in terms of server metrics, we would be interested in sharing information available only on the server
… e.g. sender cwnd
… it could also provide information not directly available to the client, e.g. the rtt
… the congestion window is available through APIs e.g. in nginx, appache traffic server, via an http header or inline with the data
Piers: the cache-status-header has per-cache metrics
… one of my draft to IETF proposes a Transport-Info header
… The W3C server timing API provides some information to the client
… CTA-WAVE has ongoing work via the Common Media Server Data, with media-specific delivery info
Piers: we did some test - a server that includes transport info via a proxy, profiled for consumption by a dash player
Piers: the error of the bandwidth estimation is much lower when using transport info
Piers: among the issues with that approach is ensuring the client is directly connected to the server
… with HTTP2/3 flows can be coalesced
Piers: discussion at TPAC around rebooting the network info API with a smaller scope, but still not very popular outside of chromium
… and giving very rough info in any case
… Resource Timing API is not very useful for streamed media
Piers: in terms of potential API improvement - streams API would benefit from a data buffer arrival timestamp
… Could e.g. resource timing be extended to cover media delivery?
Jake: did you measure the impact on the quality of experience?
Piers: we did, but that's more involved
… it depends on which algorithm you use
… on VOD, the benefit isn't as strong
… in low latency areas, it depends on which algorithm you use - you get benefits, but not always as clear you would expect, but likely due to to the algorithms themselves
Jake: is there a common place to follow these discussions?
Piers: CMSD in CTA-WAVE; the analysis will be published soon, but hasn't been published yet
Jake: I'll watch this space
… would be worth bringing to MOPS in IETF
… can you elaborate on the privacy questions that were raised?
Piers: exposing accurate information about a client connection that may allow to fingerprint that particular device, which may allow to infer where they are
… but we didn't lay them out in details
dom: information could be used to say whether someone is at home / office / in transit
… possibly even at the room level with very detailed info and impact on e.g. wifi connection
Piers: not sure if this exposes any new info though compared to what you can measure with JS, but just more efficiently
… Another issue was around coalesced flows that would allow to infer activity happening separately
Jake: I guess some of the noise of obtaining the info directly from JS might be seen as a good thing from that perspective
Edge computing
Max: I haven't updated the draft use cases draft recently
… ByteDance has expressed interest in contributing
… will try to gather more momentum from other companies
… toward a possible charter
… please get in touch!
Sudeep: sorry we're out of time, we'll also run another dedicated session on the topic
… Our next meeting will likely be in January, with Max & Michael to dive on edge computing