AV-friendly networking Cambridge, England www.ninetiles.com - - PowerPoint PPT Presentation

Cambridge, England www.ninetiles.com

AV-friendly networking

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

• 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

Links to drafts

Additional slides

Wikipedia page on “TCP delayed acknowledgment”

“The socket level tries to guess what the application level is doing, in order to manage communications efficiently.

Often it guesses wrong.”

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) routing table buffer memory inputs

• utputs

control packets etc

logic logic logic logic scheduling

Signalling

• 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 controller

routing table

buffer in

• ut

ctl pkts

scheduling

Signalling

• 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 controller

routing table

buffer in

• ut

ctl pkts

scheduling

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  packets sent at regular intervals  QoS guarantees (if supported by lower layers)

 Asynchronous

 appropriate for static data  one-to-one or many-to-one  best-effort service

as simple as possible, but not simpler

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

Typical AV functions

• One-way (e.g. listening to radio)
• regular flow of data
• can buffer before rendering if data arrives in bursts
• similar to file transfer, with many small media files
• Two-way (e.g. conversation; in-ear monitors)
• buffering increases latency
• timeliness more important than bit-perfect accuracy

application presentation session transport network MAC / link physical

control

Planes

Control and management Forwarding Signalling

Communications technologies

Time-division multiplexing

• Small, fixed-size data units (1 byte in ISDN)
• Channel identified by position in frame
• no per-channel overheads
• Fixed-bandwidth channels
• unused capacity is wasted
• ITU-T and other standards

F 2 1 3 5 4 6 7 6 7 F 2 3 4 1

Connectionless packet switching

• Packets are quite large (Ethernet min 64 bytes)
• Destination identified by address in header
• globally-significant → high overheads
• in many systems, a header for each layer
• Bandwidth-on-demand
• “best-effort” service
• Standards: IETF (RFCs, L3) and IEEE 802 (L1,2)

idle headers data idle headers data idle headers data headers data

Asynchronous Transfer Mode

• Fixed-size data units (48 bytes payload)
• Channel identified by label in header
• locally-significant → low overheads
• Bandwidth (or best-effort) negotiated per channel
• unused capacity can be used by others
• Standards: ATM Forum, ITU-T

5 E 2 6 6

FN / AVFIP / Flexilink

• Small, variable-sized data units for media traffic
• channel identified by position in frame

– very low overheads

• connection-oriented service

– per-flow reservation of bandwidth M5 M6 M2 M2 M5 M2 framing

FN / AVFIP / Flexilink

• Ethernet-sized data units for best-effort traffic
• occupy all the space not used for media flows
• channel identified by label in header
• locally-significant → low overheads
• many-to-one “quasi-connectionless” option

– supports route-caching for IP addresses

• Standards: ISO TR 29181-3, IEC 62379-5-2

M5 M6 idle 3 7 M2 M2 4 M5 M2 framing

Latency

• In the analogue days ...
• sound in air: 1 ms / ft (0.3 m)
• electrical signals: 1 ms / 160 to 300 km
• any other delay needs magnetic tape

Latency

• Telephony recommendation (one way) G.114
• 25 ms: max without echo cancellation
• 150 ms: max for comfortable conversation
• 400 ms: max for “network planning”
• Musicians
• 10 ms: max with in-ear monitor for most instruments

– typically includes two transits across the network

(source: Lester & Boley, Convention Paper 7198)

• 20-25 ms: max for ensemble
• Sample time: 20.8µs at 48kHz