MavEtJu's Distorted View of the World - 2011-03
A proper WAN Optimization analogy
All about MAC addresses Online newspapers, waiting on the iPhone to load them Back to index A proper WAN Optimization analogyPosted on 2011-03-29 18:00:00 Even after working for Riverbed Technology for two and a half years now, I still have to come up with a bullet-proof analogy of how WAN optimization works. Consider a network from one side of this planet to the other side: A round trip time of 300 milliseconds for 20 million meters. Of that 300 milliseconds, you have two factors: The speed of light to get from A to B, and serialization delay which happens at every hop and is related to the bandwidth and the size of the packet. One is constant, the other one is variable. To move data in a stream, the throughput is limited to the smallest bandwidth in the path. Although you can move data faster on other parts, it all has to go through this one. As an example, say you have a stream of 300 Mb and a smallest bandwidth of 2 Mbps. Without any protocol overhead, this will take 20 minutes to go through there. With a fourty byte protocol overhead and an MTU size of 1500, this will take 20 minutes and 33 seconds. Now with WAN optimization. It consists of three parts: Optimization on TCP level, which has been ignored for now. Latency optimization on application specific protocols, which has been ignored for now. And data optimization, where the data is either compressed or only referred to. If the same or similar data gets transfered via two WAN optimizers twice, the first time you would get a relative small reduction factor, depending on the compressability of the data, while the second time you would get a large reduction factor because the data patterns is alreayd known on both devices. If that 300 Mb is split into segments of 1024 bytes, making it 300 000 segments, and each segment has a 64 byte label, you end up with only about 19 Mb worth of labels. Transfering that 19 Mb through a 2 Mbps link will be take 80 seconds, about 15 times faster. Now back to the topic: A good analogy for WAN optimization. Is it faster than light? It feels like it, but the Round Trip Time of the WAN is still the same. And the speed the packets go via is still the same. Is it a "wormhole"? Wormhole-based paths which are shorter than a non-wormhole-based paths. The path travelled travelled for optimized traffic still has the same distance. Is it comparable with ships, where goods are stored in containers (labels) and then transported in large bulk carriers? If the speed limit of other ships was limited to the speed limit of the bulk carriers, then it would be a good start. Is it a train analogy, where passengers are cramped into carriages and efficiently transported across the rail network? It could be, except that on the railroad network everything is put into train carriages and transported efficiently on it. Comparing it with the French TGV and the Japanese bullet trains does not work neither, because the speed of the packets is still the same while these trains are way fast. So, the analogy needs to use the same speed limits on the transport mechanism, and needs to give the impression that the delivery gets faster without changing the distance. The best thing I come up with is transport of goods via large trucks instead of via small delivery vans: Goods are shipped via small delivery vans to a distribution point, stored into a single large truck which then uses the same transport infrastructure as small fast vans would have used if they would have transported their payload. Instead of a long convoy of small vans, you get one truck towards the distribution point which there gets reloaded into numerous small vans. The only thing which does not make sense yet is that small delivery vans are often 2 x 4 x 1.5 meters and big trucks are 3 x rather long x rather high, which gives the impression that size still matters while this isn't the case on WAN optimized traffic... That is the problem if you work with magic :-)
All about MAC addressesPosted on 2011-03-17 18:00:00 The "FreeBSD laptop as a Wireless Access Point for an iPhone" project I wrote earlier about has made me some followers, mostly they have no idea where the free internet connection comes from. But, based on the amount of download measured on it, they are enjoying it. One of the methods to determine how many people are on it is to use the output of the "arp -na" command: Every MAC address you see there is a mobile device which is associated with the wireless access-point you created. One thing which you can do with that data is to match it against manufacturers. Very boring for non-networking techies... Don't read the rest :-) MAC addresses consist of 12 hex-digits (48 bits) which are split in two parts: A six hex-digit (24 bits) prefix and a six hex-digit sequence number. The MAC (or OUI as the IEEE calls it) prefix database can be found on the website of the IEEE at http://standards.ieee.org/regauth/oui/oui.txt. It contains at the moment of writing 14765 prefixes. The manuf(acturers) file from the Wireshark project can be found at http://anonsvn.wireshark.org/wireshark/trunk/manuf and contains 18321 prefixes plus a handful of shared prefixes. Why is the one from the Wireshark project larger? Not really sure, but if you look at the registration costs it (US$ 1750 for a public registrered prefix OR US$ 1750 plus US$ 2100 per year for a private registered prefix) must be part of it. So it could be that the list from the Wireshark project has determined a bunch of the private ones. And unlike IP space which you can register in advance, you can't get a new prefix until you have certificated that you have used 95% of the sequence numbers. Some statistics based on grep and cut and wc:
Number of prefixes Company 503 Cisco 122 Shenzhen 112 Motorola 109 Nokia Danmark A/S 84 Samsung Electronics 84 Apple 78 Intel Corp 59 Advanced (??) 61 Hewlett Packard 51 Private "Advanced" could be a mistake in here, since it matches Advanced This and Advanced That. "Private" means a company who pays the US$ 2100 per year. Shenzhen has the same issue as "Advanced", it is a large bunch of companies in the Shenzhen city in China (near Hongkong). Apple was the company I didn't expect in the Top 10, but considering their iPhone / iPad success, it shouldn't surprise much. Every prefix has 2 ** 24 entries in it, or 16 777 216 (about 16 million if you are conservate, or 17 million if you are optimistic), making there 1.4 billion Apple MAC addresses in the world. That number is not the number of Apple devices, since you need one per network interface: Ethernet, wireless or Bluetooth. But the other number of Cisco is much more impressive: 8 438 939 648 MAC addresses. More than the next five in the list together. Unfortunately the list of prefixes does not contain any assignment dates, it would have been interested to see what happened when LANs based on switching instead of hubs became the norm (and thus Cisco when Cisco started to sell their switches) and when mobile devices like the iPhone became popular, it would have boosted the allocation rate by Apple for sure. MAC prefix exhaustion? Unlike other technologies, and IPv4 comes in mind here, the MAC address prefix pool is pretty much unlimited but also only slowly being touched: There are 2 ** 22 or 4 194 304 prefixes. The number is 22, not 24 because two bits in the first byte of the prefix are used to determine if the MAC address is globally unique one or a special one. And right now, a good 35 years after the invention of Ethernet and Tokenring there are not even 19 thousand used. The other causes are of the more strict rules the IEEE handles: You get a single prefix and don't get more until you have informed us officially that you have used 95% of them, and of course that you actually need to produce (and sell) something which uses a MAC address.
Online newspapers, waiting on the iPhone to load themPosted on 2011-03-02 18:00:00 One of the uses of my iPhone is as a replacement for the newspapers and other news sources. Yes, I can do this on the computer too, so far nothing new. The thing which fascinates me is how much time I spend on waiting for the data to be retrieved. Take the ABC app. On it, I only read two sections: The Just In section and The Drum. I open the app, have to wait for the Latest News section (which is not the Just In section) has been loaded, then I tap for the overview of the sections (which is instantly) and then tap on the Just In section, for which the overview gets loaded. To read an article, I tap on that article which then gets loaded. So I have to wait three times before I can read a single article, and every other article I need to wait again. Even after having read the ABC news this way for about a good year now, it still doesn't remember which news sections I'm interested in and doesn't pre-load them. Take the SMH app. It is a little bit nicer, you can tell it which sections you are interested in and only shows those. It opens the one you opened last time up first. Could be close to a winner! But then it has the same cons as the ABC app: It loads the index and when you tap on the article you want to read it loads that one. Waiting twice again. Take the Volkskrant app. It has two major sections, the Just In section and the Opinion section. When you start the app, the index of the Just In section gets loaded together with the text of all the articles. When you tap on an article, it comes up immediately and then loads any images: You can read it immediately. So you only wait once. Take the BBC app. Just like the Volkskrant app, it loads the index and contents of the main sections at startup, which also has a lot of images on it. When the article gets loaded, it will load the image on the article. The method of loading of content done by the BBC app and the Volkskrant app is by far the most ideal way of using an online news app. I am not yet sure if I prefer the sober layout of the Volkskrant or the smooth horizontal scrolling layout of the BBC. But overall, I am looking forward to the day the Australian news apps have caught up! |