Accepting Less Than 99.999% Uptime

The Standard has a good writeup on how we accept less than stellar uptime for things that are becoming more and more valuable such as broadband.

Phone service is reliable because it’s mandated to be. There’s pretty strict rules regarding uptime. As a result it’s pretty good. The reason for this is that phones are used for emergencies (911). But what about VoIP?

It makes you wonder why broadband access isn’t being held to these standards. Of course the answer is “money”. But should it be changed? Should ISP’s need to ensure connectivity is as reliable as old POTS lines? I suspect for people to ditch POTS, it will need to be.

I wonder if FiOS is held to the same 99.999% uptime requirements when it’s run by the phone company, and used for VoIP. I doubt it, but I’m not sure.

I suspect reliability of broadband will become more of an issue as VoIP interest increases in the next 18-24 months and larger players like Verizon and Comcast start pushing it to even more homes.

Upload Bandwidth

I’ve moaned before about the lack of good upload bandwidth despite having rather decent download speeds. Comcast’s new PowerBoost for upload took effect this week, giving a burst of about 1Mbps for uploads for the first part. While this doesn’t quite fix the problem with making remote backups, it does help in some cases.

Hopefully DOCSIS 3.0 or FIOS will come around.

Early Morning Bandwidth

It’s well known cable modems are “shared bandwidth”, meaning if everyone on your neighborhood is downloading Paris Hiltons latest video off the net (ahem… her music video), your connection slows down. Well Comcast’s feature for the past several month allows you to briefly use the excess bandwidth when it’s quiet. So what does it look like at 1:30 AM?

Bandwidth

During peak hours it’s really not that much worse. Typically between 7000kbps – 14000kbps. Not to bad. Of course Verizon will eventually roll out 15Mbps sustained with 2Mbps upstream. Comcast just announced “speedburst” for upstream, and it doesn’t really compare to Verizon’s Fiber offering. DOCSIS 3.0 can’t come quick enough.

Take that 56k dialup!

Site Backups And Bandwidth Fun

I keep regular backups of everything on this server just in case something happens. Recently I switched to a more automated and secure (PGP encrypted) solution for this blog due to it’s fast-paced nature. Just the critical stuff (database, media, templates). I choose PGP (implemented using GPG) since it’s easy, and I only have to store the public key on the server, making it safer than most alternatives.

I’m strongly considering moving it all eventually over to Amazon’s S3 storage. At $0.15 per GB-Month of storage used and $0.20 per GB of data transferred it would be very affordable to keep backups in an even more secure fashion. I’d still use my own encryption on top of theirs for extra security. For things like media, I could even see myself hosting it solely at Amazon. It just seems like that may be a more practical and scalable approach.

Unfortunately until either FTTH or DOCSIS 3.0 comes to town, it doesn’t look like Amazon’s S3 will be practical for home backup purposes. This server has a beefy connection to a few large pipes to the internet (Level3, Global Crossing, and Cogent last I checked). They provides high speed connectivity so a backup would take only a few seconds. At home with a cable modem on a DOCSIS 1.1 network (such as Comcast) the bandwidth is just to slim to allow enough upload capacity. Comcast still only allows 384kbps up. Even the top plans in select areas don’t top 1Mbps. Of course these are Comcast’s numbers (the actual performance is often less). In areas that they currently serve, Verizon FiOS (FTTH) is available at 15 Mbps/2 Mbps. Much better suited for such purposes (though more would be welcome). As strange as it may seem pricing is quite competitive, giving cable a run for it’s money. Perhaps one day DOCSIS 3.0 will appear, though that seems to be a while away. Perhaps one day all homes will have 100Mbps full duplex connections with low latency.

The only real way to get around this limitation is to perhaps use rsync to perform backups. Initial backups would still suck, but after that it wouldn’t be too bad. Though that wouldn’t work with services such as Amazon’s S3, which are token based. There is an rsync-like clone, but it’s still not the real thing. Perhaps Google’s upcoming GDrive will be cool enough to allow the use of rsync over SSH (I could dream) in addition to WebDAV (which is what I expect to see). Last I checked rsync doesn’t support WebDAV because WebDAV is done over HTTP. If I understand it right, RFC 3229 would add Delta encoding support to HTTP, making something like rsync over WebDAV possible since it uses delta encoding.