Wireless: Media Access Protocols and TCP Performance

This post covers two different papers:

• MACAW: A Media Access Protocol for Wireless LAN's [MACAW]
• A Comparison of Mechanisms for Improving TCP Performance over Wireless Links [COMPARE]

The authors of [MACAW], motivated by the proliferation of wireless devices, sought a way to engineer a media access protocol that performed better than existing multiple access congestion avoidance protocols (versus carrier sense protocols).

The authors of [COMPARE] were interested in how TCP could be tuned (or modified) to perform better over the broadcast medium of wireless links (i.e. assuming some fixed media access protocol).

It is interesting to see how, once again, TCP has become such a dominating network transport protocol that we are willing to sacrifice possible performance in order to augment it (as little as possible) to operate over emerging network technologies. In fact, it seems very likely that a new network technology (link-layer technology or transport-layer technology), even one that outperforms existing network technologies, that imposes a seriously difficult transition path for TCP will have a hard time being adopted. The authors of [COMPARE] do mention one new such technology, selective repeat protocol (SRP), but claim was not conclusive as a better alternative to TCP (although selective acknowledgment + TCP was).

It is not clear exactly what is the right level for abstractions and optimizations in the networking stack. Perhaps it is time to investigate how applications might actually perform better if they had a better understanding of the actual mediums that they were running on? Perhaps the applications themselves might better be able to take advantage of wireless networks by changing, for example, their sending patterns? Operating systems research has shown how applications that can take advantage of lower-level resources can often outperform those applications that rely on layers of abstractions (exokernel, scheduler activations, acpm, etc). Perhaps there is an analogue in the networking world?

An interesting aspect of [MACAW] was the investigation of the backoff counter. The authors conclude from their investigation that a backoff counter is needed for each station that a node is attempting to communicate with. In addition, all of the nodes communicating with that station need the same backoff counter in order to ensure fairness. (Digression: While I don't know enough about 802.11(a,b,g), I was not under the assumption that a station simultaneously communicated with more than one node (station), in which case, I'm curious how sophisticated the backoff mechanism needs to be.) I'm curious, given that I'm a frequent of coffee shops, how many of my "delayed" connections are due to backoff congestion, packet interference loss, versus TCP congestion control. (You know, when the network sometimes just stops responding and it is best to actually re-submit the url request ...)

(Hmm, I'm getting used to a new style of writing blog posts, less summary and more interesting thoughts from the paper to encourage feedback/conversation with others ...)