W3C Web5G Workshop Day 1

10 May 2018


Eric_Siow, Dominique_Hazael-Massieux, Jeff_Jaffe, Lucas_Pardue, Chris_Needham, Diego_Gonzales, Dan_Warren, Carl_Taylor, Stephane_Tuffin, Ulrich_Dropmann, Didier_Berthoumieux, Paul_Farrow, Vincent_Toubiana, John_Grant, David_Hutton, Dan_Druta, Kobayashi-san, Joe_Butler, Sharon_Ruhane, Goran_Eriksson, @@@Huawei, Louay_Babouss, Andrew_Hutton, Johanna_Gonzales, Alice_Foster, Christoph_Ziegler, Louay_Bassbouss
dom, cpn, jeff


<MrQ> is the Bluejeans video streaming going to be ON?

<inserted> ScribeNick: dom

Eric: this is a first date - a chance to share what we're doing across the 5G and Web communities to get a better understanding of possible opportunities to work together
... at the end of the workshop, we need to get a clearer picture of next steps
... we don't want to create confusion between e.g. W3C and 3GPP
... the world is getting more and more complicated, with standards emerging from various sources
... we need to create complementary not competing standards
... standards only matter if they get adopted
... we want to provide clarity for the ecosystem to grow and the market to expand

[reviewing agenda of Day 1]

Jeff's Keynote

Jeff's keynote slides

Jeff: [on integration layer integration]

John_Grant: we need to keep layering, but include the signaling across the stack

<shuhei> driverless people:)

jeff: there are great opportunities, new appliciation ideas, great new network
... too few people care about the middleware, it's really up to us as a community to make it all work

Eric: there is a new exciting area called progressive web apps
... it would be interesting to explain the possible applications

Jeff: progressive web apps solve the problem of having to wait so much with loading appliications
... PWA get you started right away, and add stuff as you go along

<cpn> scribenick: cpn

dom: PWA brings more control, for offline use, gives better OS level integration, home screen
... we bring what you normally expect from native apps to the web
... PWA are the main current evolution of the web platform today

Eric: usage example: car hire when on vacation, parking payments

dom: i describe this as the ambient web, adaptation to your local context

Didier: are there features in 5G that help with WebRTC? I don't see a big improvement from 4G to 5G for WebRTC

<shuhei> I will bet > PWA in the "mobile" point of view

Jeff: these are open topics, bandwidth hungry applications

Andrew: performance, and apps need to know the characteristics of the network. capability negotiation

Jeff: bandwidth and latency constraints, understanding the network you're running on. can we figure out the set of characteristics that need to be surfaced?

Dan: a lot of the API work started before 4G. it has to be implemented in the client. we don't want to create vertical walled gardens
... as a developer, i don't want to be network-dependent, i want to be network aware. optimisation is important. need to have incentives for the ecosystem to work. not just a technical challenge

Goran: the web vs application specific protocols. technologies are developed in a context
... guidelines for what we do on the public web: don't do cross layering
... moving web technologies into private networks, i can use other solutions

Jeff: each time we've had a new underlying network, we don't throw the layering out
... we moved from terrestrial to satellite networks, figured out how to incorporate within
... i'm talking about the implications of lower level changes to the higher levels

Goran: you may want an API for network control

Jeff: the approach didn't scale. you can try things on a proprietary stack, but people end up on the web stack due to interop

Dan: the proliferation of open source and the intersection with OSS and web technology makes it easier to use

Eric: was talking to a consulting firm for US government, due to the sensitive nature of their work, they designed custom solutions. but they found it more efficient to participate in open source

Panel discussion

Eric: [introduces panelists]

<jeff> scribenick: jeff

Panelists: Dom, Goran, Dan, Stephan, Didier, Eric

ES: Lot of hype on 5G... excitement
... but people say what is it?
... still evolving
... wdyt; what is 5g?
... compelling value prop

ST: 5G is evolving
... some stable aspects

<scribe> ... new spectrum

UNKNOWN_SPEAKER: virtualization
... cloudification of network
... that part is stable
... evolving on how it will be used
... economic impact
... (speaking for myself)
... Mark @@@, French economist
... talks about evolutionary and revolutionary
... evolutionary is BAU
... won't change economy in Europe
... revolutionary picture
... not economy of offer
... is economy of demand
... enterprises ask for specific connectivity

DB: 5G driven by spectrum
... UHF, millimeter wave
... lots of physical technology
... common for fixed and mobile
... common core network; agnostic
... 3GPP will define APIs for apps; not in OMA
... application ecosystem needs network slicing
... VPN extended to mobile access
... clearly a revolution
... brings new applications and customers to operators
... not a huge technical change
... linked to core network being virtualized
... easier to program
... not in standard, but assumed by all
... requires orchestration

ES: Interesting that 3GPP is defining APIs
... could be area of exploration with web community and 5G community

DW: We are in danger of doing tomorrow's presentation
... nobody here has marketing in their title
... 5G interest generated by marketing
... more so than 2G, 3G, and 4G
... driven technical topics (e.g. slicing)
... issues of scaling, geographic coverage
... makes 5G network complex
... plus new radio stuff
... more spectrum
... build it and they will come
... 5G is a confluence of events
... virtualization of networks happening everywhere
... fixed nets, mobile nets
... 5G core architecture enables slicing
... coincidence of time
... massive MIMO and millimeter wave access changes core network architecture and enablement of services

GE: Three things
... 1. New industries. Not just telco. Not just telephony. Not just public net.
... 2. Continued embrace of web
... 1993 said replace X.25
... customer in Japan said we needed it for packets
... someone else said "internet"
... still using core protocols
... some done in 6 months
... now we embrace microservices, virtualization, QUIC, HTTP2
... tensor flow, machine learning
... bottom up AI hype and implementation everywhere
... 3. Attempt to make a more flexible toolbox.
... I've worked on both web and telco
... even IMS but don't quote me :)

ES: So you have pressing issues

GE: Pressing issue is with all of this flexibility, how do you keep it all together?
... automation? search? Management?

ST: Pressing issues?
... identification of features that will benefit vertical services
... niche services have low ROI
... hard at the moment
... today driven by physical layer
... need to get reqts from vertical industries
... through intermediate layers as well
... Jeff talked about latency
... 5G has some features, but they will be invisible if the transport layer does not progress
... latency coming from queueing and congestion
... not the radio interface
... but need features from verticals
... integration points
... many initiatives

DW: Fundamental and big problem
... Telcos get the entire industry in the room
... GSM and 2/3/4/5 G
... but some of these industries are bigger than us
... nascent industries
... we tried GPRS, WAP; didn't really work
... we build pipes and others put services through pipes
... outside of expectations of mobile operators
... tried to grab web, but failed
... little interaction in web stack
... same problem with IoT
... but no organization (except for auto)
... and everyone wants something different.
... Big autos want their own ecosystem

GE: In 2011 we started working on WebRTC
... we could join that development
... cannot do that today
... Apps have so much money

ES: Interesting that you raise that issue
... Looking at IoT and W3C's WoT
... same conclusion
... all these verticals; industrial (e.g. Siemens)
... connected homes; connected building
... need deeper dive
... different markets
... factory (homogeneous), home (heterogeneous)
... what verticals will be early adopters
... are there 2-3 with similar use cases and reqts?
... focus on that; solve the problems; compelling solution
... then come the late adopters

DW: Biggest challenge is telco industry velocity
... auto is a great example because it has a similar velocity
... 5 year lead time on design
... has wheels
... small number of vendors
... no operator
... organized
... But Industrie 4.0 has many people looking at the same thing
... but doing different things
... An auto manufacturer in UK built their own network based on latency
... if we don't build it; some industries will do their own proprietary
... if we don't get it right, other communities will build on the infrastructure

DB: The vertical models are to be built
... but it will take time
... we will design 5G network
... fast internet access
... extension to new markets will take time
... 3G was design for circuit switched video
... so we are used to making mistakes
... but we need to be flexible
... slices of demand
... then adapt to IoT market

GE: We have also learned
... need to be flexible
... need to be simple
... basic item ... connectivity ... will always be wanted
... then comes value-add
... but cannot focus on that too early
... work in cloud-native way will be good
... trust issue
... are we fast enough?
... but basic design we have right
... but will it be simple enough?

ES: Jeff talked about some web things
... advanced technologies
... what is the interplay or synergy between web and 5G

DW: That is what we are here to discuss
... discontinuity suggests opportunity
... velocity comes in to that
... operators need to change velocity within their own network
... people need to evolve or be fired
... move to dev ops
... a network that evolves once a year based on 3GPP networks won't be quick enough
... apps work on 2 week cycles

DHM: A question
... 5G won't happen overnight
... 2/3/4/5 G will coexist
... if an app requires 5G
... how do I manage if my car goes into a 2G cell?
... is this being explored?

GE: You have that today GPRS, 3G, 4G
... 5G will include 4G radio
... don't you have that today?

DHM: If apps require 5G features need fallback

ST: 5G application is looking at it
... a car needs information from its environment
... latency aware
... can the network tell the apps?
... this could answer your question
... "latency failure notifications"

DW: That is not great if the service is critical
... "your car will stall because latency not good"

ST: Still, application needs to know

GE: In some device context it could be highly sensitive
... in others cross-layer API not good
... so we need to be clear

DW: 5G is not a single use case
... broad and diverse
... the term 5G confuses everyone
... need to talk about specific industries and use cases
... careful what you read
... a solution with 5 9's of reliability and 100% coverage won't happen for years
... what we are selling different from what we are delivering
... at least for many years

ES: Open to floor

David Hudson, GSMA: Goal of panel

scribe: what is 5G and what is driving deployment
... is it only enhanced mobile deployment
... is it novel service
... 3G was circuit switch video
... 4G was FB
... will 5G just be network slicing?

DW: I've been asking that question!

DB: Different answers in different parts of the world
... more than massive access

<scribe> ... new market of fixed wireless access

UNKNOWN_SPEAKER: convergence of fixed and mobile
... (less so in Europe)

<scribe> ... new verticals; IoT

UNKNOWN_SPEAKER: opportunities, but unclear business models
... will network control car with low latency
... or will car be a user of the network?
... automation, Industrie 4.0
... slicing, private networks
... licensed/not licensed unclear

ST: Yes, depends on country
... enhanced mobile broadband in some countries
... fixed wireless access in europe
... B2B in other countries
... so three cases for Orange in different countries
... bundling, multi-play offer

Dan Druta, AT&T: Many things happening under the hood

scribe: cloud-first
... virtualization direction
... decomposition of functions
... (aside from bells and whistles)
... taking advantage of revolutionary aspects for slicing
... car should be network aware not network dependent

DW: Autonomous means not dependent

Carl from Hutchinson: We've talked about use cases from verticals

scribe: 5G services cannot be delivered by one size fits all internet stack
... so we build something niche
... then Jeff's wisdom is that special stuff doesn't scale
... long-term you end up in standards
... throw away early investments
... operators focused on niches
... barrier is how do we build middleware to deliver low latency
... will web community support?
... or will it be local standards
... perspective?

ES: Can focus on niche within an open standard
... early adopters; early majority; late majority
... all operate differently
... need early deployment, proof of concept
... tolerate bugs
... $25K for first flash screen TV has different tolerance
... from someone who bought $1500 standard item
... Jeff did not use word niche
... he talked about native
... eventually moves to web

DHM: You raise excellent and difficult point for webside
... W3C focuses on scale
... eliminates things that are too niche
... but people want to experiment with new approaches
... I'm working on how to make web more evolvable
... some CG focus
... browser vendors have some tools
... need more
... what does it mean to do web in private networks?
... have more control
... no net neutrality issues
... can we build features that first work in private nets
... (e.g. some WebRTC features)

Carl: Do you see a period of exploration of new types of web stacks
... eventually controlled together
... Dan Druta pointed out that it will not be sustainable to have a stack per app
... but need to enable

ST: Ecosystem issue; not technical issue
... WebRTC needs a feature in browsers for Orange to deliver a service
... driven by browser companies
... openness of implementation of web architecture

DW: We have some commonality in browser
... small number of dominant OS providers
... pushed down to end user device
... can we unify in 5G architecture

GE: We have some of that already
... we should lower cost of connectivity
... better toolbox
... companies will want to standardize

DW: If you talk to some companies about Industrie 4.0 they want proprietary
... if you address health care, you have many players
... manufacturers, insurers, etc.

GE: But certain vendors want proprietary
... other have other pain points.

DB: 5G encourage vertical markets with proprietary systems
... public safety (US and Europe)
... industrie 4.0 (China)
... 5G can adapt

GE: Standardize toolbox and lower layers
... don't bring complex API
... give a foot in the door

DB: IoT a good example
... help app developers
... SCEF APIs in 4G
... low battery consumption
... adaptation layer for non-IP stuff

GE: Complementary investments
... for higher layers - what will W3C do to make higher layers work for IoT devices?
... web workers, web assembly

DHM: Some of that has already happened
... fitbit using sensor APIs
... so far ad hoc
... System Apps WG looked at it
... non-browsers to use JS APIs
... if we get support for IoT on JS APIs, we can host the effort

GE: Need the vendors

ES: Thanks panelists
... break
... return at 11:30

ETSI work on Next Generation Protocols for 5G, by John Grant

<dom> ScribeNick: dom

John: wearing hat of chair of ISG NGP formed in 2016
... you're not going to notice the latency of new radio unless you address latency in the core
... also needs to reduce number of bits (e.g. TCP headers)
... this needs to fix problems with IP-based LTE core
... we don't think IP is able to support some of the proposed services
... while Internet is built on IP, we could use other protocols inside the networks
... the ISG has defined the scenarios it will be working on, existing technologies, requirements
... part of the discussions has been the relationship with IETF (where relying on IP is non negotiable)
... our work in GR8 to 10 can work both over IP or over something new
... GR12 looks at the operators requirements
... IP addresses don't identify the host, they identify the interface
... packet header is another issue (compression helps but it drains battery)
... latency - due to bad interactions with TCP retransmissions and congestion control
... security - with NAT persisting to protect hosts
... IP is anchored in some of the computing constraints of the 70's (e.g. limited memory)

Lars: [how does this 80's approach scale?]

John: it scaled for the needs of that time

ColinPerkins: in a connection-oriented network, you don't discover the routes on 1st connection - the routing tables are pre-populated

john: but in IP, routing tables get fragmented

Lars: the control plane synchronously with the data plane

John: so you never get an IP packet that is not in the routing table?

Lars: even if you do, there is a default route for it

Stéphane: [this] is specific to a particular implementation

John: clearly we need more participation - this hadn't been identified there

Lars: this was brought up as a flaw when this was presented in IETF

John: in any case, one of the benefits is support for multiple addressing schemes
... e.g. to access locally cached content

Urlich: one of the premises of your roadmap that release 15 doesn't define architecture
... but that's not the case
... the next phase of the standardization process cannot accommodate such a change - the core 5G network has been set already
... some of the problems you identify have already been addressed

John: clearly we need more liaisons with 3GPP on this - we hope to rely on some of the changes brought by the 5G architecture
... some of the additional support we hope to get from this new protocol is capability for QoS negotiation, and improved security

Lars: is it that you only expect 65K flows? that seems rather low

John: you can aggregate flows like in the push operation in MPLS

Lars: if you stack things up, you're going to get back into the cost of IP

John: we don't think we would need more than 2 levels of stacking - ATM didn't
... regarding latency, it's important to realize that media networks have different requirements than IT usually understands
... IT mostly cares about sequencing, where media needs things to happen at a precise time
... the Quality of Experience for media is continuous
... best effort approach is not great for live media
... NGP proposes to have a separate service for AV traffic (separate from IP traffic)

Lars: are you talking about nano-seconds delay here?

John: delays between 1 to 12 ms

Lars: but you don't need this for that kind of delays

John: you do on 1Gbps links
... which was what we experimented on

Lucas: in IP studio with multiple feeds, we're looking at 14/15Gbps for multiple 4K video feeds

John: the project we had been looking at was for radio, so a different scale
... but our approach scales
... Looking at control plane signalling (coming from Radio4 project) based on an IEC standard
... it also enables new security features

Lars: everybody is excited by QUIC because it gives 0RTT to applications
... this adds a new handshake: this looks backward

Zahed: you even get DNS prefetching to reduce latency upon clicking a link

John: we're at the very early stages - IP + many refinements may be equivalent to this, but we expect to have more growth for improvements

Lars: I disagree - by dropping IP headers, you may be more efficient in the packet, but that requires an additional handshake

Zahed: the complexity needs to live in one of the layers no matter what

John: we're still getting other advantages

Dan: in the end, we want to have our customers watch their cat video, which requires IP
... what's the cost in the intermediary translation? what are we gaining from it?
... where is the adaptation between this and the existing IP network?
... the same way HTTP over QUIC hides the change from an HTTP perspective

John: you can keep using IP addresses with NGP
... if your application is able to ask for some of the new features, then that app will benefit from it

Lars: everything uses IP today
... your protocol needs to interface with it and still provides benefits with the translation overhead

Dan: you can't expect a switch over night - you need compatibility with IP

Stephane: this could happen in a specific slice, for a specific application (e.g. video streaming)
... it's not meant to replace IP in the general sense

Colin: we have also non-TCP protocol in IP - yet everyone is using TCP even for AV; deployability wins over quality

Dan: even AV is a very broad concept: interactive video vs broadcast
... is AR/VR considered AV?
... is maps IT? but it is still very latency sensitive?

John: AR/VR would definitely be considered AV in this context

Dan: but it's just data

Colin: and it's synchronous

---- Lunch Break, back at 1:30pm UK ----

The Browser as An App Platform, by Dominique Hazael-Massiexu

<jeff> Dom: Looking at current trends in web platform

<jeff> ... introduce for people not familiar

<jeff> ... shed light for people on path for the web

<jeff> ... personal pov; not W3C's

<jeff> ... about the future, but I don't have a crystal ball

<jeff> ... provide an angle on how this intercepts the network layer

<jeff> ... Here are some fundamentals:

<cpn> scribenick: cpn

Dom: The browser is a user agent, there to represent the will of the user
... this means that it leaves a lot of control for the user
... writing web apps, Javascript execution can be changed / modified by the user
... user control over fonts, cookies, enabled features
... this implies a strong stance on security and privacy
... only data shared is that agreed with users
... the corollary of that is, by default the application is not trusted
... push towards encryption on the web; the network could host an adversary
... the browser is built with and around the network
... hypertext existed before the web, hypercard in the 80's
... the internet existed well before the web
... the web connected these two paradigms
... the start of web 2.0, web applications, was the arrival of AJAX
... it allowed loading data without reloading the page
... the migration of media to the web was brought about by HTML5 video, adaptive streaming using Media Source Extensions
... WebRTC is another big evolution of the web, deeply linked to the network layer
... Progress Web Apps, a collection of technologies that give a nice integration with the underlying OS
... enables offline web apps, also with bad or inconsistent internet connections
... looking at the web as an app platform, it's the only one built around the network
... the notion of origin is critical to security
... the only platform with this characteristic - data bound to where it came from
... it's an adaptive platform. it started during the desktop PC era
... now mobile, automotive, VR headseats, as ways of interacting with content
... can author across all these platforms
... progressive enhancement, by default can be accessed by anyone, but can add features
... device independent, multi-modal, immersive web
... next i'll describe some current trends
... the Stream API allows the browser to receive data in streamable form
... media streams, from adaptive streaming such as DASH
... WebRTC is based on real time streams that you can process and record
... early discussion in the WebRTC WG on exposing QUIC based streams
... big trend towards streamable content and parsers in browsers
... WebAssembly is a byte-code for other programming languages
... streamable, allowing running code more performantly
... blurring of distinction between clients and servers
... WebSockets provides bidirectional communication in browsers
... move away from request/response, browsers can act as servers
... projects to allow an HTTP server in the browser
... Second Screen, projecting browser content on to a second screen
... peer connection between browsers
... peer to peer OS for hosting content in the browser
... WebAssembly means you can compile any existing code base to make it compatible with the browser, C or C++ codebases
... Node.js allows JavaScript to run on both client and server
... boundaries between code run in the client and server needs to be managed flexibly by developers
... another trend is micro-services and serverless functions
... small components integrated dynamically
... one frameworks uses Service Worker, an API for managing background processing
... you could choose Service Worker to use in the browser or be dispatched for a serverless function
... network integration is one of the core benefits of the web
... some progress on how the browser integrates with the network (WebSocket, WebRTC)
... Service Worker brings a programmable network proxy to browsers

Jeff: regarding the client as a server
... W3C does client APIs, server APIs less clear. should we be looking at server APIs more at W3C

Dom: If we think browser has a role to play as integration point between server APIs then yes

Eric: Looking at the recent re-org at Microsoft - user experience group and cloud group. The immersive web, they see as not just a client thing, also server.

???: This distinction relates to responsiveness, processing, caching. Will low latency / high bandwith affect these principles?

Dom: it's an open question, want to see us explore
... 5G makes a distinction between what running on the edge or in the cloud less relevant
... it creates new opportunities to defer some things to the network
... 5G changes the device / cloud topology

???: Could be a way to bring client and server closer.

Dan_Druta: For future definitions in the web space, the user agent is what the user has control over, then extends over the web platform
... Pushing logic seamlessly between pieces in the architecture is a valid point. clients can also be servers. cloud centred compontent with databases etc
... this is happening, but not done in standards. helpful to clarify the topology and the roles and responsibilities of these containers

Goran: inexpensive devices we haven't started to cram in VR, more computation. have we reached a point where have to be distributed?

Dom: question is more whether there are benefits to doing so
... filtering of data before being sent to a client
... focus on things that are time critical for the user experience

Goran: augmented reality, conversation based interaction are more network intensive. is there a need for lower latency?

Dan_Druta: Face recognition happens locally for a good reason
... Voice recognition could be done that way
... More battery requirement

Goran: will the need for connectivity increase or decrease?

Dom: If the only thing you can get is more bandwidth, that's what you'll use. you could use the user's environment, edge, cloud
... the browser has a specific role to play, can be used on any device, makes it unique

Richard: you've shown the building blocks for distributed execution
... you write an app in a style that is distributed by default, then some mechanism needs to decide between network / power and a rules engine for deciding what to run where
... what is W3C thinking in terms of supporting that?

Dom: If we think the convergence of browser as app platform trend with the network trends is valuable, we need to think about solving these things
... Another big trend is hardware integration: sensor APIs, Bluetooth, USB, MIDI
... some are controversial due to security and privacy
... lots of interesting ideas, when you think of the browser as a way to interact with devices in your environment
... Web of Things as a way of describing IoT devices
... interacting with the room is just one click away, interesting potential
... Progressive Web Apps, integrated with other apps in the OS
... Cloud integration. we have active work at W3C on payments, Payment Request API
... Payment Handler makes any website able to be a payment instrument, standard integration with third party payment system
... a way to integrate the browser with payment services
... similar approach with identity. WebRTC has a mechanism to certify the identity of a peer
... integration with existing cloud identity providers
... another example is the Share API, for sharing content on social networks
... Service Workers allows syncrhonisation of data with cloud services
... a key component for cloud integration
... moving data between the server/client boundary
... browsers now allows synchronising of data using proprietary services
... allow user to synchronise browser configuration between devices
... another idea is moving the browser itself to the cloud, cloud browser, for media service in the Media & Entertainment Interest Group
... Web Components make it easier to package code into reusable pieces, ECMAScript modules
... interest in "intents" (in Android terms), Share API, Payment Request API
... packaging is a recurring theme on the web, the latest work in W3C and IETF is around signed packages
... retains all the right security properties
... Google AMP, content hosted by Google but with the original website's packaging
... another theme is embedding and reuse of web technologies outside the browser
... not clear how W3C relates to this work, they benefit from it
... JavaScript on devices, we can expect more of this. WebAssembly can bring more targets for existing code
... more modalities coming to the web. speech recognition, computer vision. camera access and high performance code with WebAssembly
... computer vision: object detection and classification in the browser
... another trend is chromeless browsing: full screen mode, immersive context, you may not realise you're on the web
... another early trend is artificial intelligence and machine learning
... browsers use heuristics to determine whether you get access to advanced features
... e.g., the ability to add to the home screen
... also seeing ML primitives coming to web applications, tensorflow.js, GPU computation

???: also Web MPU. we're exploring this at Huawei, trying to accelerate the platform

scribe: The cloud-native browser - authoring web apps without predetermining what runs where
... it relies on the trends i mentioned earlier
... need to understand the role of the user in making this decision
... e.g., mobile data plan -> mobile data and processing plan

Dan_Druta: this is already happening with split browsers?

Dom: generally you don't develop web apps with the split browser in mind
... no longer an asymmetric network, expect devices to act as client and server
... The ambient web - if you walk into a space, the UI comes from the environment itself. example is Physical Web from Google
... privacy and security conserns
... The invisible browser - as the browser becomes more integrated with the OS, becoming chromeless. where are the boundaries?
... a future to investigate

???: About the invisible browser, the rendering and the protocol stack

Dom: you can build a protocol stack in the browser, you ship the protocol stack with the application, QUIC
... interesting questions around security
... The smart browser, fully embracing artificial intelligence, learning from user behaviour
... We are planning a W3C Workshop on exploring the future of the web as an app platform. please get in touch if interested

Jeff: Is there another possible future where the web technology stack is a set of building blocks to enable the other directions you mentioned?
... Many of these things are very complementary, not meant to be mutually exclusive

Andy: You mentioned not trusting the network. Negotiation over QoS. Users have a preference over which connection to use. There will have to be some trust over the negotiation mechanisms.

Dom: Need a system where a subscriber can choose which network to use, based on the data / processing plan, how network critical aspects of the application are, the user agent makes the decision
... none of this is easy

Stephane: no cost for the user if using wifi or some cellular networks. but there's a big cost impact for the network operator, if not for the user

Immserive Web and 5G

Immersive Web and 5G, by Diego Gonzales

<dom> ScribeNick: dom

Diego: presenting Samsung internet developer relationship team
... Samsung internet is a chromium-based Web browser shipping as default browser on galaxy devices
... it's an ever-green browser, constantly up to date
... among the new cool latest technologies is the WebXR API
... Samsung in the Web: we have the internet browser, we contribute to Chromium, and tailor our browser to our specific devices
... we also contribute to standards (e.g. in Service Worker, XR, Payment Request)
... contribute to cross-browser initiatives
... Going into Web & (V|X)R
... Expectations from the Web: linkability, shared context, privacy friendly, accessible
... on VR, the user expects immersiveness, which requires orientation tracking, position tracking (for 6 degress of freedom), 360 content (audio & video), low latency (below 20ms for immersion), different input methods
... There are different type of VR headsets, e.g. 3 degrees of freedom vs 6DOF
... right now, users have to wait downloading content from a closed pre-approved environment
... we can learn from the Web there
... that's where WebXR comes in
... WebXR is supported in Samsung internet, firefox, chrome, edge, oculus

Jeff: you mentioned haptic support - that and all these other modalities make accessibility that much more challenging

Diego: this was one of the topics we covered at the WebVR authoring workshop, with a conclusion that a lot of the accessibility primitives are missing at the moemnt

Dan: you can look at AR & VR as an accessibility framework too
... it can be used by other technologies for accessibility

jeff: in principle, it could be a huge enabler - but we need the right base support

Diego: you can target all the combination of OS/device and find a browser with WebVR support
... from a hardware support, you can build support for everything: magic window, 3DOF, 6DoF, controller, web speech
... This brings us to connectivity toward devices
... imagine mixing in TV, smart appliances to build VR multi device experience, with IoT playing a big role
... This satisfies a number of developers needs
... One is discoverability
... [showing example of sensor-connected dress broadcasting a related VR experience at the URL]
... we built this as a Progressive Web App - this brought up visibility on the homescreen, independence of network connectivity, frictionless experience, preloaded assets and more visibility in existing app stores
... Another need satifised by this is reach: the Web is the most widely available distribution platform
... another aspect of this is the progressive enhancement enabled by the Web whereby I can access this experience across very different type of devices (from 2d screen to 6DoF VR headset)
... Another aspect of the Web is that makes things available ubiquously and immediately
... the Web is also inherently a social platform [showing an example of a socially constructed VR world by kids]
... WebRTC allows to bring real-time interactions to VR, as e.g. in Mozilla hubs enabling 3D social interactions (again, available in any device, VR-capable or not)
... Finally, the Web enables accessible platform for creatives, which enables new creators
... Web + VR = ♥
... The Web can help democratize and commoditize VR
... Now looking at what role 5G plays in this
... 5G promises low latency, 10x faster speed, 1000x more traffic, robust mobile networks
... One angle to look at this is multi-device experience - bringing data from IoT and integrating it into VR experiences - similar to what Dom called Ambient Web
... also new headsets coming to the market are very autonomous, but very dependent on the network
... so WebXR + 5G
... progressive enhancement can e.g. get higher quality resolution based on the network
... improved latency is key to make social VR
... to enable creation on the go, making creating VR on the go requires sharing/saving content on the go

Eric: what kind of impact are you seeing on the phone itself when running VR content?
... I've heard reports of heat, battery drain

Diego: that varies across devices
... and it also depends on the level of quality you require (e.g. lots of polygons)

Eric: so high quality would probably drain battery pretty fast
... I wonder how that intersects with Google's usage of android as their main platform for VR

Dom: they've also released an autonomous VR headset

Eric: but then that loses the pervasive availability that mobile brings

DIego: [reviewing adoption report of VR use cases]
... you could imagine a VR-room service provided in hotels
... Some of the key enablers: low latency; transmitting more sensors (e.g. touch) data requires lots of brandwidth
... you can imagine low-latency used for e.g. remote medical interventions, or engineering
... being able to deliver large assets on the go (e.g. live streaming of 360 content)

Didier: do you have a specific value for low latency in VR?

Diego: 20ms

Goran: is that latency needed to be reliably constantly under 20ms?

Diego: there are techniques to smoothen if lag appears - e.g. safe spaces the browser would bring you in case of spotty connection

John: is it 20ms total (RTT)?

Diego: yes
... that's what needed to avoid motion sickness

Ulrich: 20ms feels a bit high for some use cases - e.g. while driving, or catching a real ball while wearing a VR headset
... for this, you need more like ~1ms

Diego: the latency I'm referring to is related to the frame-per-second visualization

Dan: it's a different model between AR and VR

Louay: there are 2 types of latency: motion to photon latency requires 20 ms
... that's independent of the network, expect if you do cloud rendering

stephane: you can also pre-calculate the movement locally - hard to translate movement latency to network latency

@@@: there are all sort of latencies to consider

Zahed: in the social context, where the lagging comes from? to understand if 5G would help

Diego: (information about shared artefacts not going through fast enough)

Zahed: what is transport? or processing?

Diego: not sure - Web assembly might help for processing

Zahed: it would be good to get the fighres of what's needed at the transport level

Stephane: this shows the importance of measurements
... (which is problematic from the network in an encrypted world)

Scalable media delivery on the Web with HTTP Server Push, by Lucas Pardue

Lucas: I work on a team looking at internet media distribution
... as a broadcaster, things used to be quite easy and simple: a network of broadcast transmitters as a fixed cost, independent of a number of watchers
... our iPlayer service keeps getting more popular - which comes with a cost rising in proportion to the popularity
... in UK TV, only 85% is done in live viewsing - the rest of timeshifting and on-demand streaming
... (for UK main channels, not online services à la Netflix)
... (this includes live viewing on the iplayer)
... live viewing still plays a major role

John: do you have a breakdown between IP and broadcast for live viewing?

Lucas: it's actually hard to measure
... Live events: the biggest BBC event was England vs Wales in Europe 2016 - with 20% done via IP
... in the US, the most watched live event had only 3% done via IP streaming
... There are more and more bits to shift: SD, HD, UHD
... improved colors, higher frame rates, 360, binaural audios
... that means higher CDN costs
... and meanwhile our spectrum is being eaten away by telecom operators

Didier: do you use use MBMS?

Richard: we've had an experimentation with it, but we're not using it in production yet

Lucas: we want to have better UHD services, but don't have the spectrum for it
... Our challenge: how can we reach 98% without terristrial spectrum: this is the IP glidepath
... with audience increasing by a factor of 10, bit rate by a factor of 5, this grows our cost by 50

Goran: is that cost a real pain point?

Richard: yes
... BBC had its own CDN in the UK - and that has a good RoI
... Media streaming over IP multicast helps reduce the cost of redundant transfer
... IPTV works well on managed networks
... 3GPP has also MBMS, although there aren't so many capable clients for it
... The industry has been switching to Media Streaming over HTTP - as this works over any kind of network (incl unmanaged networks), and on many kind of devices and clients (incl browsers)
... this has worked using existing network technologies and CDNs
... this also aligns with our charter that requires broad reach to distribute our content
... Adaptive streaming over unicast HTTP is basically about chunking content over http with different encoding and bitrates to adapt to network conditions
... this is in contrast in IPTV which is less flexible
... We've been looking how to take this from unicast bringing it to multicast
... Cablelabs has also work in this space, 3GPP with enTV as well
... DVB has a spec on adapting media streaming over IP multicast
... they released a reference architecture in March
... This DVB architecture allows switching from unicast to multicast via a gateway

Dom: can you walk us through this a bit more?

Lucas: main questions are around discovery and transfer; SDP is used to discover capabilities
... in the Web context, WebRTC has used SDP for peer discovery
... it's a difficult area to see how this discovery happen - we have a particular proposal for this
... one of the challenges is having multicast gateways available in the network - we're exploring how 5G can help in the 5GX test bed
... there are a number of possible deployment models, with a flexible approach on where the multicast gateway gets deployed
... e.g. in a set top box that would be made available via an HTTP proxy
... or in an edge device
... via MEC
... particularly useful for local events, if we can solve opportunistic discovery
... We have an independent Internet Draft to bring HTTP over multicast QUIC
... Discovery there is solved with HTTP Alternative Services (RFC 7838)
... we advertize various hostnames for different bit rates encoding as alternatives, and applications can pick the one that better fits the network conditions
... this applies for Dash, but also for any bulk file delivery

Goran: will you cover how this would be exposed to the browser?

Lucas: partially
... HTTP2 introduced Server Push which enables the server to push resources it thinks you'll need
... i.e. multiple responses to a single request to improve Web page performance
... but I argue it enables new use case
... QUIC came along based on some of the HTTP2 lessons
... QUIC has also Server Push
... A lot of the QUIC congestion control relies on bidirectional communication not available in multicast

Goran: so as a Web app subscribing to this, I can't provide back pressure and thus agree to receive an unlimited amount of data
... not sure how this would be surfaced to the user for approval
... this ties in to the question of the browser not trusting the network by default

Lucas: part of the work we've been doing in the past few months is bringing our existing work in a proprietary controled context to the browser context
... right now this would be handled by the application

goran: it should be under the browser control

stephane: doing congestion control in JavaScript exposes network risks to the wrong level

Colin: you could put circuit breaker in the browser to limit the risk of congestion control as a saftey measure

Paul: what would prevent saturating the link if there is no backpressure?

Lars: you could use marking to make the QUIC multicast lower priority than regular TCP

Colin: this would multicast QUIC, not uncontroled UDP, which is guaranteed to get some congestion control

Lucas: Server Push has had mixed levels of adoptions, but for us, it's a great solution
... we don't have access to server push in JavaScript
... the push cache is not reliably available - an API to expose the arrival of a Push would help tremendously
... Alex Russel and Jake Archibald have been discussing how to expose this, but no one has completed that work yet
... So we came up with our own proposal: a server push API
... this is not just for multicast, it could also be useful in unicast case
... it's a very simple proposal aligned with the Fetch API
... it's a exposed as an event that brings the request/responses objects from the Push
... to facilitate experimentation, we added a transport protcol gateway to transmit QUIC multicast over websockets

Stephane: do you have encryption between the multicast server and the gateway?

Lucas: theortically - but in this circumstance, we have to expose the key so we have to fudge around QUIC encryption
... this exposes risks that QUIC is supposed to protect from

Lars: this is an understatement :)
... but it would be great to find the right approach and finally bring multicast to the browser

Lucas: exactly - this is one proposal, but the key is really to find ways to bring multicast to the browser for scalability
... we've been using Web Assembly to port our deserialization to the browser

Goran: this is an interesting way to show what we would want from browsers

Lucas: this has been done in other contexts e.g. for codecs

richard: right - this is a proof of concept to show what we need from browser vendors

Lucas: once this is all in place, this is all oblivious the client
... this works in Firefox and Chrome; now that Service Worker is available in Edge and Safari, we will investigate if it works there as well
... we want to have a public trial on this - we have a white paper that describes this in more details
... We think the future of multimedia streaming requires a mixture of multicast and unicast to match heterogenous networks
... having convergence on transport over QUIC would be great
... The Web Platform faces challenges in supporting new content delivery mechansism
... some of this is solved with WebRTC, but not all - doing all of this in a secure context is key

Ulrich: from a radio guy perspective - if we manage the transition both on the Web level and in the network level, we gain better usage of the spectrum
... including with ubiquitous coverage

Richard: @@@ 3GPP release 14

Ulrich: our vision from the mobile side - the terrestrial network could be-used to enable also low-latency applications, not just video à la DVBT

Louay: you extended the DASH.js player in your prototype?

Lucas: no, we're using the conventional dash.js player
... all the smarts are the in the service worker
... the service worker looks for multicast options among the various options exposed in the manifest

@@@: this is just a protoype - do you have plans to bring to production?

richard: we're planning a public trial
... to go to service with it, we need to get browsers to adopt the API, but also to test it from a service perspective - it's a long road

Lucas: we've been involved in QUIC to make sure that QUIC CAN support this

Wrapping up

Eric: this brings the first day to an end
... a lot of meaty stuff today, a lot coming still tomorrow
... as you sit through the sessions and see opportunities where we need to get the 5G and W3C communities to work together, please write them down
... we will be reviewing them tomorrow as part of the conclusion session

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/13 13:44:45 $