IoT Links Feb-2015

This student paper gives a pretty decent lay of the land.
https://sites.google.com/a/cortland.edu/the-internet-of-things/summary

Cisco's 2011 whitepaper framed things up nicely and is still very relevant.
www.cisco.com/web/.../IoT_IBSG_0411FINAL.pdf

Ecobee, Lyric, and Nest...oh my!
http://smartthermostatguide.com/

Big Data, analytics, and finding value in Internet of things.
http://www.networkworld.com/article/2889975/careers/future-proof-your-it-career-8-tech-areas-that-will-still-be-hot-in-2020.html

Sensor technology will be all the difference for IoT
http://www.forbes.com/sites/tjmccue/2015/02/24/a-butterfly-wing-inspired-sensor-may-save-your-life/

Always wanted my cell phone mic right inside my mouth!
https://wtvox.com/2014/10/top-10-implantable-wearables-soon-body/

Regional leadership in IPv6

Network World claims "The US is overtaking the world on IPv6" , but I'm not entirely convinced.

Seems like when the numbers can support the claim such as overall traffic, North America vs. all of Asia numbers are shown.  When it's a bit closer, such as in number of addresses or vendor support the numbers are broken down by country to show the US is slightly ahead of China but not all of Asia.

It's nice to see that North America is no longer ignoring the protocol and the future of the Internet.  Now let's see how we are doing in percentage of bandwidth and percentage of total users!

SSL and TLS - What do browsers use to encrypt?

I'll spare you all the gory details you can read on wikipedia, but these are protocols used to encrypt data exchanged by browsers and web servers for keeping information private and unchanged.  Secure Sockets Layer (SSL) has been through versions 1, 2, and 3.  All by 1996 !   Transport Layer Security (TLS) was released as version 1.0 in 1999.  (Also a !).

You may often see references to SSL3/TLS1.0 because "TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security."

TLS1.1 was defined in 2006.   TLS1.2 was defined in 2008.  As of 2012, IE9 appears to be the only major browser to support it.

In his great BlackHat 2010 presentation, Ivan Ristic presents great statistics on server support for these protocols discovered during surveying:

nping, a ping for more protocols

Nping is really handy when you suspect that ping or traceroute aren't giving you clear results.  I really like it for a TCP Connect to a website:


$ nping --tcp-connect -c 3 --delay 2s www.google.com

Starting Nping 0.6.01 ( http://nmap.org/nping ) at 2012-08-13 12:09 MDT
SENT (0.0067s) Starting TCP Handshake > www.google.com:80 (74.125.225.176:80)
RECV (0.0209s) Handshake with www.google.com:80 (74.125.225.176:80) completed
SENT (2.0086s) Starting TCP Handshake > www.google.com:80 (74.125.225.176:80)
RECV (2.0250s) Handshake with www.google.com:80 (74.125.225.176:80) completed
SENT (4.0113s) Starting TCP Handshake > www.google.com:80 (74.125.225.176:80)
RECV (4.0244s) Handshake with www.google.com:80 (74.125.225.176:80) completed

Max rtt: 16.390ms | Min rtt: 13.108ms | Avg rtt: 14.507ms
TCP connection attempts: 3 | Successful connections: 3 | Failed: 0 (0.00%)
Tx time: 4.00581s | Tx bytes/s: 59.91 | Tx pkts/s: 0.75
Rx time: 4.01892s | Rx bytes/s: 29.86 | Rx pkts/s: 0.75
Nping done: 1 IP address pinged in 4.02 seconds

You can also scan MAC addresses on your local subnet:


 $ sudo nping --arp-type ARP 172.16.16.1-10 --count 1

SENT (4.8530s) ARP who has 172.16.16.1? Tell 172.16.16.11

RCVD (4.8546s) ARP reply 172.16.16.1 is at 1C:DF:DF:53:91:91

SENT (5.8538s) ARP who has 172.16.16.2? Tell 172.16.16.11

RCVD (5.8548s) ARP reply 172.16.16.2 is at 00:26:9F:37:33:33

SENT (6.8556s) ARP who has 172.16.16.3? Tell 172.16.16.11

RCVD (6.9364s) ARP reply 172.16.16.3 is at A4:EF:57:E3:EA:EA

SENT (7.8575s) ARP who has 172.16.16.4? Tell 172.16.16.11

SENT (8.8582s) ARP who has 172.16.16.5? Tell 172.16.16.11

SENT (9.8587s) ARP who has 172.16.16.6? Tell 172.16.16.11

SENT (10.8600s) ARP who has 172.16.16.7? Tell 172.16.16.11

SENT (11.8612s) ARP who has 172.16.16.8? Tell 172.16.16.11

SENT (12.8621s) ARP who has 172.16.16.9? Tell 172.16.16.11

RCVD (12.8656s) ARP reply 172.16.16.9 is at 00:21:CF:BD:1F:1F

SENT (13.8634s) ARP who has 172.16.16.10? Tell 172.16.16.11

Raw packets sent: 10 (420B) | Rcvd: 4 (184B) | Lost: 6 (60.00%)
Tx time: 9.01162s | Tx bytes/s: 46.61 | Tx pkts/s: 1.11
Rx time: 10.01221s | Rx bytes/s: 18.38 | Rx pkts/s: 0.40
Nping done: 10 IP addresses pinged in 14.86 seconds

Integrating routing with CDN

A content delivery network (CDN) is a large distributed system of servers deployed in multiple data centers in the Internet.[citation needed] The goal of a CDN is to serve content to end-users with high availability and high performance.


Uniform Resource Identifier (URI) is a string of characters used to identify a name or a resource on the Internet. - en.wikipedia.org/wiki/URI


Border Gateway Protocol (BGP) is the protocol which is the core routing decisions on the Internet. It maintains a table of IP networks or 'prefixes' which designate network reach-ability - en.wikipedia.org/wiki/BGP

The multiprotocol extensions of BGP has been used to carry many types of information.  I stumbled across a great progression on the idea from this NANOG presentation from the guys at Comcast.


Here's their packet capture screenshot.  Notice the Address Family -  URI.

IPv1 , v2, and v3

I always hear "What happened to IP version 5?" But we've seen the answer many times.  "Some experimental testing version".

While reading Charles Kozierok's excellent TCP/IP Guide, I found the history of why IPv4 was actually the first version of IP as in a Layer 3 on it's own.  The addressing layer was part of the original Network Control Program and then Transmission Control Program combined into a single Layer3 and 4 functionality.   TCP became Transmission Control Protocol by its 'fourth iteration'.

Why hasn't networking followed Moore's Law ?

Andy Bechtolsheim's keynote at NANOG55 in Vancouver looks into what's been going on with networking versus Moore's Law:

Follow the link to his slides in PDF.  There are some fantastic graphs on:

1. Server 10/40/100G Adoption Cycle
2. Total Datacenter Switch Revenue by Protocol & Speed

Today's custom switch silicon support 64 10G ports on a single chip but forecast to scale by 4X in the next 3 years.  He wraps up the presentation looking into ways to alleviate the current high cost of optics slowing down 40G/100G adoption.

IPv6 Day

Early today, major web sites enabled their DNS 'quad A' or AAAA entries.

These include google.com, bing.com, facebook.com, yahoo.com, youtube.com and aol.com.

I especially like Facebook's IPv6 address:

2A03:2880:2110:3F03:FACE:B00C::

It looks like traffic to Google over one backbone immediately doubled... Albeit up to almost 2% of total traffic.

I'm told that unlike last year, these updates are planned to be permanent. Sure is a step in the right direction!

A Brief History of SDN

Software Defined Networking is a new and exciting development in networking.  However, it's been a long time coming:

1985    IGRP  planned to take into count metrics beyond hop count to include reliability and load

1991    OSPF  specified calculating paths to deliver better throughput, lower latency, etc.  John Moy's excellent book remains one of my very favorites.

1996    Cisco Policy Based Routing was introduced with IOS 11.0 and "provides a flexible mechanism for network administrators to customize the operation of the routing table and the flow of traffic within their networks."

2006    Cisco OER  became PfR sometime around 2010.  It allows the traffic forwarding decision to be based on delay, packet loss, and link loading.  Arguably the closest precursor to SDN (at least from Cisco) in that it has a 'separation of control plane', 'a centralized controller' and possibly 'programmability by external applications.

Please send me other examples!

Slow TCP but no packet loss

Many times I've heard the claim "out-of-order packets" wreak havoc with your application.  Many interpretations conclude that must be because of poor application coding.  Blaming others can flow both ways, it seems.  My favorite comment in all threads about Duplicate ACKs and Fast Retransmit concludes with " how the network performance is improved by a server reboot. "

Back to our main concern here.  When a receiver gets TCP datagrams 1,2,3 and 5 it will immediately send an ACK expecting 4 as it already did to confirm receipt of datagram 3.  Ding.  First 'duplicate ACK'.

Now, listen closely as I don't plan to get in this habit.  The RFC for TCP Congestion Control is a moderately pain-free read and gives the authoritative fundamentals on how TCP should behave.  Give it a look!

The key to dig out is somewhere around page 6.  Duplicate ACKs cause sender to reduce window size.  The whole mechanism and scenarios for SLOWING down transmission rates of the TCP flow are detailed.

MORAL:  nothing has to be lost and TCP can still determine congestion has been encountered and slow down.  Sometimes significantly.  Also came across these great course slides.

Two missing but vital Cisco Nexus vPC commands

So you come across a pair of Nexus 5548 switches and dive right into setting up a Virtual PortChannel following the configuration guides.  You'll wind up with something like this:

Things go swimmingly!  That is until you want to upgrade or have to power cycle one of the switches.  Your server can't get anywhere nor be reached for quite a few seconds.  Odd, you think.  Surely frames can happily flow along the remaining active link.  Isn't that what vPC is for?  As one switch comes back online, you then get ANOTHER period of lost connection to your server.

TCP Throughput across the Internet

After reading Brad Hedlund's excellent overview and digging into the great tools at SWITCH, I ran some quick numbers for what transfers might see across the Internet.

First, taking low packet loss of 0.01% and checking across various delays from 5 to 60ms, I get:

Then, using 60 ms as a rather normal round-trip time (RTT) across the Internet, I tried values for packet loss increasing to a very normal 0.1% :

Looks like it's pretty hard to fill that 25Mbps DSL.  In the future, I will look at tuning options for improving that.  Comments welcome!

Response Time Composition

Waaaay back in 2006, I used a network monitoring appliance from Network Physics whom I'd lost touch with.  It delivered this graph that quickly became my best friend:

One glance at the Response Time Composition and I could see what had changed from a baseline.  I could also see where to dig in further as to the cause of reported 'slowness'. Of course it was never the network and quite often the server or sheer massiveness of application chattiness.

I'm pleased to say my old friend lives on and has been seriously enhanced by the folks at OPNET in their AppResponse Xpert tool.  Even more super-cool is the SaaS edition that fires up right in your #cloud -running application via a sweet bit of JavaScript.