Interesting Tidbits in der Schweiz

This blog started off as a place for me to post paper commentaries for a computer networking course at Berkeley, but I'm commandeering it for my travel journal. I won't be attempting to write something everyday, but I will be using it over the course of the next 6 months to post things of interest about projects I'm working on, as well as Switzerland, the people, and the language(s) around me.

After a grueling 18+ hour-long journey that took me through Atlanta, Chicago, and Sweden, I made it to Zurich. Fortunately, signs in the Zurich airport are written in English, as I understand approximately one word of Swiss German. Swiss German is quite different from high German, "standard" German. Now, high German is rarely described as being a fun or romantic language.. but I find it to be one of the cutest languages I've ever heard, namely because of the vocabulary. While English speakers are no strangers to compound words, they typically reserve compounds for more complicated concepts. Not the case in German.

Take "airplane," for example. A simple enough word for a simple enough concept, right? Not in German. "Airplane" can be reduced to even simpler concepts, translating as "Flugzeug," or flight-thing. Ice skating in German becomes sled-shoe-running, glove becomes a hand-shoe, and my personal favorite is the translation for crosswalk, which is zebra-stripes. Well, the newest addition to my list of Fun German Compounds is Kuschelwetter. I heard this word used on a German news channel for the weather forecast. Kuschelwetter describes wet, gray, rainy weather, and what does it translate to? Cuddle-weather. Whoever says Germans are cold and impersonal clearly never visited in autumn.

In Pursuit of Free Phone Calls

In my attempts to get free international calling, I'm bringing a wi-fi-only calling configuration to my Google Nexus One platform. Unfortunately, Google Voice isn't a VoIP service like Skype; it requires use of the cell network to move packets around. I say "unfortunately" because the process of making and taking calls becomes a lot more complicated. This whole process took me two consecutive evenings to complete, but the ultimate payout is worth it.

Here's what I'm using for my configuration, which is successfully taking inbound calls and making outbound ones:
Google Voice + SipDroid + sip2sip + ipKall + PBXes + Google Voice Callback

My loose translation of what goes on when I accept a call on my Nexus One:
IPKall and PBXes are both associated with the same SIP number, so when a call comes into the Google Voice number, it forwards to the IPKall number, which is tied into a SIP number. The SipDroid app uses its PBXes call path settings to accept calls to this SIP number. Essentially, it creates the connection from my phone to the other destination by going through the path "Google Voice->IPKall->SIP number, taken by SipDroid app using PBXes".

When I make a call on my Nexus One:
Google Voice Callback intercepts my call; it calls my number on one end of a connection (which goes through incoming process mentioned above) and then calls my intended destination with my Google Voice number showing up on the caller ID. I didn't initially understand why this app was necessary, but really it's about bridging the VoIP-cell gap. Without it, my cell phone wouldn't understand how to make use of its SIP+physical number setup to traverse the cell network used by Google Voice.

*** Update (Nov. 26, 2010): I've been using this setup now for the past 2 months to make calls from Switzerland to the US. Call quality is pretty good, but sometimes with a slight lag (not a noticeable problem if you and your other party both talk and process slowly). The quality of your WiFi connection can dramatically impact the quality of your calls; initially the wireless network I was using was having some hiccups, and calling was essentially unusable. On the up-side, text messaging works great even with a bad WiFi connection.


Slightly more detail on the different pieces of the configuration, if you care:

Google Voice: app on the phone that calls numbers with Google Voice number; when verifying the phone with Google voice, I use the physical IPKall phone number

SipDroid: app on the phone, "softphone" that ultimately accepts calls. Connected to PBXes setup

sip2sip: sip phone DID number provider (sip:2233#####@sip2sip.info) [sip2sip.info]. Acts as sort of the transitioning point from cell network to VoIP.

IPKall: real phone number that's associated with SIP number; Google Voice thinks this is the phone number that my (non-existent) carrier has provided me with.

PBXes: creates routing paths that tie a SIP number to actions [pbxes.org]; SipDroid uses PBXes settings to take incoming calls for a given SIP number

Google Voice Callback: connects my phone and my callee's phone by first calling me and then the other end

BotGraph: Large Scale Spamming Botnet Detection; Zhao, Xie, Yu, Ke, Yu, Chen, & Gilumm

This paper describes BotGraph, a system to detect Web-account abuse traffic generated by bots. It attempts to determine the botnet on the collective scale, not determining individual nodes, by taking advantage of similarities in configuration among nodes in a botnet. Detecting this abuse consists of detecting aggressive signups and logins.

Detecting botnet signups is based on spikes of signups from a given IP address. Locating all bots in a bot-user group is done through use of a graph with users as vertices and weighted edges between them showing their activity similiarity. This paper uses a DryadLINQ-based system to process large amounts of data in parallel for these user-user graphs. A nice thing about this paper is that if the botnets adaptively limit their signups or e-mails sent per bot, even if the graph doesn't pick them up as being bots, their activities will have been sufficiently scaled back that they don't pose nearly the problem they did previously.

Not-a-Bot: Improving Service Availability in the Face of Botnet Attacks; Gummadi, Balakrishnan, Maniatis, & Ratnasamy

Botnets are responsible for a large portion of all undesirable web traffic, such as spam, DDoS attacks, and click-fraud, which can be reduced with effective schemes to correctly classify traffic as human-generated or bot-generated. However, these schemes must not trust potentially-infected hosts and must be as transparent as possible to users. This paper describes Not-a-Bot (NAB), a human-activity attester that requires both a Trusted Platform Module chip and a verifier module implemented in the Xen hypervisor at any server wishing to use it. NAB attempts to reduce bot-generated traffic while not affecting human-generated traffic.

An interaction is attested to be human-generated based on how closely recent activity from the keyboard and mouse ports matches the potential web traffic. If matching recent activity cannot be found, an alert is issued that the activity could not be attested. Bots could replicate this user behavior in their messages to be sent, but NAB rate-limits this activity by requiring application-specific time between attestations. The TPM on a host then signs and sends the request on, where it can be checked at the destination verifier.

The authors evaluate their scheme on actual traces of several hundred users, as well as malware traces and spam messages. They found that NAB does very well in suppressing spam, DDoS attempts, and click-fraud by around 90%, and it didn't deny any human-generated traffic.

In reading about the scenarios in which NAB is actually applied, I wondered how many average e-mail users would actually want to deploy NAB. The authors then addressed this question by saying that e-mail users would benefit from having all their mail correctly classified. However, I personally don't feel that I'm largely affected by mis-classification of my e-mails, so I still have a hard time accepting that NAB could catch on widely. The DDoS scenario is less effective in justifying use of NAB, particularly since some legitimate web requests could be machine-generated. As for detecting click-fraud, any company getting ad revenue could make use of NAB, but the benefits for users is low; I particularly disliked the idea of having an attester bundled with installed toolbars.

Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems; Nedevschi, Chandrashekar, Liu, Nordman, Ratnasamy, & Taft

This paper examines the energy wasted by computers not taking advantage of idle times to go into lower power sleep modes. The authors straight out acknowledge that this problem of when and how to effectively put nodes to sleep without them losing their network presence has been examined, with wake-on-LAN and proxying as potential solutions.

Based on traces from actual users, they justify the need for these solutions by showing that the studied computers actually do spend a lot of time in idle and that in many cases, long gaps of time pass between packet arrivals at the idle machine. Not suprisingly, the machines tend to have more frequently arriving packets in the office setting than in the home setting, with some users having even more available idle time than others.

I like this paper because it breaks down the type of network traffic seen in both the home and office settings; it starts out breaking both the incoming and outing packets into unicast, multicast, and broadcast groupings, and then further examines the breakdown of the multicast and broadcast packets into such things as ARP, IGMP, etc. These breakdowns are important because the power savings possible due to proxying for a node are dependent on which packets a node does not actually need to be woken up for.

Protocols are classified into groupings such as "don't-ignore" (ARP or DHCP requests for the sleeping node), "don't wake", ignorable, and mechanical response that the proxy can respond to. With these classifications in mind, the authors present 4 proxy schemes that offer varying levels of power savings, with the tradeoff that less application state is maintained. They find that their more aggressive schemes offer a lot of power savings, particularly in the office environment, and create a prototype of their proxy architecture in Click.

Cutting the Electric Bill for Internet-Scale Systems; Qureshi, Weber, Balakrishnan, Guttag, & Maggs

This paper discusses reducing energy costs of operating a data center. This technique relies on temporal and spatial fluctuations in electricity costs as well as use of dynamic request routing across widely distributed machines. The notion of energy elasticity determines how much money can actually be saved by changing the load on a machine; machines with greater energy proportionality can save more money when they're less used than those machines that continue to burn lots of power when idle.

The authors choose to focus on real-time electricity pricing instead of future, predicted markets, though RT makes up about 10% of the market share. Routing to different geographic areas to obtain the best price relies on low correlation between hourly prices in different regions, which appears to be the case between different Regional Transmission Organizations (RTOs). Part of the difference in cost between two locations at once is the fact that different time zones reach their peak cost at non-peak hours in other locations.

An inherent tradeoff in cutting cost of electricity by routing it elsewhere geographically is an increase in bandwidth costs, which the authors accounted for in part of their study. They did find that this cut the amount of energy costs that could be saved, but they still managed to cut total operating costs. Further reductions could be made through enrolling in demand reduction programs, but that would require delay-insensitive workloads within the data center, and it's not obvious whether that tradeoff would end up being monetarily beneficial.

Regardless of the assumptions the authors must make to simulate their ideas, I think the idea of geographic routing based on hourly electricity costs is a great idea (to the extent that performance doesn't suffer greatly), particularly if the work might be moved around anyway due to node failure or data placement.

Scalable Application Layer Multicast; Banerjee, Bhattacharjee, & Kommareddy

This paper describes the NICE (NICE is the Internet Cooperative Environment) multicast protocol. Like SRM, NICE is implemented at the application layer so as not to require changes to the underlying network. NICE uses hierarchical layers to group nodes into clusters and in doing so, reduce stretch, or unnecessarily increased path length from the unicast path.

When new hosts attempt to join, they first communicate with a Rendezvous Point (RP) node, which then directs them to high-tiered nodes, which subsequently direct the host to lower-level nodes close to them. Higher-level nodes are cluster leaders, responsible for keeping the size of their associated cluster between a certain threshold and splitting or merging the cluster group when the max or min threshold is passed. Members of a cluster alert each other to their presence throughput periodic heartbeat messages.

The authors simulate NICE and compare their results to Narada, an existing multicast protocol. They find that it performs comparably, but with less control overhead and less stress (total messages sent over a link) on links. The hierarachical structure of NICE seems to be the main reason that it has such low control overhead and hence can be used (at least in simulation) for groups of large sizes, say, greater than 1024 hosts, which Narada cannot do. The paper references another paper about Narada, but I wished they would have given a succint, organized comparison of the two protocols.

This paper went much more into detail about the underlying workings of the multicast groups, while the other paper offered a more concrete example of when this multicast framework would be used and how to detect and deal with losses.