net-neutrality-im-for-and-against

Net Neutrality has become almost a battle ground in the States; the FCC is trying to take more control over the web and the relationship between ISPs and their customers, while the ISPs themselves are more interested in seeing if they can charge at both ends of the pipe. Through all of this, both sides are arguing the case, but with Ofcom now opening the debate here in the UK, I believe there are some causes for concern.

Before I break down the finer points one item should be abundantly clear – I pay for access to the Internet. All of it (baring a few legal and political issues can be bypassed should I not agree for whatever reason).

I do not expect an ISP to select for me content which would be ‘in my benefit’ to access at a better rate at the expense of another (for example, 4OD verses BBC iPlayer). I do expect every site, every company and every commercial venture (new, mature or otherwise) to be treated equally and independently, and to be fully available when I choose to use and access it.

Therefore I absolutely disagree with some of the tactics being brought around by the larger ISPs in the USA. Namely the ‘demanding’ of money from companies/sites such as Google, YouTube or Facebook to compensate them for what they claim is ‘free’ access to their networks, or the charging for preferential access to their customer’s bandwidth. This completely ignores the fact the customers are paying them to transport the data across their networks for their personal consumption and therefore is just greed.

Net Neutrality for me is the prevention of this from happening: Regulating all ISPs to simply manage the transport of data without limitations for the benefit of any commercial, political or other influence.

What I do disagree with is the aspect of it where ‘all packets are equal unto the Router‘.

There’s no point in trying to argue that everything is equal. To say this is to say that all vehicles are made equal – they all have engines, wheels and lights. Yet a car cannot do what a lorry can.

A lorry is great at carrying 40-tons of goods from point A to point B, but although they probably can do it at 70 to 80mph, for our safety were happy for them to be limited to 60mph (at 70mph, a lorry will have 36% more kinetic energy than at 60mph, and 77% more at 80mph!). It may take them a little longer, but it will still get there; the roads will be safer and through limiting their speed, their actions more predictable allowing us to move in & out between them.

The same can be said for different protocols.

I use SSH a lot, for example, in managing servers or remote access to my desktop (especially when combined with SCP). The characters that appear on screen are sent by the remote server and do not appear in reaction to the input at the client end. For a something to appear on my local screen, each letter (or groups of letters if typed quickly enough) will be sent to the server with a returning command returned to tell the client how to change the display.

These packets are generally small and light, but a small slowdown here has a big significance on the ability of the client to interact with the server.

However, SMTP (the protocol used to send e-mails) is usually made up of full-sized packets which are sent in bursts. Taking 4 or 5 seconds to send an e-mail instead of 3 seconds at ‘full speed’ is neither here nor there and (with most clients sending e-mails in the background) is not something you would probably notice.

Based on this example, it’s safe to say that SSH would have a more urgent need over SMTP and therefore should be prioritised accordingly.

This could be taken further into multiple stages. For example, on my home router I have it configured that the first part of a stream (say up to 1Mb) has higher priority that larger packets or beyond 1Mb.

On a normal console, it would be very difficult to transfer approx. one-million characters to the server. Therefore it would be a good assumption that anything over 1Mb would be a file being uploaded through SSH (using SCP) to the server and therefore not an interactive session requiring the highest priority. (Sometimes it is nice to have this fine-grained control).

Beyond all this however is the greatly improved experience of the Internet without detriment to other users or protocols. It’s also important to note that this isn’t throttling – by prioritising packets only, everything is free to flow at the maximum rate, but on occasions when two streams are competing for bandwidth it may be of benefit to allow one’s stream the ability to occasionally jump it’s packets before another’s to improve latency.

Therefore the ‘throttling’ of, for example, P2P protocols so they are always slow to access is not prioritising and is influence on a commercial or other (internal) level, and it’s this importance in distinction, combined with the policies of improving (or restricting access) based on charges that should be avoided (and even regulated against) at all costs.

So:

• NO to influence over streams for commercial, or other, gain;
• YES to the ability to prioritise of packets to improve latency and experience for all users; and
• NO to the throttling of selected protocols or streams to control access or manage overall experience.

When the time comes, we must all make our voices heard on this…