AV-friendly networking. Cambridge, England

Transcription

1 AV-friendly networking Cambridge, England

2 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

3 To most people, network = IP It's cheap It's ubiquitous

4 To most people, network = IP It's cheap It's ubiquitous BUT is traditional IP good for AV? It's an IT system, and...

5 Media networks have requirements that IT folks don't understand

6

7 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

8 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

9 Flexilink history 1980s data network Video and audio over ATM ATM switch for BBC Radio 4 project (2004) Asynchronous Transfer Mode 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

10 Flexilink Proof-of-technology implementation

11 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

12 Flexilink main features Connection-oriented simplifies resource reservation clean separation between route-finding and forwarding and re-routing round failures 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 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

13 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,...

14 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

15 Flexilink standards Frame format based on AES51 AV and IT services specified in ISO TR signalling protocol: IEC also the recommended audio packet format inherited from AES47 / IEC Management protocols: other parts of IEC 62379

16 IEC 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

17 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

18 Links to drafts includes link to draft of also links to IEC drafts

19 Additional slides

20 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

21 Packets need address labels which can carry the full address or a reference number which is looked up in a separate data base

22 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

23 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

24 Switch structure controller (computer) routing table inputs logic control packets etc buffer memory scheduling logic outputs

25 Signalling controller ctl pkts routing table in scheduling buffer 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 out

26 Signalling controller ctl pkts routing table in scheduling buffer 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 out

27 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

28 Two kinds of flow Synchronous appropriate for dynamic data one-to-many as simple as possible, but not simpler 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

29 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

30 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 client does not need to know location of server format depends on the link technology for the first hop each network element only needs to know local part of route rerouting, handover, etc are transparent

31 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

32 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

33 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 controller checks required capacity is available loops easy to detect not scalable to large networks provided the switching technology supports it Labelling of packets depends on link technology route may pass over several different technologies

34 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

35 application presentation session control transport network MAC / link physical

36 Planes Control and management Signalling Forwarding

37 Communications technologies

38 Time-division multiplexing 6 7 F F 1 2 Small, fixed-size data units (1 byte in ISDN) Channel identified by position in frame Fixed-bandwidth channels no per-channel overheads unused capacity is wasted ITU-T and other standards 3 4

39 Connectionless packet switching idle idle headers headers data data idle headers data headers data 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)

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

41 FN / AVFIP / Flexilink M5 M2 M6 M2 framing M5 M2 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

42 FN / AVFIP / Flexilink 7 M5 M2 M6 3 M2 framing 4 M5 M2 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 idle supports route-caching for IP addresses Standards: ISO TR , IEC

43 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

44 Latency Telephony recommendation (one way) G 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) ms: max for ensemble Sample time: 20.8µs at 48kHz