The bandwidth of a Boeing 747 and its impact on web browsing

Australia for a long time was a worst-case major economy networking situation with few, slow, and high-latency links (and still suffers from high costs due to limited links and telco monopolies).

For an understanding of how limited international data links were as recently as the early 1990s, one of the key public data links between the US and Europe at the time was a 9660 baud link according to a dated, but fascinating, compendium of networking at the time (lost somewhere in the Krell stacks, I'll dig a reference on request).

Jon Bentley's classic Programming Pearls discusses the problem of transferring graphical data images between Mountain View and Santa Cruz, California, in the 1970s. The high-bandwidth, cost-effective, sufficiently reliable solution? Carrier pigeons. Really.

http://en.wikipedia.org/wiki/Sneakernet

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. —Tanenbaum, Andrew S. (1996). Computer Networks. New Jersey: Prentice-Hall. p. 83. ISBN 0-13-349945-6.

The main example I've heard is special effects companies like Weta Digital in New Zealand wanting to deliver video to the US across a 200ms latency link.

There are a few open protocols in various stages of development or you can pay for a product like FileCatalyst http://www.filecatalyst.com/ ( some interesting case studies on their website ).

All engine data that the pilot can see is available realtime on the ground at the repair stations.

What this means is that an engineer can call up a GE-CF6 in the second position on the starboard wing and see how it is performing. While that might not sound all that interesting, there are literally tens of thousands of measurements taken a bunch of times a second and transmitted to the ground for each engine.

For instance, if the flight was 10 hours (and every package was 100 Kb) they'd send about 35GB of data per engine. This is just the engine measurements. This does not include avionics, communication, position.

Most of the information is propriety for how they store, transmit, and calculate these things so I do not know exactly how this works. I have seen one of these workstations and it is really impressive to know the exact RPM of the number two engine compressor is spinning at in real-time of a flight crossing the Atlantic.

Also, you can two-way text-message with the pilot from this workstation to pass perceived information about the engine performance.

I recall the US now has a relatively free hand in confiscating storage media for analysis/cloning during border crossings, and you might not get your copy back for a couple of months if they take a serious interest.

So, even though the aeroplane travel infrastructure itself is quite reliable, there are points of failure that would require another copy of the data to be created and shipped, with a much greater latency (It might take days to purchase more disks, transfer all the data onto them, find a willing courier, book their flight, etc).

Hmm, not sure about those numbers.

Say we limit it to this trip, at 10 hours.

A Boeing 747 can carry ~30,000 kg (http://www.boeing.com/commercial/747family/pf/pf_facts.html) You can get get 3TB 3.5' drives now, and they weight about 1kg (http://www.amazon.co.uk/WD-Caviar-Green-WD30EZRX-SATA-600/dp...), so 30,0003TB is 90,000TB in 10 hours.

10 hours is 36000 seconds, so that means that the speed of the data on a 10 hour flight is actually 90000/36000 = 2.5TB/sec.

That said, if we were to account for the next generation jump (http://www.techspot.com/news/47860-seagate-60tb-hdds-possibl...) so 60TB for about a kilo, we'd get 6030000 / 36000 = 50TB a second.

Obviously, the longer the flight, the more inefficient this transfer becomes.

Items detained indefinitely in the customs, items detained until bribe is paid, items lost, items stolen during load/unload, items broken (hits, pressure changes, magnetic gateways and handheld scanners etc.). Lots of problems in general, all are multiplied if your country customs and airport personnel are incompetent.

However, there is one thing that the delay (in the cited article) does not take into account is that the flights do not take-off all the time, so if you have data ready to be sent and no one to take it, then there is waiting delay before it can be sent. so if there is only one flight in a day then some data will have to wait between 24+10h to 0+10h before it can arrive. Since storage cost is very low, one could ship a lot of data but this data cannot be delay sensitive else.

on the other hand, using TCP one can prioritize data and send more important data before the rest. Of course there may be intrinsic problems with TCP receiver window and one of the proposal is to increase the initial window but the research community and the IETF is a bit split on the real benefits of it. The fear is that it may cause a congestion collapse. Moreover, the current buffer-bloat in the routers and the increase in the window size may only aid in causing a congestion collapse (http://tools.ietf.org/html/draft-gettys-iw10-considered-harm...).

And you need to sit in London traffic.

I guess fighting the speed of light sounds cooler, but that's not really the problem they are solving or speaking too, is it?

*edit just for fun: 5MB data storage transfer, 1956 http://mlkshk.com/p/AW8A (img)

Wouldn't doing it that way cut down on the latency signifigantly?

(or send the entire file, 1000s of packets) determine which don't make it and just ask for those?

This isn't my area of expertise, so I'm just curious.

A better selling point for distributed delivery is the round trip when you deal with multiple transactions, for example requesting a web page and then the included objects, or submitting data and waiting for a response.

Modulo baggage reclaim, of course.

A rackspace portable storage center fits 12,000 hard drives (=36Pb) of data, into a 40ft shipping container.

A container ship like the Emma Maersk can carry 15,000 TEU (20foot containers) across the Atlantic in 5days

So 12,000drives * 3Tb * 7000 containers = 250 million Tb, and it takes 5days = 450,000 seconds

So a data rate of 250,000,000Tb/450,000s = 600 TBytes/s

Although you do have to watch out for pirates!

So next time you're considering physical transport include the time spent in the destination country's customs, with their highly incompetent and inefficient crews.

First off, do you really think it's more practical to ship data per airplane than a simple cable that's already connecting you? Not that bandwidth is completely for free, but most of the time you're paying a flat fee and transferring this 1TB won't cost you anything extra. I bet that Boeing is quite a bit more expensive.

Secondly, at some point the article assumes the 'transfer rate' of the Boeing to be 222Mbps. While this might be true for this practical example--let's ignore that you actually need to get the data on the plane in the first place--I bet that you could load it up from bottom to top and reach practically a speed of many gigabits ifnot terabits per second.

Thirdly, the Boeing flies with physical stuff. If the plane crashes, the data is lost. You would need backups, which take time. Over the internet it's not even possible to transfer the original medium; you'd need to first transfer and then delete it.

Fourthly, while it might be true that a packet gets corrupted 28 times during this 1TB transfer (I myself do not have statistics on this, but let's assume), on the internet you can retransmit a packet. Try retransmitting that one sector on the harddrive in under a second.

Fifthly, the article goes on about how TCP needs to wait for an acknowledgement (or 'ack' in short). I've made this mistake before when choosing for UDP instead of TCP because "it would not have to wait for acks and thus make my game much faster". It's wrong because there is a so-called congestion window. I do not know the exact figures, but it's like this: The server sends packet one. Packet one is in transit. The server sends packet two. Packet one and two are in transit. The server sends packet three. Packet one arrives. Packet two and three are in transit. The server sends packet four; the client sends ack 1. Packet 2, 3, 4 and ack 1 are in transit. Etc. The thing is that the server can send up to X packets ahead, without receiving an ack.

Sixthly, the article finally concludes that this is why you should choose for Cloudflare--so it was an advertisement after all. That explains why it's told in this story-like way and why it contains so many technical errors.