All times will be listed in Pacific Time.
The NANOG 64 Agenda icalendar feed is now available!
If you already have the app, you can search for NANOG 64 and download the guide to your mobile device!
As home networks see increasingly faster downstream throughput speeds, a natural question is whether users are benefiting from these faster speeds or simply facing performance bottlenecks in their own home networks. In this work, we study a simple question: Are users' downstream throughput bottlenecks in their home networks or in their access ISPs? Although our question is simple, answering it on a large-scale deployment is challenging because accurate measurements require instrumentation of a home router, which is too resource-constrained for many existing throughput analysis tools. In this work, we identify lightweight metrics that can accurately identify whether a throughput bottleneck lies inside or outside a user's home network and develop a detection algorithm that accurately locates these bottlenecks. We validate this algorithm in controlled settings and report on two deployments, one of which is the FCC deployment with 2,652 homes in the United States. We find that wireless bottlenecks are more common than access-link bottlenecks—particularly for home networks with downstream throughput greater than 20 Mbps, where access-link bottlenecks are relatively rare. In homes with a wireless bottleneck, it is equally likely that only one device experiences the bottleneck as it is for all devices to experience the wireless bottleneck simultaneously.
Home Network or Access Link?
Distributed network attacks, such as DDoS and BGP prefix hijacking can severely hurt online businesses and disrupt critical infrastructure services. The main challenge in handling such attacks is their distributed nature: the best locations to diagnose and mitigate them are often far from the victim's network. Today's Internet has no automated mechanism for victims to ask help of remote ISPs, and has low incentives for remote ISPs to offer such services. Consequently, prefix hijacking attacks go largely unmitigated, and victims of DDoS attacks pay exorbitant prices to large CDNs to distribute their contents and thus sustain the attacks. We propose SENSS, a programmable security service for the Internet. SENSS brings simple and generic programmable interfaces from SDN to inter-AS security. These interfaces can be easily implemented in today's ISPs; victims use them to observe and control their own traffic and routes in remote ISPs, and pay per use. We show how victims can leverage these simple interfaces to design solutions against many attacks. We provide six such custom programs that handle a variety of DDoS and BGP prefix hijacking attacks, many of which are not handled today. We evaluate SENSS through extensive simulations and prototype implementation, using realistic traffic and Internet topology, and show that it is very effective in sparse deployment (with adoption in 20 large ISPs, SENSS can eliminate 80-96\% DDoS attack traffic and correct 92--99\% of polluted ASes for BGP prefix hijacking), and it has low message overhead and delay.
Monitoring, managing and troubleshooting large scale networks. Almost four years ago I came to NANOG and mostly complained about the state of monitoring networks, par for the course for me. A lot has changed since then, we've solved many of the problems I addressed. Perhaps more importantly, we've fundamentally changed how we manage, monitor and troubleshoot our network. We plan to share what we learned, what went well, and best of all, what went oh so terribly wrong. Our driving philosophy behind this effort is that by taking an engineering approach to operations, you can greatly reduce the time to discover, mitigate and resolve issues on your network. We analyzed our faults, our pain points and the work that consumed most of our time. This allowed us to prioritize what we tackled first, we were surprised by what we learned caused the most outages, and how much impact minor network issues can have when they fall in the right place. From this, today, the majority of the faults that occur in our network are automatically detected, and mitigated all without human intervention. We'll dive into some of the most interesting issues we've experienced in our network, how we narrowed them down before, and after our new tooling and monitoring was deployed. We'll walk through specific examples of remediations and how the systems function. I'm lazy, I don't want to spend my time fixing known issues, I want to work on new problems, I want a challenge. This was the driving force behind our approach, if this sounds like you, them this talk is for you. ---- One of the keys to this effort was a system called FBAR, which interacts with our devices to perform the tasks needed to resolve issues. We'll explain in detail how this works, as well some of our earlier remediations. As a companion to this talk, David Swafford will be preparing a separate tutorial session to show you how to build your own system much like FBAR to help detect, isolate and remedy issues automatically.
Learn about how the Netflix Open Connect network evolved from the ground up.
The track will last 2 hours and be broken into four sections, a 30 minute presentation, a 30 minute panel discussion, a second 30 minute presentation, and 30 minute update and open mike discussion on Open-IX. The first presentation - "Moving Away from the Grid - Implementing Fuel Cell Technology for Data Centers" will be by Peter Gross, Vice President of Mission Critical Systems at Bloom Energy. The panel presentation - "When is N enough, Reducing Reliability in the Data Center" will be anchored by Jim Smith, Chief Technology Officer & Senior Vice President of Portfolio Operations for Digital Realty Trust. Lucy Yong of Huawei will present "Inter-AS Options for Network Virtualization Overlay." Data Center (DC) Network Virtualization Overlay (NVO) supports many tenant virtual networks in a DC with privacy and security properties. Some tenant virtual networks in a DC are required to interwork with BGP/MPLS WAN VPNs to provide end-to-end connectivity to tenant sites. Inter-AS options specified in [RFC4364] can be used between a DC NVO and BGP/MPLS WAN VPN. This presentation describes the inter-AS solutions for DC NVO and WAN VPN interworking that are being worked in IETF now and the solutions comparison. Gabe Cole will lead the Open-IX update will review progress this year, the data center evaluation tools that have been developed, complaint resolution process, and additional standards currently under consideration.
This tutorial will cover three different areas, Dense Wave Division Multiplexing, Packet Optical technology, and performance monitoring. This introduction of technologies will lead into a practical overview of methods to debug and troubleshoot optical networks, for both new and existing installations. Examples will include debug techniques for real-life issues and various solutions will be discussed.
Note: this is a single 3-hour session spanning two back-to-back tutorial slots. No coding / Python experience needed or assumed. Do you find yourself wanting to write a robot but not quite sure where to start? Ever find yourself typing the same set of commands on the CLI all day long? If so, this is the class for you! In this session, we'll focus on scripting in Python as a way to tackle a few common problems faced by all of us in the network world -- issues that typically steal your attention, but don't have to anymore. We'll take a practical approach to automating the humans and give you the foundation to go out and build your own version of Facebook's FBAR (https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920). This session will be targeted to the scripting n00b -- assuming no prior coding or Python knowledge. While we won't have time to cover a proper "Intro to Python", relevant syntax will be explained as we walk through the session and you'll be armed with the knowledge to go out and build! One tip! We will be working from a virtual machine of Ubuntu Desktop throughout the session. A copy will be distributed on USB sticks, but if you would prefer a direct link, please download DEVBOX01.zip from https://drive.google.com/folderview?id=0BweIzzj21fzEfllZbnJOQXoxbmIyeHJjS2VZWFY3ajBsMEZXZFBlTVhTTTFnQjJuWnhTM0k. This VM was built using Virtual Box and will open natively, but has also been tested / confirmed to work under VMware. VirtualBox is a free download available from https://www.virtualbox.org/wiki/Downloads.
Updates on status of current Appeals and BCOP Drafts. The Best Current Operational Practice (BCOP) project is collecting the best practices known within the operations community and capturing those practices in a series of documents. This is a community project and is open to all to participate and get involved. We welcome your participation and look forward to working together to build better documentation for the entire community. Join the conversation - Subscribe to the BCOP Mail List at http://mailman.nanog.org/mailman/listinfo/bcop Questions or suggestions about BCOP should be directed to bcop-support at mailman dot org.
Do you find yourself wanting to write a robot but not quite sure where to start? Ever find yourself typing the same set of commands on the CLI all day long? If so, this is the class for you! In this session, we'll focus on scripting in Python as a way to tackle a few common problems faced by all of us in the network world -- issues that typically steal your attention, but they don't have to anymore. We'll take a practical approach to automating the humans and give you the foundation to go out and build your own version of Facebook's FBAR. This session will be targeted to the scripting n00b -- assuming no prior coding or Python knowledge. While we won't have time to cover a proper "Intro to Python", relevant syntax will be explained as we walk through the session and you'll be armed with the knowledge to go out and build!
Use of IPv6 is gaining momentum. For some companies it is the primary IP version of choice to run their businesses and to deliver products and services to their customers. The depletion of globally routable IPv4 and private IPv4 address space has prompted many technology firms to look at the use of IPv6 while abandoning support for IPv4 in some parts of their networks. Additionally, and perhaps, more interestingly IPv6 has been rumored to outperform IPv4. New data is available from more diverse adopters that further substantiates these claims. Come hear the following as part of this panel: * Facebook will share information about their IPv6 only efforts including the data they are seeing comparing IPv4 and IPv6 performance. * Comcast will share how they are using IPv6 only for their next generating entertainment operating system as well as IPv6 differences compared to IPv4. * T-Mobile will share information about the deployment of IPv6 only across their mobile network which minimally includes lessons learned and techniques to ensure IPv4 content continues to be reachable. Other participants may be added in advance of the actual panel session. Akamai and LinkedIn have both been invited.
During last years much attention was paid for process of deploying IPv6 in different regions. And with growing IPv6 adoption the requirements also grew up. Today we require not just working IPv6 but reliable IPv6. Of course this aim brings to our attention IPv6 network latency which we want to be comparable to IPv4 latency. First measurements gave community very interesting and promising results – for some networks IPv6 was faster than IPv4. But why IPv6 had less latency – there was no clear evidence. In my report I'm going to discuss reasons why in some cases IPv6 is faster than IPv4 and why it is slower in other ones.
The Python library dubbed Napalm - short for Network Automation and Programmability Abstraction Layer with Multivendor support - helps interact with devices from various vendors though a unified set of commands. It currently supports Arista, Juniper, Cisco (IOS-XR) and FortiGate. It provides methods to replace or merge the configurations on the devices, view a diff, commit the changes, or roll them back. It also provides an Ansible plugin, which enables administrators to push configurations directly from Ansible playbooks. Napalm is open source and available on Github: https://github.com/spotify/napalm We will present more details about Napalm, how to use it and show in a demo how to instantaneously configure a set of multivendor devices.
Centralization seems to be the current "silver bullet" for network complexity — but will it really "solve" for complexity, or just bring us another round of "pushing complexity around?" This presentation considers an alternative view of the centralization/decentralization debate.
QUIC is a new transport protocol that runs on top of UDP. It is currently deployed to a significant fraction of Chrome users of Google services. It combines TCP-style congestion control, TLS-grade security, and HTTP/2 multiplexing. Our measurements on real-world traffic show that QUIC significantly decreases page load times and time between pauses in video playbacks. Google will continue scaling up the use of QUIC on the public internet over the next few months, with the goal of sending all Google traffic over QUIC. This talk will discuss how QUIC works, why it's an improvement over TCP, the problems we're anticipating as we deploy at scale, and what we're doing to prevent them.
In this talk, we share our work in creating an "IPv4 as a service" network overlay. We begin by suggesting there is value in building network infrastructure which is "lean" and "IPv6 focused". There is likely value in focusing on a lean FIB infrastructure and IPv6 focused functionality in our next-generation routing platforms. We performed traffic analysis on how IPv4 is being used in our network today. We found that 90% of the traffic in our fully routed backbone is done by %0.005 of the routes. 99% of the traffic is performed by 4.5% of the prefixes. This data suggests we can incrementally deploy an IPv4aaS solution. Our goal is to build an IPv4aaS using cloud infrastructure based on open source and home grown software. We then present an IPv4aaS built on top of LISP. While we use LISP encapsulation, we have decided not to use the LISP DDT "routing" mechanism. Our IPv4aaS overlay routing architecture must associate IPv4 prefixes with IPv6 next-hops. This isn't supported with "classic" BGP today. To solve this, we augmented JSON BGP IPv4 prefix updates with additional JSON information, namely an IPv6 next-hop. Effectively, we created a BGP IPv4 update with an IPv6 next-hop value. These messages are HTTP PUT to a route reflector / controller device, which processes the updates and applies associated business rules. These messages are then HTTP PUT to the overlay ingress (iTR) which announce a "default" to the underlay network. We then suggest the concepts in this presentation are an extension to the concepts we've made at the previous two June NANOG meetings.
Abstract Follows: The networking industry has made good progress in the last few years on developing programmable interfaces and protocols for the control plane to enable a more dynamic and efficient infrastructure. Despite this progress, some parts of networking risk being left behind, most notably network management and configuration. The state-of-the-art in network management remains relegated to proprietary device interfaces (e.g., CLIs), imperative, incremental configuration, and lack of meaningful abstractions. We propose a framework for network configuration guided by software-defined networking principles, with a focus on developing common models of network devices, and common languages to describe network structure and policies. We also propose a publish/subscribe framework for next generation network telemetry, focused on streaming structured data from network elements themselves.
The "whiteboard talk" represents one of the key ways that engineers can communicate ideas in a concise and educational way to colleagues. More than a classroom lecture or a slide presentation, a whiteboard talk is a combination of several disciplines including teaching, storytelling, the visual display of information, and improvisational acting. In this tutorial, the attendees will learn how to organize a whiteboard discussion, how to avoid popular pitfalls, and how to make sure that their audience walks away with the knowledge that the attendee wants them to have. These topics include how to narrow down the scope of a topic (both in terms of the topic itself and the level of abstraction), how to build the knowledge model for the talk, how to define terms for different audiences, and how to handle difficult audience members.
The early months of 2015 have seen an unprecedented level of action in the realm of U.S. cybersecurity policy. The Obama Administration, in response to a growing number of cybersecurity compromises and data breaches has announced an aggressive cybersecruity and data security agenda. The activity appears motivated at lease in part by the spike in the number of U.S. data breaches in 2014. The Cybersecurity agenda of the Obama Administration will have direct and indirect consequences for network operators potentially adding to their already substantial regulatory burdens. On top of these new obligations, the FCC adopted new open Internet rules that for the first regulate how data Internet service providers can utilize Consumer Proprietary Network Information (CPNI). That's a big deal to network operators who supplement revenue from user fees in a variety of ways by trafficking in user data. This presentation will educate the audience on the new rules and outline compliance strategies. About the Presenter: Ross A. Buntrock ([email protected]) is a partner at Arnall Golden Gregory LLP in Washington DC and is a member of the the Government and Regulatory, Litigation and Privacy and Consumer Regulatory practices. Mr. Buntrock is the leader of the Media, Technology, and Telecommunications industry teams. He has 20 years of experience representing all segments of the industry. He is nationally recognized for his work in communications, media, and technology law.
RSVP-TE is widely deployed. Over the years, various operationally challenging issues have emerged – both due to how RSVP-TE gets deployed and also how it has been implemented by various router vendors. This talk shall very briefly summarize the operationally-significant issues in deploying RSVP-TE at scale, from a perspective of: a. LSP configuration, b. Monitoring LSPs, c. Maximizing network utilization: Multi-path and load-balancing, d. Minimizing data losses during LSP re-optimization, e. Reducing network churn. Thereafter, the talk shall present mechanisms and recommendations to address each of the above operationally-challenging aspects.
Closing summary remarks from NANOG Executive Director and others. Detailed Agenda to be posted as the meeting time approaches.