A day in life without running water

Before you worry too much - no, I did not go into exile into the sub-Saharan Africa or polar-circle Siberia.

And I do have the tap water. I needed a catchy title to get you thinking - and to share my own experience about something that a lot of us take for granted: a high-bandwidth practically unlimited Internet connectivity. But this is not granted for a lot of parts of the world.

It's an experiment that I've dubbed "extreme tele-working": 1 month on an island off African coast, working as usual: taking part in webex conference calls, communicating over IM, reading and writing emails, preparing the presentations, testing things in the lab, and so on - anything I'd be expected to do during my normal business routine, minus travel. The latter was the reason for choosing August: this month is usually quiet on travel, so only the "office" work is left.

It was a bit of a risk to go for this, given that the only investigation I did before was about the general availability of the internet in this area, and some small investigations about the price of the 3G: as an added challenge, about 1/3 of the month we spend in one place on the island, and the 2/3 in another, none of which have a reliable connection.

I got a reasonable deal: a "monthly" connection that allows "unlimited" Internet over 3G. There's a catch, however. Eat all you can eat, as soon as you do not eat more than 250Mb per day. After that your connection gets rate-limited to 64kbps.

Another particularity about my setup: I use a Linksys E3200 running TomatoUSB firmware, as my router/access point - with the WAN interface connected as client to an iPhone that allows the tethering over WiFi. The reason for doing that was to both get better control over the traffic and to lower the strain on the iPhone - just in case it was not designed to act as an Access Point for 30 days straight!

This setup brings some particularity - for anything on the E3200 WiFi, the connection is indistinguishable from a regular broadband home connection - thus, even if an app would be able to do special handling for the tethering scenario, it can not do that in this case.

I got a stark reminder that my connection is not the "usual" broadband when I ran out of my limit early afternoon on the first day of running this setup in "established" mode. Something ate 250 MB. What ? I kept pondering about that as I was straggling to survive the rest of the day, waiting for the emails to slowly pour over 64Kbps VPN.

So, I got onto the crusade of getting my traffic under control - I wanted to work without any "surprises".

First thing that went away was any "casual distraction" social networking and random browsing. Luckily I already had the dedicated Virtual Machine with Linux for all the "social stuff". The result was an immediate pay off. Did you notice how much traffic does an open Facebook page in the browser consume ? Give it an hour or so, and it's multiple megabytes. Nothing on your broadband - but it becomes several percent of the daily cap. Another great side effect - no more "social" distractions throughout the day, I felt much more focused.

Another thing that I empirically singled out was Webex: the meetings are often run with screen sharing, and my anecdotal observation was that the screen sharing seems to run a video stream, which tends to be quite bandwidth hungry. Let's use the Webex app on the iPad - and shape the iPad address on the Linksys down to 32K with 64K bursts. Worked wonders! The only drawback it does take a little more while to join the meeting, but otherwise the screen sharing works fine! Whatever the Webex folks did, they did it right, it adapts to low bandwidth!

Wait, what about the VoIP ? I tried to run VoIP and ration it - until I realised that the solution in this case is to employ additional common sense. A direct inbound call on the cellular number is way way way cheaper (free?) than trying to squeeze some data out of the daily cap and then running voice on it. The added benefit is that my traffic shaping experiments do not affect the quality of the voice.

One thing that happened as well earlier, was a switch from Chrome to Firefox and some configuration tweaking: Chrome on a rate-limited 64Kbps connection was completely stubborn - nothing beyond a trivial website would load. I think this is because they'd try to optimise the user experience at the expense of some extra network traffic… which got dropped… so the user experience was that nothing worked at all. I had a hunch that if I make the browser behave more like it's 90s, it'll be more performant at 90s' data rates. Indeed this was the case. I changed the following in the Firefox configuration:

I set network.http.max-connections to 32, network.http.max-connections-per-server to 2, and network.http.max-persistent-connections-per-server to 2 as well. This made it possible to get the pages to load even on severely rate-limited 64Kbps.

That's it for the "obvious" part. What to do with the rest and how to ensure nothing catches me unaware ?

To make life simpler, I did with a couple more tweaks:

configure the rate limiting to 256Kbps in both directions. The rationale is that 256kbps is relatively fast, but it's slow enough to make anything that hogs the resource make me notice its presence and take measures.

"noticing the presence" part meant running a tcpdump on the Linksys in a continuous fashion, and seeing any abrupt changes in traffic that happen. Another tcpdump was running on the host itself, focusing on the DNS traffic alone - this would help pinpoint what was the culprit.

This turned out to be very useful trap for catching the offenders.

One was VMWare Fusion, which on startup connected to softwareupdate.vmware.com and ueip.vmware.com and did something over HTTPS. Whatever it was, it was a lot of packets - so off comes a chunk of configuration for my dnsmasq:

address=/softwareupdate.vmware.com./127.0.0.1 address=/ueip.vmware.com./127.0.0.1

There were a couple more offenders. Something decided to make connections to plus.google.com - not a whole lot of traffic but it seemed to pop-up relatively frequently. Since I gave a vow of no social networking - I knew it was not me. Off comes another entry in dnsmasq.

Now, let's invest a few megabytes into downloading and installing Adblock Plus (I had it running on Chrome - but did not install in firefox. Good time to do it - someone just put an auto-play video ad on the page! (oops, 5MB gone!)

There were a couple more offenders who got loopback-ed in the dnsmasq, and finally I could get a consistently lazy packet rate on tcpdump throughout the rest of the day.

Now, let's get the mail… wait, it is going pretty slow… Oh, someone's HTML mail with useless graphic signatures, in a casual thread turned into a 150Kb/message shower. Duh! I am lucky no-one sent a large file yet! Time to tweak the fetch mail: introduce the "limit" option. The first day I had it really "aggressive" by today's means - 50K. The second day I relaxed it to 200K - and indeed it caught a few mails that were several megabytes in size, but very non-critical in nature. These are to be retrieved in the end of the day in a single batch.

The end result: 62 Mb down / 20 Mb up on the first day. A large chunk of the upload traffic, by the way was from Facebook that I ran in the end of the day. The second day with the same setup, but no tcpdump this time, ran in the same ballpark - about 70MB down and 15MB up. All while working pretty much "as normal".

You will say: "What's this nonsense? get yourself a real broadband and stop this nonsense!" My reply is - a lot of people in the world are in the same situation as I am - and making your lifestyle and applications accommodative to their restriction will gain you respect and thankfulness from these users.

Of course, wouldn't it be cool if the network and applications could agree on this automatically, without the manual involvement ?

Index of /blog/2013-08-16-A-day-in-life-without-running-water/

NameLast ModifiedSizeType
Parent Directory/ -  Directory
lighttpd/1.4.33