Dan: I want to give a recap of where 5g has come from
... the first significant stake in the ground was set by NGMN in 2015
... the interesting thing is what's in the red box is in slide 2
... business contect, use cases, business models, value creation
... nothing about technology
... more than any other generation of radio, this was led by usage
<dom> Dan's slides
... if you look at the classic criteria of what exists in mobile network today, and what is in the NGMN paper, you need either lots more bandwith, much less latency, much wider coverage, etc
... this is all driven by operators wanting to move outside of their existing use cases
... there is an understanding if you're delivering lots of bandwidth, you need a very narrow beam - looks like a wireless wire
... the requirements came after
... 10x bandwidth, 1-10ms latency, five 9 reliability, 100% coverage, >10x connections, 50Mbps per connection everywhere, 1000x bandwidth/area, 10 year battery life (for IoT), reduction in total cost of ownership
... all of these things draw back to MNO biz models addressing new customer segments [slide 4]
... wanting to move away from just B2C to also B2B and B2B2C
... moving from B2C to B2B brings very different constraints in terms of reliability expectations, contractual obligations (KPI, SLAs, penalties, litigation)
... ITU has started their IMT-2020 process by which what meet requirements for a pseudo 5G would look like
... this covers all the requirements previously discussed, excpet for coverage and five 9 availability
... not by accident - these two depend on mat-by-mat decision process where operators have to make business decision on where to invest the cost of setting up and maintaining mats
... coverage is a business case challenge, not a technology challenge
... likewise, five 9 availability is not a technology challenge, it is an operational challenge coming with a cost, i.e. a business case challenge
... so when 5G is launched, clearly the coverage/availability requiremnets won't be met
... how do we build these new networks - 6 main tenants: mm wave (lots of available spectrum band)
... the problem with mm wave bands don't go very far - ~50m for @@@
... up to the point where you have to a very pointed beam with limited spread,
... that's where you need electronic steering of beams that track people as they move
... network slicing - to be covered in a moent
... massive MIMO - getting devices with e.g. 16 antennas and thus 16 bearers, which increase bandwidth significantly
... massive connectivity for IoT - with grant-free multiple access
... low latency network - by reducing latency end to end, including with MEC to tackle the limits of physical distance
... There are many other radio improvmenst [slide 7] to help meet the requirements
... Among issues with mm waves is that they don't traverse things well - including tree leaves
... CoMP helps by getting devices connected to multiple cells at once
... CoMP blurries the notion of cell - all the cells form a big shared cell
... you need small cell support for indoor coverage
... Topology flexibility is another coming with 5G (although not 5G per se)
... softwarisation of the network has been well understood and applied in entreprise network and is being brought to mobile network
... up until 4G, mobile networks required lots of dedicated hardware for optimization and performance
... now hardware is fast enough that software can run on commoditized hardware
... Cloud-RAN centralizes a lot of the software running in base stations - that helps reduces CAPEX and OPEX (less power consumption)
... MEC goes into the opposite direction of cloud RAN by pushing more things to the edge for performance to help with 1ms latency
Zahed: is MEC only for core network functions?
Dan: up to operators - will come back to this
... [slide 9] Meeting the goals
... what helps, and what hinders
... Cloud RAN is not helping with latency, likewise NFV/SDN potentially degrades performance
... most things cost money and thus are bad for TCO
... Meeting all these requirements require significant network investment
... conversely, the things that help with TCO are not really helping meet the 5G requirements - they bring flexibility to meet new business cases via network slicing
... Network slicing needs dynamic resource allocation, which require orchestration
... you're trying to sell this to entreprise that probably already have their own orchestration, their own services
... Customers (e.g. BMW) don't want to buy a slice to connect all their cars, they want to buy a slice to connect all their offices, their salesman, mobile workers, logistics
... they're likely to get it from a system integrators, not care about the network directly
... they also have their own network functions (e.g. virtual firewall) - which will require some level of integration
... and enterprises have integration with many other type of networks slices
... this makes the orchestration layer much more complicated and painful
... and all of this has to be funneled into limited radio spectrum
... [slide 11] An example of secondary implications
... keeping low latency requires connect between networks at the base station level
... this comes wtih big technical and commercial challenges - commercial challenges in particular take a lot of time
... [slide 12/13]
... you only get 5G standalone service once 5G core network is deployed
... the 5G Core Network architecture is very similar to 4G, but redefined as service based architecture built on HTTP2
... the way this has been architected is a 3 tier approach - exposing services
Richard: where does QUIC fit in there?
Zahed: it is being considered
Kevin: part of the issue is that it's not standard yet
Dan: also in release 16, a lot of these functions are being removed in favor of the more finegrained services
Dan: The Application Function (AF) allows for 3rd party applications - either talking directly in HTTP2 or via gateway
... that AF has access to everything in the control plane: start network slicing, store data, analytics, ...
... this brings far greater integration into the core network
... this could enable pushing content very close to the end-user
Lucas: Does HTTP2 help particularly here?
Dan: the only reason is that it has been chosen :)
DanDruta: HTTP2 is good for long-lived connections
... also helps with multiplexing API calls
... HTTP2 applies very well to these requirements
DavidHutton: any impact on performance to moving to API calls everywhere
Dan: I'll ask that to our panel :)
Dan: This question of application integration brings a feeling of Deja Vu
... OMTP, WAC, TheParlayGroup, OneAPI, OMA, Parlay
... there is a concern of different velocity between network deployment and applications development
... so where does that take us?
... There is a big gap in APIs to enable integration between apps and network
... We don't want 3GPP to get this wrong (as happened in the past)
Jeff: 3GPP is already interested in looking at these APIs
... do we think they may have an interest in working with us in developing them?
Dan: I think we should at least try
... there is an open opportunity - it's not clear that 3GPP knows what app developers need
... 3GPP do amazingly good things; where they tend to fall down is integration with the service layer (for a mix of technical and business reasons)
... Conclusions: there are good things with caveat
... 5G deployment will take time - plenty of maturation needed, technical and commercial considerations that need to be solved
... the difference of velocity between communities is a big open question
... no one is really use about the right business cases for 5G yet
... at the moment, network operation center is being revisited by e.g. the TIP project from facebook, adopting data centers practices
... [slide 20: Consequences if we take all as read]
Ulrich: the 1ms latency is not really best for AR/VR, it's more for control case s(e.g. in the factory case)
Dan: Panelists: Kevin from Vodafone, Didier from Nokia, Chris from Hutchinson, Goran from Ericsson, David Hutton from GSMA
Dan: first, wanted to get your input on what I got wrong, what I missed
Kevin: [introducing himself]
... one consideration you hinted on - an application could ask for some certain characteristics in a network slice
... this is all great until you hit the radio scheduler
... for the consumer internet, operators run a best effort service
Didier: when you presented, I was a little bit surprised by the service-based architecture, you claimed that the third-party Appliciation Function can access to everything
... it's not clear to me that the standard says that - this will be open on a case by case basis by operators
... it's not clear there will be interoperability there
Dan: the decision is operator-based - it's not a technical limitation, it's a business decision
Zahed: I kind of agree and disagree with Dider
... in some case,s ASF could connect to EUSF, to EUDR
... some APIs would be exposed by operators
... network functions won't talk to each other "for free"
Jeff: any internal capability which is surfaced on an operator by operator basis
... are less likely to be used by Web developers
Goran: the reach of the API is a key question
... the classical way we expose functions in telecommunications is we have optimized hardware on which we layer on top flexibility
... we're virutalization hardware, but this includes much more than: containerization, servicization, which opens things like machine learning
... this should push us to reconsider how we build this service based architecture beyond the current layering approach
Chris_Seal: one lesson from 3G is that the architecture had a lot of redundancies, a lot of functions we didn't use
... I'm sure the same will happen with 5G
... I was also involved in Parlay
... for most appliciation developers, they just need higher level abstractions - they don't need all the 50-100 parameters exposed by network slicing
... I don't think any operators will let let go of is anything that affects capacity planning
... e.g. ULRCC costs a lot
Dan: will that be put as a technical limitation, or will it just come with a high price?
Chris: hard to say
... if you provide a gold-service, how will other customers react to being pushed in the priority lanes?
David: at GSMA, we're looking at 5G from a deployment / commercialization perspective
... on paper, everything looks great
... the things that haven't been addressed include:
... - security - softwarization opens new attack surfaces
... the notion of trusted domain in operators private network needs more scrutiny
... - performance: moving away from proprietary hardware necessarily has an impact on performance
... SBA is a good development for service innovation - even just for operator-internal development
... but keeping the same flows in this new architecture - you're not really improving flexibility, and this comes with a performance penalty
... - commercialization: network slicing is a good concept, but how dynamic will it really be? or will it just be 4 static slices (consumer, emergency, ...)
... and how will we monetize it? QoS never really worked$
Dan: how many slices do you think we'll existing 5-6 years after 5G launch?
Didier: 100?
Kevin: regulation-dependent
Goran: 42
Chris: 100 sounds high (but maybe not?)
... in the tens
David: I think we will have very templates for slices (3 to 5), but multiple instanciations of these templates
Zahed: agreed
Dan: if you listen to senior people, network slices enable MVNO, enterprise networks, KPI-based slicing
... MVNO will need slice their own slices for entreprise slices
... this becomes an exponential problem
Chris: this depends on how slices materializes
Dan: I've asked the number of slices at a recent event in portugal - the range spread from 6 to millions
John: I think the protocol has 8 bits for the slice number
Didier: re 3 or 4 slices - this all depends on the need for roaming
... we only need specific templates to manage roaming
Dan: is there an opportunity for W3C to have some input to the 3GPP process? if so, what's the best way to do that?
... what advice we can give to avoid past mistakes
David: I think there are huge opportunities, but it needs a change of mindset from operators
... previous attempts have not taken off
... the opportunities for 5G really need enterprise adoption, which require these APIs
... 3GPP has only defined a framework for APIs, not actual APIs
... the way GSMA has worked with 3GPP is by providing requirements (e.g in IoT)
... from the Web side, this should be very simliar: providing requirements of what you need from the network
Eric: what's the best channel?
David: one of the best channels is to be at the meeting
Goran: bwaaaa
David: you need to make sure someone here is following up in 3GPP
Dan: there needs to cross-participation to help
Goran: we need more extensibility from the browser side to help with experimentation which can then help adoption in actual browser
... that makes it hard if there is too much fragemntation on the network side
Dan: the ways of working are different
... 3GPP have fairly regular meetings with discrete agenda - it's a bit legacy of working, but it works for 3GPP
... we need to make sure the organizations/communitiies know how to work with another despite the difference of cultures
Kevin: I was involved in OneAPI
... we spent considerable time even explaining what an API was, and why they should be exposed
... what we learned from the failure: an API needs to be used, which means they need to be useful - it needs to match a business need
... there needs to be lots of involvement with stakeholders
... it also needs to be useable - there was very sparse implementations, and a lot of hoops to go through
... rather than having one operator starting its own development program - plug your operators functions into existing platform (e.g. AWS)
... Also, APIs need to be safe - this absolutely needs engagemnet from the developers community
Dan: given past experience, has enough changed? has the value become clearer?
Kevin: I think so
Stephane: do you think long-tail developers are the same as the one we want to address with network slices?
Didier: when you look 5GAA and 5GIAA (industry 4.0), they're not the kind of community W3C hosts
... W3C is not really at the top of 3GPP targets for apps
... they're looking at more specific verticals
Dan: there is a very broad community looking at telco APIs
Stephane: I think the APIs that are needed for slicing are distinct from the ones needed for long tail developers
... I think the ones we need to talk about long tail developers, i.e. the ones that live on the "internet slice"
David: There is so much potential with innovative Web developers (e.g. with MEC)
... we need to build the framework that allows these developers to tap into these opportunities
Kevin: the one horrible aspect of mobile operators is the access network
... determining who is authorized to access privileged network apis is a key question
Jeff: just make it open :)
Goran: that's not enough
... different operators have different business focus, which drive different priorities
... e.g. if verticals is a priority, long tail developers are less of a priority
kevin: also, access networks are regulated which creates necessary friction
Chris: even if parlay has not been successful, some operator APIs have been successful
... another complexity is the constraints we need to keep on privacy - e.g. we can't expose phone numbers
<jeff> [Eric introduces speakers]
<jeff> ... [Joe Butler and Sharon Ruane, Intel]
Joe: we're not from a networking background
... our background is from work of orchestration in data center
... we've been looking closer to the edge, which brings us closer to the network
... there are increasing demands for network performance
... but as you increase the number of network configurations, you still need efficiency and flexibility
... this increases complexity
... you move from a policy-driven set of simple rules to a much more reactive approach
... our overall premise is that high precision orchestration requires reliable insights to applications sensitivities
... as you get more finegrained components, the complexity raise
... slide 3 explains where we position our work
... the role of orchestration in a distributed system gets more complex - there are plenty of orchestrators (e.g. openstack)
... our role is to automate their configurations
... we want to help orchestrators deal with this increasing complexity with advanced telemetry
... accompanied with heuristics
... virtualization and softwarization brings network as a service
... edge data centers have constrained resources - a big difference from classical cloud computing
... adapting to these constraints is key to orchestration
... [service function chaining: slide 5]
... for increasingly visual content (fastest growing type on the Web), content oriented applications come with analytics functions as well as network things
... the affiinities that these network loads exhibits are very different
... [toward network functions - aaS, slide 6]
... what's emerging, esp in larger CSPs, is very short-lived instanciations of functions (e.g. in AWS)
... We explored application adaption in the past - by expanding the developer environemnt, with an application could adapt to different environments
... it turned out to be messier than we had expected
... with ever more components, ever smaller components, we're way beyond the time of handcrafted policies
... [emerging edge use cases, slide 7]
... applicable both in the industry and transport ecosystems
... a surprising fraction of computational activities are A/V processing
... in-vehicle orchestration and for V2X are merging key for the next 5 years
... dynamic resource topologies
... [Resource Allocation: Prescription, slide 8]
... classical way
... the problem with that is it is often wrong, often naive, scaling the wrong way
... it's fine as a starting point, but it doesn't assure you of efficiency
... A second approach is through learning [slide 9]
... [Machine Learning in context - slide 10]
... data scientists don't have a magic wand
... our goal is to automate precise and efficient placement & adjustment driven by service objectives
... sometimes deriving the metrics is hard
... then how do we express these constraints to make them decidable
... [Example: dynamic placement, slide 11]
... trial to orchestrate > 100K mobile end points
... [Automated Performance optimization via Machine Learning, Sharon Ruane]
... [Prediction of Heterogneous Workload behaviour]
... [slide 15]
... [slide 16]
DanD: AT&T is very kind in working on the open
... [every company represented in the room has ongoing AI-related work]
... Acumos AI tries to address a fundamental challenge: faciliating collaobration of AI activities
... it's started as an internal effort, but realized it was more useful if done in the open - it's now a linux foundation project
... it's a market place where people can use and share models, as well as learn about various things
... it helps grow awareness of AI, promote its use
... the platform that is available on acumos.org is osmething you can instantiate internally or re-use the central one
... you can also federate across acumos instances
... acumos enables to manage both shared and private models
... it also encompasse sthe deployment and execution environment
...it's all based on open source, with the ultimate goal to create an open ecosystem
... we think there is an opportunity for the industry as a whole to provide that kind of collaboration
... it's all open source, so you can the find the links to the code, and accompanying documentation
... this is all about bringing more collaboration, more transparency both inside and across organizations
... this provides a foundational base for those things to happen
... I'm not going into the details of which models you can build - this is a framework for collaborating on these models
... there are models on the marketplace related to face recognition, face blurring, image identification
... This is just one part of the various activities we're involved in - ONAP is going to benefit from this significantly, when we use AI in the network
Goran: this workshop is not an AI workshop
... but it's tricky to discuss Web & 5G without mentioning what's coming ahead, and AI is clearly on the roadmap
... We also want to have a simple picture of how ML and AI can be used in Web apps
... the innovations in Web Apps will source future innovation for the network
... part of the question is what happens when you have AI both in the network and in applications
... the timeframe for these discussions is not today or tomorrow - we're looking at 2022-ish, once basic 5G has been deployed
... and the various existing AI assistants have come much further in their evolution
... [an example Web apps with MI inside - slide 3]
... WebRTC enables to build applications on caputred audio / video
... Imagine a smart WebRTC-based app that predicts user intent to prepare the establishment of connections based on previous user's behavior
... this could then trigger at the network level the provisioning of a TURN server to facilitate the establishment of the WebRTC connection
... through network intelligence
... there can be AI at the browser level, on the server-side, in the network - and the UI itself can be AI-powered (à la Siri)
... we're seeing lots of investment in bringing AI-enablers in devices
... this paves the way for a lot of innovation in this space
... in this simple example, we had 4 models in operations
... each of these models have to be implemented in software that needs to be maintained, deployed, debugged
... What does it take to deploy a data model in production?
... first, you need to collect data, clean it, explore & design models
... then you need to train & evaluate - which can cost a lot
... and you do that as an iterative process - you need to monitor your model to make sure it behaves as you expect
... two processes: service delivery, and the model devops process
... one key emerging question is about the transparency of these AI approaches, beyond algorithms
... [Challenges and some "co-optimiznig" questions", slide 6]
... what will be the impact on 5G of these machine learning technologies in Web cloud native apps?
... can 5G be an enabler for these media intensives apps?
... what cross-layer colloabration we need?
... [Co-optimization? App-network collaboration?]
... distributed computing - I don't believe in edge computing in base stations due to the need to keep the footrpints low then
... for cross-layers integration, you want to avoid tight coupling
... there are barriers on the public Web for integration (incl network neutrality)
... in private networks with verticals, there are more possibilities
... the whole devops principle is to bring together the people developing and deploying
... we need to bring that mentality to telco API deployment
... can W3C help with hosting these discussions needed to help vertical integration?
Lucas: what's the trust model for the "private" Web?
Goran: you need defense in depth; encryption and authentication everywhere
DanD: I understand your example, but I'm going to challenge it
... the reality is that I can turn TURN into a service offered by a complete different entity - one model less
... likewise for the app
... if you decompose your app properly, you have less dependencies and issues
... I disagree this implies Web developers need to understand the network intricacies - it's about exposing the right high level abstractions
Goran: right - you may want to outsource a lot of the AI, but that comes with its own set of challenges for the management of models
Chris: you're showing slices with public and private internet
... where does network neutrality fit into this? only to the public slice?
Goran: my understanding is that it would only apply to the public internet
Ulrich: there is a view that network slicing is easier to accept from a regulator perspective than QoS
Vincent: there are ongoing consultations on network neutrality and how it plays with network slicing
... the conclusions will be published soon
... my understanding is that with network slicing, they are likely to be considered as separate networks
Stephane: one guideline that I've heard is that the private slices should not impact the quality of the public internet service
... it's not likely there will be strict rules, more of a set gray areas
... Another related question: if we want to optimize the network based on app data or vice-versa, there needs to be knowledge circulation - which is likely not to be coming for free, or not at all
... there are likely to be regulatory questions around that
Chris: my understanding is that slices can be multiplexed, where they only interfer in simultanous usage
... Another related question is how to expose MEC to 3rd parties in the consumer place
... The protocols should not give away my location to 3rd party I don't have a relationship with
... as soon as you enable deployment of MEC in specific locations, you expose the subscriber location, which is probably not allowed
... operators are not allowed to share freely cell-ids
Goran: this opens up a new information leak
@@@: is there any existing work in W3C to enable AI in Web apps?
Dom: there are a number of ongoing discussions to expose ML primitives; complementarily GPU processing via Web GPU
Eric: there is ongoing discussions in the Web Platform Incubator Group around these primitives
Li: we have some existing work in this space
Eric: I think it's likely we will see emerge a dedicated CG in the upcoming few months
... another important related issue is security
Ulrich: I want to support Goran's point that network APIs would be easier to achieve in private networks
... ad would likely be a good place for W3C to work in
... 5GAA and 5GICAA are xample of organizations where these discussions get raised
Goran: W3C's strength is the connection from the browser vendors
... lots of learning to be gained from them
... in particular, getting a clear understanding the security model and how it can applied to other contexts
... e.g. to help defense in depth
Goran: there is a // to the browser sandboxing and containerization
... a browser is virtual machine; it's also a lot much more
Eric: as you get into machine learning - data is king
... the amazons of the world are accummulating mass of data; operators are building their own data from the network
... how can we get them to share and work together
DanD: I think we need to keep separation of concerns, and define clear touch points
... in Goran's example, making TURN provisioning as a lambda function on AWS
... the kind of optimization Sharon is providing can be turned into a well-defined SLA
... the collaboration doesn't have to happen at the data level - it can be at the service level
Stephane: would optimizing the network infrastructure be such a possible touch point?
... e.g. WebRTC Stats or the the rebuffering in DASH are available to apps/browsers, but can't be seen by the network?
... Is that a place for such a cooperation?
DanD: getStats API is offered by the browser to the app developer
... what the app developer does with it is up to the application
... stats are a service to the application
... the network could also provide middlewares to expose data from the network side
... the app could benefit from gaining this additional knowledge
Goran: information exchange makes sense, but can we make it scale? esp with XXX operators?
... if so, why isn't it happening?
Joe: there are likely business barriers
Goran: indeed
... one learning is that we need app developers at the table to be successful
Jeff: one reasons why app developers may not be there is them not getting the signal of operators being ready to open up 5G API
... that's a chicken and egg prolem
<jeff> Dom: Key is to find intersections
<jeff> ... browser vendors have deep knowledge for their own environments
<jeff> ... last time W3C had the conversation, the operators were not ready for the discussion
<jeff> ... "the network is ours"
<jeff> ... Interesting discussion today whether that is changing
Eric: I'm presenting in my name, but many other people have been involved in the work behind
... my presentation is about an internet draft - this is not a standard yet; we hope to get finalization by the end of the year
... what are we trying to solve
... one issue is how to select among multiple IPv6
... ipv6 doesn't change the datalink layer, the transport or application layers
... it only impacts layer 2
... it also introduces Neighbour Discovery Protocol, which replaces DHCP and ARP
... NDP works where devices send router soliciations in multicast (at boot and then every 5/10 minutes)
... when an ipv6 router is available, it response swith a router advertisement which comes a 64 bits prefix, completed with a random 64 bits
... ipv6 is here to stay
... 1/3 of US users are on ipv6
... in India, almost all users are coming from Reliance Jio, a greenfield operator working with all the latest technologies
... 3GPP relies on router advertisement
... [Hosts and networks are multi-homed]
... 5G slicing adds more complexity to the existing multi-homing situations
... with IPv6, a given interface can have multiple addresses
... the question arises is which IpV6 address to pick as a default address
... there is a protocol to do (rfc6274), but it doesn't work very well
... it needs more information from the application
... this is important e.g. when doing DNS resolution with CDN-cached contents
... it also doesn't work well in cases where anti-spoofing systems are in place
... there is a proposal to address this: PvD (provisioning domains)
... PvD can be extended with application layer information
... this is sent via router advertisemnet
... we identify each and every PvD with human readable domain name
... this also opens up the possibility to fetch data from HTTPS
... every ipv6 capable hosts can get that information, even in an ipv4 network
... the URL of the PVD specific information uses a well-known address, which resolves to a JSON file with additional information
... this could be used e;g. in the context of network slicing
... Another issue we're trying to address is captive portals
... among other issues, the probes required to detect captive portals create privacy issues with the targets of the probe
... with PvD, the JSOn file is mandated to advertize the captive nature of the portal
... this can also enable connection for automated systems à la IoT
... PvD Status and next steps?
... code is available on Linux
... we had an iOS implementation developed in 1/2 day in a hackathon
... the PvD can help applications expose which network to pick based on their characteristics
... PvD can be extended via a IANA registry
... you could expose optimized for VoD video, and e.g. properties of each 5G slice
... Reminder: this is still a draft, comments are very welcomed
Chris: in 5G specs you use GTP / DHCP / DNS
... is this complementary? can you use both?
Eric: they're orthogonal
... in 3GPP, the RA is mandatory as part of the ipv6 and the RA can advertize the PvD, even for an ipv4 connection
Jeff: a feature like saying that this particular connection is metered - that's transport level
... there are applications that can be interested in that e.g. for WebRTC
... are there already work in incorporating this in applications?
Eric: this is one of the things we've been exploring in the NEAT project
... at the IETF, we're doing the foundations, then captive portals - we haven't touched on applications yet
Lucas: have you considered how COAP would work with this?
Eric: a COAP gateway could handle this; for COAP devices, they would have to delegate TLS to the gateway
Colin: I'm a transport person - not a Web person, nor a 5G person
... I want to talk about work that has started recently in IETF
... this is EARLY work in IETF
... we've been discussing for a year or so; was adopted as a WG item a month ago
... we're actively solicitting input into this
... lots is happening in IETF at the transport and network - e.g. QUIC, or PvD as we've just heard about
... the problem is that it's not easily realised in applications
... getting applications to use new features is difficult
... the idea is to build applications on a higher level API, hiding the intricacies of the various underlying protocols
... a very long term goal is to replace the Berkeley sockets API
... What's wrong with sockets? what does it need to changed?
... The stack used to be straightforward
... with clear divisions between features provided by the OS (TCP/IP) and those provided by the applications
... with very little choices (TCP/IP/HTTP/HTML)
... sockets was well adapted to this
... the stack is now much more complicated - many more physcial links (wifi, cellular) active in //, Ipv4 is now completed with ipv6 and apps may have to use both
... we still have TCP (and it is not going away), but we are getting more and more protocols developed on top of UDP, e.g. QUIC
... HTTP2 completes HTTP1, WebRTC is bringing its own set of additions
... we're using the same API to prorgram this much complex stack
... what needs to change at the API level?
... We need to get more message-oriented asynchronous API
... sockets deliver bytestreams, but applications want messages
John: for UDP, it provides packets of unstructured data
Colin: right, for TCP, you get a bytestream, but that's not really what you want
... The API should provide the meaningful application unit
... you have to reinvent parsing wheel with the socket API
... the socket API also doesn't inform about connectivty changes
... we now have rich notion of streams that helps with reduced latency, and apps which care about timing
... the sockets APi doesn't help with this
Stephane: how does SCTP work with this?
Colin: the SCTP API is an inspiration for this work
... but exposing this with more semantics
Richard: would this API select the right underlying protcol for you?
Colin: in some cases yes
... Path discovery is another issue that isn't handled transparently - some of it needs to be app specific, but some can be generalized
... another aspect that we would hope to expose network policies
... e.g. whether an app can use cellular or should only use wifi
... and fundamentally, applications shouldn't over-specify the transport
... there should be flexibility in identifying the best combination of transport and protocols
Jeff: Is there a place where you're gettiing app developer input?
Colin: we want to get app developers to bring their input
... we're not trying to invent anything new
... but make a bigger part of the logic reusable
Stephane: what about congestion protocol?
Colin: one of the things we have is a set of protocols for setting requirements for the connection
... to the extent the system expose different congestion protocols, that's how you would choose it
... this would give a standard set of hooks to express the same things
... not reinventing congestion control, but exposing it as a hook
Richard: e.g. as a IANA registry of congestion control
Colin: for instance
... all of these things exist, but they're being done differently
... We're trying to define an abstract API, not a concrete one
... that can be implemented in whatever language
... with higher level semantics
Richard: will that be done in a language dependent interface language?
Colin: not really - we will say what an API should specify, and vendors would derive it in specifci languages
... NEAT has an implementation that looks like this, so does Apple
... likewise for Rust
... Things are changing at every layer
... it would be useful if we could expose a more generic API, rather than come up with a new e.g. QUIC-specific API
EricS: what role do you see W3C play in this?
Colin: this is not a Web API, this is more of a question of browsers implementations
<jeff> Dom: WebRTC is exposing QUIC. Are you saying that is the wrong thing?
<jeff> Colin: If it is QUIC alone that you are exposing that could be a problem.
<jeff> ... need to provide more general APIs
<jeff> Dom: We are exploring, but currently looking at "closer to the network"
<jeff> ... so you can build new data channels
<jeff> Colin: QUIC does a lot that others do as well
<jeff> ... let's generalize and put different things underneath
<jeff> ... that's what Sockets API got wrong
<jeff> ... should have leveraged a name, not an IP address
<jeff> ... make IPv6 transition easier
John: you talked about the interface should be above the parser - are you reinvnenting the presentation layer
colin: everyone writes a message parser
... it should be a generic function
John: we had that in ASN1
Colin: but that's for specifcation, not implementation
Richard: you're nto attempting to interpret the message, you're passing a blob that is the message
Colin: that depends on your target environment - it would be different in a low level language à la C from Rust or Swift which have a native http library
Stephane: in your approach, the transport services are exposed to the application, or does the application also expose its transport patterns?
Colin: yes - how much we go in that direction is tricky though
... we don't want to go into an overengineering baroque result
Zahed: one thing we're trying to identify the minimal set of data is useful
... e.g. how much data is sent at a time
colin: or exposing the amount of data for a file transfer
... but we don't want to go the level of RSVP
DanD: there was a proposal for exposing a one-bit trade-off between latency and throughput
stephane: in this case, Apple is participating and has been pushing for carrier aggregation
Lucas: @@@
Didier: does Quic provide the equivalent of multipath TCP?
Lars: not yet - planned for v2
Didier: is there anything specific to 5G in this?
Colin: not per se - one question is whether 5G needs to expose new type of features via this API
Didier: one thing 5G brings is mobility with IP changes
... will QUIC provide for that
Colin: we expect to expose event for path changes?
Richard: QUIC doesn't have an API at that moment - is this an answer to that?
Colin: yes - or at least, if you're building an API for QUIC, try to follow these guidelines
Richard: where do you this API living?
... does this still in user space?
... or does it replace the system API in kernel space?
Colin: I don't think I care - it will happen in both
<scribe> scribenick: cpn
eric: we want to gather your feedback
dom: we may want to have similar
workshops on specific topics, so please send your
feedback
... addressing gaps at W3C, needs signals of support from
you
... any pre-standardization work we could start? possible APIs
between app and network layers
... doesn't seem ready for standardization work yet
... we need to talk more, understand how they layers are
evolving, how they intersect
... we'd benefit from closer coordination
... should we have a workshop on media, IoT, automotive?
... more specific topics: MEC, 3GPP NB APIs?
... also associated topics such as AI and machine
learning
... could have another broad-brush workshop, eg in Asia
Didier: IoT applications have a
connectivity gateway, done in 3GPP without the app developers,
we had an end to end group to describe architecture
... we could review this with W3C and the Web of Things
group
... it was the first time 3GPP defined north-bound APIs
Jeff: Some participants mentioned
having browser vendors participating would give more
meaning
... would require more planning, can pick up with Dom, need to
figure out an agenda for that
Eric: we did reach out to them, but there was Google I/O at this time
Jeff: Web and 5G are abstract concepts, could be interesting if made more specific
???: Where the web is more embedded in physical objects. How would app layers want to interact with the network? W3C could provide great input to 3GPP
???: Want to understand what the verticals want. Is what 3GPP doing enough?
scribe: Engage the developer community with the operators, need to bring people together
Goran: W3C has two main roles:
creating interest, speaking for the web, but also coordinate
with browser vendors
... potential next step for work in W3C is in IoT on the device
side APIs
Eric: Coming from the perspective
of making W3C more relevant, we have to ask ourselves as
members, what is it that we do, why does it matter, how does it
translate to adoptions, products, services?
... i'd like us to shift the focus, what's the ROI on our
time?
... we could focus on a few things, with a plan towards specs
that address end customer problems, proofs of concept
... need to debate which areas are most promising
???: We need a framework to allow quick development APIs, 3GPP can take years
scribe: also need quick
adoption
... i don't know what that process is, but we need a framework
on top of what the standards communities have
Goran: an incubation framework
Peter: MPEG works very quicky, so we have to be careful not to publish too soon
Jeff: I don't know that the W3C
team can sufficiently represent the telco industry to the
browser vendors
... are there a few people amongst us who can work on
proposals?
Andrew: I think it's early to
talk about APIs, need to focus on some use cases, eg network
slicing for IoT
... then look at the browser trust model. which components need
to trust each other?
Eric: sometimes we rush too quickly to standardisation. early stage market, each vendor wants to do their own thing
DanD: there are stakeholders not
here, because they don't care. they don't have a business
interest
... we need to have something to give, in order to get
something
... a technology needs to be commoditised for people to
realised their use case isn't special
... the workshop is good for us to share information, there
were some key aspects we can pick on
... things to learn from experience, with WebRTC,
implementations matter
... this was a good opportunity for us to learn
Eric: we could define success as
seeing implementations once we've published a spec
... or as creating a CG or a WG
... the right outcome might be just this: opening the
communication channels between the communities
... just having these conversations is part of the work of
W3C
David: The baseline telco
standards define the framework
... this group should review that framework? is it fit for
purpose to build on?
... let's work out requirements, then where do the next steps
take place?
Jeff: About my conversations with
browser vendors, I want to have a conversation about the
relative roles we have
... We could have some pilots, see if it works
???: Focusing on a limited set of use cases allow us to focus on concrete solutions
Eric: focus on problems, key stakeholders, then gives a better chance of pilots and end products
DanD: in this workshop, we didn't
articulate a significant value of W3C in relation to the
semantic web
... this community should be more aware of what's happening
there, and the opportunities
Eric: we need to communicating
the value of what W3C is doing to GSMA and 3GPP
... a note of caution on semantic web, some people thinks it's
too complex or expensive
... maybe this relates to IoT - try not to boil the ocean,
focus on particular sectors
Dom: another thing is we could
create a W3C group as an anchor
... probably an Interest Group or a Business Group to act as a
steering group, contact with 3GPP, developing use cases, could
help with pilots
... organising events takes effort, this group could help with
organisation by bringing the right topics and contacts
... create focused Community Groups, Task Forces, conf calls on
specific topics
DanD: the work W3C is doing can't
be ignored. amazon aren't members. they had one of the earliest
WebRTC implementations
... the work done in W3C is extremely important. need to make
sure it has the right participation to get critical mass
... to reach that, you have to be able to convince browser
vendors to implement features in the UA
... what can we do better to create the platform for
collaboration
... adoption is driven by browser support
Andrew: we may have been a bit
too technical during this workshop
... i can see why this is useful to us, i haven't seen what's
in this for the browser developers yet
vincent: original 5G use cases:
smart cars. i agree browser vendors are key from a W3C point of
view
... there is an automotive working group, could get 5G input
there
Didier: we are interested in
studying the use cases with W3C
... i can't identify a specific need for our input in
automotive
Chris: I'd like to see input from network operators in discussing media, when we're talking about live streaming of video
Goran: This was a first workshop. A key thing will be to select topics to focus on. We have identified some areas for work: browser vendors, industry verticals
Eric: should we have an informal steering group, maybe form a Business Group, volunteers for leadership in that group
Dom: [presents overview of W3C
group types]
... Business groups can do pre-standardisation work, but
preferred way is a Community Group
... Business Groups are open to non-members
... Interest Group has the advantage of having more standing
and visibility in W3C community
... I think a steering group would be useful, gather use cases,
organise future workshops
Jeff: I think Goran is suggesting
it's too early to start one of these groups
... take an action to narrow the focus
Goran: TPAC could be the place to
create a group having done that
... I would need to come up with a more precise proposal,
informally, perhaps with a steering group
???: Will creating a group help the missing stakeholders come to the table?
Dom: Part of the process of creating a group involves writing a charter, that can help bring the right people
Goran: I need some text that I can socialize offline
Eric: We'd need to figure out the marketing pitch to the browser developers. who are the stakeholders, why would they care, and then how to approach them?
Jeff: one venue is on Monday, at
the AC meeting
... if you work for a W3C member, tell your AC rep
Eric: Thank you all for attending
Jeff: Thanks for chairing
Eric: Thank you Natasha for hosting