"I'll put my phone on charge. Oh dear the charger is in my hotel room".

You just know how this will end.

I've been specifying emergency service systems for over 10 years, duplication, monitoring, management and processes are always at the top of the list.

I'm not convinced you need an analogue failover but you do need fully duplicated systems right down to the power subsystems and cables which you periodically switch between. There is no point having a backup if you don't use it on a regular schedule to be sure it is working properly.

The solutions are not all technical, you have to be monitoring them properly with the right people who are motivated and properly trained. You also need the proper organisational processes .

I've seen NOCs on emergency service networks where the staff on duty have been asleep or out of the room for long periods. Motivation, training and accountability are frequently not given the importance that they deserve.

If calls are lost then help is delayed. This impacts the outcome of incidents.

I'm not saying that people died because of this but I'm absolutely certain that there were some who suffered worse injury and losses because of the delays. Loss of 6,000 calls will result in a lot of hurt.

Like so many other issues, it wasn't a single fault but a chain of events. In this case there was a software failure but the fault monitoring systems and support services failed to immediately note that there were no calls going through the affected systems. A change from 1,000 calls per hour to zero should be pretty obvious.

They didn't appear to have a credible mitigation process to handle this sort of failure like diverting calls to another location. This could have been automated or manually initiated by the NOC operators.

Shit happens in all systems, the important thing is how you deal with problems.

By Saudi Arabia, UAE, Oman etc. in the same way as Skype is.

I predict screaming from millions of users who find WhatsApp suddenly blocked by their ISPs.
 

Now IBM have dumped their X86 server busness onto Lenovo it looks like Lenovo might be the the best option for new deployments. At least you can (still) download patches from their website.

Another option would be Huawei, but I don't know what their support is like. At least you can be certain that the spyware on their products is coming from the NSA!

This is the sort of action you would expect from some small dictator-run country not one of the biggest countries in the world.

If you combine it with the arguments on funding which has resulted in the government effectively shutting down for the last few days and the absolute fortune being spent on making the Internet a less secure place (AKA NSA spying on everyone) then you end up with a picture of a country where the government organisations are completely out of the control of those who are supposed to set the rules.

This is not acceptable in a connected world. The spying is particularly galling, (I know GCHQ are up to their necks too) but I EXPECT that individuals not carrying USA passports should have some rights - if only the human right to privacy unless there are overriding needs in individual cases/investigations. This wholesale hoovering up of my data is plain wrong. The outright lying of some of the senior agency staff to oversight committees and FISA courts is completely unacceptable and should lead to long prison sentences, but it won't and another nail is hammered into the USA state coffin.

So I'm now generally avoiding products, hardware and software designed and manufactured in the USA - not hard anyway considering the collapse in manufacturing there and outsourcing to China of most of the supply chain.

  My recommendation for the last couple of years to clients has been to avoid Cisco and Juniper etc at the Internet gateway or areas with uncontrolled traffic and shove something else (preferably open source/IPTables based) there and review the rules very carefully. The recent news has just strengthened my view that you can't trust hardware where you can't arrange for an independent and public review of the code - IMO in general the threat of a public disclosure of a back door or designed-in weakness from a code review is sufficient to keep the vendor honest. The recent news has just reinforced my views.

Andy

Forgot to add that your VPN endpoint doesn't have to be where the VSAT or Thuraya earth station drops the traffic to the internet. You can tunnel through the Internet back to the USA and present your traffic wherever you want. Round trip delays will prevent you from going multihop satellite even if you can afford it.

Finally make sure you speak to the vendors of the VSAT/Thuraya terminals. Most VPNs don't play nicely with satellite links because of varying throughput and delays and if you are using VSAT you need an adaptive modem to squeeze all you can out of your little bit of spectrum.

Usual names apply, Astrium etc. if you want certified implementations.

Andy

In the middle east region you should consider the Thuraya IP service as it is the cheapest offering and aimed at providing Internet to communities in areas where there is little or no backhaul. It will still cost a lot though (If it remember correctly around $100/GByte). The Thuraya IP service package has 30GB/month with topups in lumps of 30GB/Month.

If you can commit to a long term contract (1 to 3 years) a better choice would be with Ku band VSAT which can work out as low as $2k-$4k/month per
megabit.

I had to research this recently.

Andy

After a long time using standard PCs in the home for development I've finally splashed out on a HP DL160 G6.

I've done this because I'm fed up with replacing power supplies, fans and running out of motherboard memory capacity. In my experience the HP rackmount servers (almost) never break down and you can stuff serious amounts of memory into them (the DL160 G6 has 18 SIMM sockets). My server spec is 2 x quad core cpu + 4 x 3.5 inch disks + 40GB RAM. Paid about GBP 1000 for the server (second user) off EBAY then added 32GB RAM. Its a good deal if you compare it with a standard size motherboard which can take that sort of memory and a pair of CPUs and you add in the cost of a good case and power supply.

With a good server you can concentrate on virtulisation and your testing and be not forever repairing things. Quality always pays off in the long term.

Andy

Wonder how many operators of TOR exit nodes will be getting a visit.

There is no way the wallet will disappear until there is a universal service obligation on Paypal and other means of payment. Such an obligation will heavily penalise electronic payment providers if they withdraw service from specific users or their networks fail to deliver a reliable service.

Cash is reliable - that is why people use it. Nobody can stop me using cash to get things I need. Look what has happened to Wikileaks when certain US Governement people had a chat with Visa and Mastercard.

E-Cash might be a way around the control issue. BitCoin is interesting but has a few issues with scaling and anonymity - its pretty good though. The next iterations of E-Cash will draw heavily on the techniques of BitCoin and I'm sure will avoid a lot of the issues.

Andy

Most delays are due to users connecting to their ADSL modem via Ethernet and not traffic managing properly.

On a congested link this can cause large delays as Ethernet normally has a 1000 packet buffer in the Linux kernel and the ADSL modem has a similar buffer. You only need a couple of heavy connections which want to go faster than the ADSL will support and those buffers start to fill up real fast. You can easily end up with latencies measured in seconds if you have a lot of connections running (say bittorrent).

There are several solutions to this but the best in my experience is to change the queuing discipline to SFQ and rate limit using HTB. This has been in the kernel for years and works extremely well. You need to limit the traffic upstream and downstream to slightly less (5% less) than the ADSL link speed. This ensures that the modem never queues traffic. Uplink you can use all sorts of fancy queuing but downlink all you can really do is policing of traffic unless you install the IMQ patch to the kernel.

I've a script which I got from somewhere a while ago, don't remember where though. I've put it at http://ams1.x31.com/~andy/ppp0-ratelimit.sh if anyone wants to look at it. It expects to work on ppp0 but can be adapted as required.

I've played a lot more recently with Linux kernel disciplines and it has produced surprising performance on congested links. One link is running mail, remote access and Internet access over a 1mbit symmetric link for about 60 users. in the morning it hits 95% link capacity at the start of work and stays there until everyone goes home but ssh sessions are fully interactive without noticeable lag all this time. Yes web browsing is a little slow but it is the same for everyone and one user can't flood the link and upset everyone else.

Linux QOS is the future, pity about the documentation

What the USA makes its ISPs do is an internal matter. Pressuring registrars to kill domains is another. Grey market and fake pharmaceuticals is one thing but when you get into matters of opinion and national ethics then it is something completely different. At least ICANN stayed away, however they are still under the influence of the USA courts and the Whitehouse - look at the farce about the XXX TLD.

I'm not a great fan of the ITU as it is slow and cumbersome but I do feel that ICANN, IANA and the rest should be moved under their control. The Internet doesn't belong to any single country regardless of who came up with the original protocols. This is preferable to having multiple organisations running different root servers which can lead to the same URL being resolved to different IP addresses.

Andy
Doha, Qatar

I've had a freecom Internet Radio[1] for about 2 years now which cost about $100 (GBP 60).

Its a flexible unit with WLAN, Ethernet etc.

Andy

[1] http://www.freecom.com/product.asp?CatID=1148017