<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: [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
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
<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 ----
<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
<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)
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
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