NANOG Archives – The Broadcast Knowledge

Video: 5G QuickStart

Posted on 10th August 2020 by Russell Trafford-Jones

The best way to cut through the 5G hype is to understand the technology itself. This video explains the acronyms, frequency use, OpenRAN sites, multipath reception, software-defined radio.

Joe Hess starts this talk at NANOG 75 by telling us what 5G isn’t before covering the basics. He talks about NFV, Network Function Virtualisation, which is the ability to move any network function such as firewalls any load balancers into software running on a virtual environment. The flexibility that this provides is significant. Not only does NFV reduce the cost of launching new services and allowing that to happen quicker, all because no new hardware appliances need to be purchased and installed, it is also key to enabling ‘Network slicing’ which is a critical element to making 5G work for the broadcast industry. When you have virtualised the network functions, provisioning a totally new, separate, network can be done via API allowing a broadcaster to have their own cut of the network bandwidth but also have the security of total segregation.

Joe also highlights some other important technologies such as CUPS, which no longer stands for the Common UNIX Printing System, but rather Control and User Plane Separation. Part of CUPS is the ability to use polar codes to represent control data in the same datastream as general traffic. This creates a more robust control channel than the general data without having to create a separate channel. He also discusses the meaning of ‘NR’ or ‘New Radio’ which is a radio protocol replacing UMTS used in 3G and 4G’s LTE. It has the ability to be used on frequencies up to 6GHz and also on 24GHz and above, includes improved OFDM performance, and also run on top of an LTE core.

Please note the audio glitches you hear are on the recording and not due to your system

Joe makes the point that the 5G can run on ‘any’ frequency from 700MHz up and takes a look at the details. He also points out that there’s a lot of information in the press about 5G rollouts including by Telegeography

We next look at cRAN, vRAN and oRAN. cRAN (Cloud Radio Access Network) involves centralising control typically in the cloud. vRAN, Virtual RAN, allows you to choose who receives service from each tower allowing you to share a stadium’s-worth of subscribers or, say the people in a traffic jam, amongst a number of cell towers, not just the one which is closest to them or gives them the best reception. OpenRAN, such as the one just launched in Reading, UK which allows interoperability with open source software and the use of software defined radio.

MIMO is the next topic covered. Joe explains this isn’t new, but it is an important part of 5G. MIMO stands for Mulitple In, Multiple Out which is the ability to use multiple antennae at both ends to deal with the multi-path reflections on the received signal. In the last part of the talk, Joe speaks about mapping 5G deployments, tools you can use to analyse 5G.

Watch now!
Download the presentation
Speakers

Joe Hess
Hess Communications

Video: Intro into IPv6

Posted on 26th June 2020 by Russell Trafford-Jones

It’s certainly taken its time to get here, but IPv6 is increasingly used on the internet. Google now report that just under 30% of the traffic to Google is IPv6 and both Akamai and APNIC show UK IPv6 readiness at around 30% with the US around 50%. Deployment within most enterprise environments, however, is often non existant with many products in the broadcast sector not supporting it at all.

Alex Latzko is an IPv6 evangelist and stands before us to introduce those who are IPv4 savvy to IPv6. For those of us who learnt it once, this is an accessible refresher. Those new to the topic will be able to follow, too, if they have a decent grasp of IPv4. Depending on where you are in the broadcast chain, the impetus to understand IPv6 may be strong, so grab your copy of the slides and let’s watch.

There are no broadcast addresses in IPv6
Alex Latzko

Alex, from ServerCentral Turing Group starts by explaining IPv6 addresses. Familiar to some as a far-too-long mix of hexadecimal numbers and colons, Alex says this is a benefit given the vast range of numbers possible allowing much more flexibility in the way we use the IPv6 address space over IPv4. He takes us through the meanings of the addresses starting with well-known tricks like abbreviating runs of zeros with a double colon, but less well-known ones too, like how to embed IPv4 addresses within an IPv6 address as well as the prefixes for multicast traffic. Alex goes on to show the importance of MAC addresses in IPv6. EUI-64 is a building block used for IPv6 functions which creates a 64-bit string from the 48-bit MAC address. This then allows us to create the important ‘link local’ address.

The last half of the presentation starts with a look at the CIDR prefix lengths that are in use and, is some cases, agreed as standards on the internet at large and in customer networks. For instance, internet routing works on blocks of /48 or larger. Within customer networks, blocks are often /64.

In IPv6, ARP is no longer. ARP can’t work because it uses broadcast addresses which don’t exist within the IPV6 world. This gives rise to the Neighbour Discovery Protocol which allows you to do something very similar. Specifically, it allows you to find your neighbours, routers, detect duplicate addresses and more.

Alex covers whether ‘NAT’ is possible in IPv6 and then looks at how routing works. Starting by imploring us to use ‘proper hierarchy’, he explains that there is no need to conserve IPv6 space. In terms of routing, the landscape is varied in terms of protocols to use. RIP is out of the window, as v1 and v2 have no knowledge of IPv6, OPSFv3 is a beacon of hope, though deployment is often in parallel with the IPv6-ignorant OSPFv2. The good news is that IS-IS, as well as BGP, are perfectly happy with either.

Watch now!
Download the presentation

Speaker

Alex Latzko
Lead Network Architect
ServerCentral Turing Group

Video: Buffer Sizing and Video QoE Measurements at Netflix

Posted on 20th March 2020 by Russell Trafford-Jones

At a time when Netflix is cutting streaming quality to reduce bandwidth, we take a look at the work that’s gone into optimising latency within the switch at ISPs which was surprisingly high.

Bruce Spang interned at Netflix and studied the phenomenon of unexpected latency variation within the netflix caches they deploy at ISPs to reduce latency and bandwidth usage. He starts by introducing us to the TCP buffering models looking at how they work and what they are trying to achieve with the aim of identifying how big it is supposed to be. The reason this is important is that if it’s a big buffer, you may find that data takes a long time to leave the buffer when it gets full, thus adding latency to the packets as they travel through. Too small, of course, and packets have to be dropped. This creates more rebuffing which impacts the ABR choice leading to lower quality.

Bruce was part of an experiment that studied whether the buffer model in use behaved as expected and whist he found that it did most of the time, he did find that video performance varied which was undesirable. To explain this, he details the testing they did and the finding that congestion, as you would expect, increases latency more during a congested time. Moreover, he showed that a 500MB had more latency than 50MB.

To explain the unexplained behaviour such as long-tail content having lower latency than popular content, Bruce explains how he looked under the hood of the router to see how VOQs are used to create queues of traffic and how they work. Seeing the relatively simply logic behind the system, Bruce talks about the results they’ve achieved working with the vendor to improve the buffering logic.

Watch now!
Speakers

Bruce Spang
PhD Student, Stanford

Video: SNMP is Dead

Posted on 24th January 2019 by Russell Trafford-Jones

SNMP has long been widely used in the broadcast industry and is a great example of the industry using a technology which is there but has never quite satisfied all the needs not least security. Here, Rob Shakir and Carl Lebsack from Google explain their dissatisfaction with SNMP and tell of the system, gRPC, Google has written and implemented in response to stream telemetry at a high frequency. As larger facilities move to uncompressed essences over IP, this should solve a number of issues for the broadcast industry.

This talk given at NANOG 73 covers: