Eric: I'm Eric Siow from Intel
... I chaired the Web5G Workshop earlier this year in London
... some background on this breakout
... the work started by looking at what APIs W3C could develop to enhance 5G
... at the end of the workshop, we realized that 3GPP standards for cellular radio, and IETF for transport protols are well established
... we formed a task force to look at what W3C could contribute to this well developed ecosystem
... we don't want to devote lots of time from engineers to develop APIs that don't get adopted
... we took a step back to look at the ecosystem to figure out what role W3C could play
... look at whether operators would open up their networks, which traditionally have been under tight control from operators
... also needed to look at how we would work with other existing SDOs
... we worked in that task force with AT&T, Orange, Qualcomm, Nokia
... AT&T & Orange looked at it from the network operator perspective to identify what opportunities exist
Eric Siow: we're trying to
get feedback on a specifci proposal for an Interest Group in
this space
... the group would try to bring clarity and leadership on the
work that needs to happen
... the IG wouldn't do the technical work, but do use cases,
requirements and work with existing standards efforts
DanD: there are interesting
developments happening on the network side of things, on the
Web, in IETF
... it feels like a good mooment to sit back and evaluate
requirements
... some of this (but not all of it) related to 5G
... the increase of encrypted traffic which limits the amount
of inference that can be done in network management
... geeting out of the workshop we lacked clarity on a specific
focus
... we've made progress, and we're looking for feedback and
input for some possible new ideas
... we're looking for a dialogue - this isn't a call for review
for a specific proposal
... [slide 2]
... the Web is fast growing, with always growing connectivity
in devices
... the requirements that come along with that go into 2
directions: need for more security vs performance
... these requirements sometimes come into conflict
... [slide 3]
... as a content provider, I want cost-efficiency,
reliability
... as a network provider, I want to optimize my network
resources
... as a user, I want to be a control
... fulfilling all these wishes, sometimes create
conflict
... what we think would be useful as an objective would be to
reduce the MiTM risks
... while allowing the client and server to negotiation
sharing, while improving security and privacy
... we think bidrectional exchanges between apps and networks
would help, in the form of hints
... I'll come back to the notion of hints
... the idea is to exchange as minimum information as possible
(to ensure privacy) while still allowing context
awareness
... [slide 4] Why now?
... 5G is rolling out - beyond the hype
... 5G implies softwarisation and distribution
... and moving to a service-based architecture that allows
exposure APIs with more consistency
... on the app side, lots of development on the transport side
(e.G. QUIC) and in the Web space
... Ubiquitous encryption, which we all want to support and get
done properly, moving away from implicit data gathering
... [slide 5] Dependencies
... if we want to do anything at the Web level, there needs to
get support throughout the chain of dependencies
... you need the underlying protocols and functions- e.g. work
done at IETF and 3GPP
... you also need to feature to be exposed at the OS level
before it can find its way in browsers
... more subtly, unless you have some sort of mechanism to
control cheating, it's very difficult to get things going -
e.g. QoS encourages cheating and requires trust
... cheat-proof mechanisms are key
... the model of hints is part of the approach we're suggesting
to work around that issue
... [Application hints and requests]
... here a couple of examples of information the application
might pass to the network
... e.g. the ability for the application to choose between
mptcp (ios), carrier aggregation, dual connectivity
... there is a trade-off for the app to use these features -
e.g. dual connectivity eats battery
... likewise, for content classification - in WebRTC you can
give different priorities to the streams under your
control
... it would be good to expose similar characteristics more
generally e.g. for media, to benefit from proper scheduling
capabilities which would optimize resource allocation for a
greater number of users
... the IETF LoLa proposal brings a 1-bit to switch between
latency-sensitiveness vs bandwidth-intensiveness
... [slide 7] Network hints
... Mobile throughput guidance in IETF is a proposal to use IP
options for the network to convey congestion information up to
the app which it can use to adapt (e.g. codec selection)
... if there is an appetite to come to the table to discuss,
it's worth having the dialog here, starting from requirements
and working with network level technical work
Eric: we started this work looking at how do we enhance capabilities for 5G network, we realized it's not just 5G - also applicable to LTE, Wifi, etc
DanD: these are not new things - they have been discussed in other forms, but I think having the dialog in W3C allows for a larger group of stakeholders
Varun: this has been talked
before in the IETF side
... has there been a study on how developers want to use
this
... these are interesting things for a network engineer
... for an app developer, how many of these knobs do I really
care about?
DanD: these things would not
necessarily be exposed from a network semantic
perspective
... the hint provided by the app developer would guide the
network connectivity, not express a strict control
... looking at proposals we need to look at things whether it's
cheat-proof, simple, a win for both sides
Varun: I implemented MPTCP and
brought it to the market, but we found it was pretty hard for
developers to take advantage of it
... I love this as a network engineer, but I'm curious how this
would be perceived by app developer
DanD: I use the priority example
in WebRTC - the browser gets the hint from the app, and it's
used in multiple ways
... congestion control, DSCP markings
Varun: good example, but we're still missing operational experience on that particular feature
Mohammed: as operators we know what we need, but we need the developers community - that's the point of having the conversation here
Mark: we've had previous
discussions in this space (e.g. Marnew)
... the key point of being win-win, of saving resources in a
detectable way
... e.g. ongoing randomized trial to measure the actual
benefits
... only path forward to avoid business arrangemnets
DanD: there are already plenty of
trust enforcement mechanisms in the industry, but that's not
scalable for interop
... integrity is a more important than authentication
mark: if you have hints that can
be ignore but whose mutual benefits can be measured, you don't
need any specific trust enforcemnet
... in terms of what app developers want, we don't really know
what's available
... but the first obvious thing is latency vs bandwidth
... but this should not be a flow based decision, it's a
request-based one
... e.g. when video buffering
DanD: what would you prefer: hint to the network or vice versa?
MarkW: as an app developer, if I could hint to the network that my requests are latency sensitive, that'd a great fit
DanD: on our side, this would
imply putting the flows in different radio schedulers
... having different template of traffic patterns while avoid
deep packet inspection, this would optimize resources
... I understand your point on flows vs requests
Frode: I looked at my notes from TPAC 2013 - what has changed? why would it work this time?
DanD: we've had more and broader
dialogs
... since then, ubiquitous encryption has also changed the
dynamics
... that combined with developments in the protocols, IETF
transport
... also, we haven't brought them to the table in a long
time
Mark: +1
... these discussions go back a long time and different
approaches were explored
DanD: re ubiquitous encryption,
we now have a lot more operational experience on what works and
what doesn't
... we're trying to deal with the traffic without implicit
hints
Frode: you should probably look into TAPS
Varun: TAPS is looking at
abstracting the socket protocol for various transports
... but it's not looking at the hint level
... this has failed before for sure
... lots of contention on the spin bit in QUIC
... lots of these things assume the issue is between the app
and the device, but the network path is much longer
... e.g. in P2P situations, you have to take into account the
other side of the network
DanD: what we learned from all
these other things that failed is what I was alluding as
checkpoints
... is it cheat-proof? win-win? implementable?
... these should be the litmus test of anything worth
exploring
... the whole point of setting up something as an IG is to
enable these analysis
Dom: we may not succeed, but last
time it failed, it dind't even go to the starting point
... I think the circumstances may have changed enough that we
can at least get started
... I would suggest we try to start with a short term charter
to evaluate how likely to succeed we would be
DanD: I would want to focus on requirements as a starting point
Frode: I'm all for us to succeed - but we need to understand why it didn't work before
DanD: we've been multiple
examples of past failures turning into later success
... e.g. getUserMedia, widgets vs Web packaging
Eric: it's also a matter of managing expectations
Mark: I agree that we need to
understand what these things failed
... I think we know that complexity and trust-requirement have
been obstacles
... and the principles DanD identified should help in that
regard
Frode: in the previous Mobile IG,
interest on the topic fell rapidly
... what do we think will help bring the right participants
Varun: in ICE, there has been
extensions made to express network cost (battery, power,
metering, money)
... to figure which network to use
... there has been interest in the WG to use
... we ourselves want to collect data on this to correlate call
quality with network characteristics
... I can see a need for APIs and interest, given that ICE has
done this on the browser (implemented in Chrome)
... netinfo is another example - these are super important to
us
Eric: would there be any objection on an IG to look at this?
[no-one]
Eric: support?
[13 hands up]