Mar 17, 2016
It seems that the bird flu, which has a disproportionate number of people scrambling for grey market antibiotics and sterile facemasks (a rant that you can be sure I've been prepping for a while) is making financial and networking industry high ups wonder what would happen to the Net in the event of a real outbreak. Their reasoning seems simple enough: In the event of an outbreak of the avian flu that posed a serious threat to people in the US, many thousands would want to work from home to minimise their chances of being infected. However, it is also their reasoning that the Net would be completely swamped with people accessing sites like Youtube and Google Groups, which would use up all of the available bandwidth, and probably cripple essential services that use the Net for information transfer and access. Thus, they are calling for the curtailing and restriction of net.traffic if such a thing should happen.
I think that they're wrong, and that the matter isn't quite as simple as they make it out to be. First of all, this supposes that a majority of the systems on the Net (let's say, for the sake of discussion, half of them) start up continuous transfers of data, along the lines of downloading a couple of DVD-sized .iso images continually. Net.traffic doesn't normally work like that. Traffic on the Net these days can be roughly categorised in three ways:
- Short bursts of traffic with relatively long pauses in between (instant messages, SMTP traffic)
- Broadcasts limited to a single subnet (ARP requests)
- Long downloads that do not run 24x7x365 but finish (.iso images, downloading system updates)
(Obligatory disclaimer: That characterisation comes from my working as a network analyst in various environments for about eight years; I haven't been a network analyst for two or three years, so my UPG (unsubstantiated professional gnosis) very well could be out of date. Contact your local backbone provider's tier (n+3) staff for more information.)
As much as They'd like it to, the Net doesn't work like cable television: You click a link in your browser, something happens, that something stops happening and your link goes quiet. That frees up bandwidth that is used by other people on the Net. Even watching videos on Youtube, Google Video, Pornotube, et al work like this because your browser downloads as much of the video as it can and caches it; the download often finishes before the content is over.
Secondly, if you VPN in from home this greatly limits what you can and can't do on a particular workstation. The way that VPN client software works most of the time, all of your network traffic gets rerouted through the VPN connection. From a technical perspective, it's easier to do this than it is to set up multiple DNS server entries on the workstation and IP routes taht differentiate between traffic to the network at work (via the VPN virtual interface) and other kinds of traffic.. it's an all or nothing deal. Prudent VPN admins set up bandwidth throttling to keep the concentrator that you connect to from crashing under too much load, and when you set up a VPN connection and log into the work network, often your web browser and mail client (IE and Outlook) will configure themselves for whatever proxy servers are set up on the work net, which further limits what kind and how much net.traffic can be sent and recieved.
That reminds me - many ISPs set up their own web proxy servers that cache commonly accessed content (such as news sites...), which minimises traffic Out There.
On top of all of this, they're mischaracterising net.traffic during emergencies. Take, for example, 9/11: Most of the net.traffic wasn't people watching streaming videos or newscasts, it was e-mail traffic, instant messages, and people clicking the reload button while reading CNN, Fox News, and the big newspapers.