AV-friendly networking Cambridge, England www.ninetiles.com
Benefits of networks for AV ● Live and file transfer on the same infrastructure ● Few high-capacity links vs many single-signal ● Easier to reconfigure ● Easier to support new media formats ● PROVIDED the network has adequate ● performance for AV traffic (latency etc) ● security, reliability ● manageability
To most people, “network” = “IP” ● It's cheap ● It's ubiquitous
To most people, “network” = “IP” ● It's cheap ● It's ubiquitous BUT is traditional IP good for AV? ● It's an IT system, and ...
Media networks have requirements that IT folks don't understand
● IT traffic is bursty and unpredictable ● needs a “best effort” service – deliver “as soon as possible” – important parameter is time to complete whole transfer ● AV traffic is regular ● needs a “defined bit rate” service – deliver at regular intervals – jittery delivery harms user experience – so does latency in two-way applications
Internet Protocol ● Intended to survive nuclear war, but ... ● ... didn't even survive Baltimore train crash in 2001 ● Designed for implementation in software ● Belief in statelessness ● resource reservation etc heretical ● connectionless paradigm makes diagnosis difficult ● actually, there's lots of state – but managing it is a problem
Flexilink history ● 1980s data network ● Video and audio over ATM – Asynchronous Transfer Mode ● ATM switch for BBC Radio 4 project (2004) – IEC 62379: Common Control Interface – AES47 / IEC 62365: Audio over ATM – AES51: ATM over Ethernet PHY ● ISO/IEC JTC1/SC6 Future Network project – Problems with IP documented in ISO TR 29181
Flexilink ● Proof-of-technology implementation
Flexilink main features ● Two services: one for AV, the other for IT – AV service fixed latency, ~ 10µs per hop – IT service routes IP at least as well as traditional switches ● Low-complexity implementation – with current-generation FPGAs etc ● Plug-and-play network configuration ● Easy fault location – not “you might not be connected to the Internet” – nor “this content doesn't seem to be working”
Flexilink main features ● Connection-oriented ● simplifies resource reservation – and re-routing round failures ● clean separation between route-finding and forwarding – addressing not tied to packet format – authentication etc at flow set-up ● routing is local to each node / link – lower overheads: IT packet headers 4 bytes vs min 62 – 12 gap + 8 preamble + 14 Ethernet + 20 IP + 8 UDP – easier lookup: 8- to 13-bit label vs 104-bit IPv4 quintuple – AV routing inherently multicast
Flexilink main features ● Connection-oriented (continued) ● globally unique flow identifier in signalling messages – easy to identify loops in mesh networks ● no need for spanning trees etc ● “quasi-connectionless” option for IT packets – similar to route-caching in IP networks – supports HTTP's short TCP sessions ● model similar to Berkeley Sockets ● signalling replaces many separate protocols – DHCP, DNS, ARP, SIP, SDP, RSVP, RTCP, ICMP, BGP, RSTP, PTP, ... – middleboxes too: NAT, firewalls, ...
Flexilink main features ● Link between nodes can use any layer-1 tech ● just need a byte pipe with framing, e.g. – Ethernet point-to-point over copper or fibre – Ethernet-formatted wide area links ● provided the delay variation is specified – SDH – SDI
Flexilink standards ● Frame format based on AES51 ● AV and IT services specified in ISO TR 29181-3 ● signalling protocol: IEC 62379-5-2 ● also the recommended audio packet format – inherited from AES47 / IEC 62365 ● Management protocols: other parts of IEC 62379
IEC 62379-5-2 signalling protocol ● Tag-length-value format ● like Q.931, Q.2931; unlike SIP ● suitable for small embedded processors – no interpretation of character strings required – appropriate for Internet of Things ● easy to skip unrecognised / uninteresting items – some parts for network, some for remote application
Summary ● Networks have many benefits for audio ● The IT industry doesn't understand AV ● Current networks are IT networks ● not designed to deliver a steady stream of data ● difficult to ensure low latency ● need skilled management ● Packet networks can be AV-friendly ● and easier to manage too
Links to drafts ● http://www.iec62379.org/FN-standardisation.html ● http://tinyurl.com/fn-stds ● includes link to draft of 29181-3 ● also links to IEC 62379-5 drafts http://www.ninetiles.com/IBC2014.html mailto:j@ninetiles.com
Additional slides
“The socket level tries to guess what the application level is doing, in order to manage communications efficiently. Often it guesses wrong. ” Wikipedia page on “TCP delayed acknowledgment”
Packets need address labels ... ... which can carry the full address ... ... or a reference number which is looked up in a separate data base
Connectionless routing ● “Poke and hope” ● no negotiation with the network ● packet is lost if not enough capacity ● every packet must contain all the information required to deliver it to its destination ● packet to a new destination stored in the switch while the switch works out where to send it next
Connectionless routing ● “It was alright leaving me” ● often difficult to find why packets don't get through – “you might not be connected to the Internet” – firewalls – other middle-boxes – “link down” not propagated – something not recognised at destination – lost in the cloud
Switch structure controller (computer) control routing table scheduling packets etc buffer inputs outputs logic logic logic logic memory
Signalling controller ctl routing table scheduling pkts buffer out in ● IP: connectionless ● routing information in packet header – includes IPv4 or IPv6 address ● packets with no table entry passed to controller ● data waits while controller decides route – e.g. during ARP transaction
Signalling controller ctl routing table scheduling pkts buffer out in ● FN: separate protocol to set up route ● address in control message, not in packet – allows new forms of addressing to be used – allows different forms of routing technology to be used ● routing table entry written before data sent – data packets never need to wait for controller
Two kinds of data static dynamic content files, web pages, etc audio, video, voice context IT AV; real world traffic bursty regular service best effort needs QoS IP designed for? yes no
Two kinds of flow Synchronous appropriate for dynamic data one-to-many as simple as possible, packets sent at regular intervals but not simpler QoS guarantees (if supported by lower layers) Asynchronous appropriate for static data one-to-one or many-to-one best-effort service
One service is not enough ● Service for one kind can be used for the other ... ● modem (including fax; data over a voice service) ● voice etc over IP ● … but is often sub-optimal ● wasted bandwidth on modem links ● latency and dropped packets with VoIP ● Need one system that offers two services ● need better latency for conversations ● IoT will need dynamic data for control loops
Addressing ● Example: access to a service by name ● IP: use DNS to find IP address – IP address is then used for packet routing – problems with mobility etc ● FN: put service name in control message – reply includes a value which identifies the route ● format depends on the link technology for the first hop – client does not need to know location of server ● each network element only needs to know local part of route – rerouting, handover, etc are transparent
Fast set-up for asynchronous ● Synchronous flows require negotiation ● FN must not be slower than IP for web browsing ● HTTP typically uses many short TCP sessions ● addresses already in routing table after the first – for popular web sites, destination is there even for first ● return route cached as SYN packet forwarded ● FN has equivalent for connection-oriented ● connection to server is many-to-one ● return route set-up does not involve controller
Finding a route (1) ● Application sends request to local controller ● includes address (or other identification) of target – which may be service or content ● also includes globally-unique “call identifier” ● Multiple addressing schemes ● must support legacy schemes, e.g. IPv4, IPv6 – including URLs etc ● must allow new schemes to be added later – no change to routing logic required
Finding a route (2) ● Controller in each switch decides next hop ● topology discovery depends on the address scheme ● may simply flood request to all neighbours – loops easy to detect – not scalable to large networks ● controller checks required capacity is available – provided the switching technology supports it ● Labelling of packets depends on link technology ● route may pass over several different technologies
Recommend
More recommend
