Trip notes from Mobicom 2011

-

I am attending MOBICOM'11 at Las Vegas, and mostly enjoying it. I took some notes from the talks. Here I will share my notes about a couple of talks which I found more interesting than the others.

  • SmartVNC: An effective remote computing solution for smartphones. The goal here is to improve on the usability of solutions (such as AndroidVNC) that allow accessing a remote PC from a smartphone. The problem with AndroidVNC is task-inflation: user needs to do a lot of zooming and panning and also the small keyboard is inconvenient for typing. The solution offered is to use macros to automate common user-specific tasks in AndroidVNC. The macros appear as a sidebar and the user can click a macro to perform several steps quickly. These macros are defined as hooks at the GUI level (instead of app-level or OS-level) so that they can be application-agnostic as well as robust and extensible
  • Detecting driver phone use leveraging car speakers. The goal is to block the delivery of a call or SMS for the phone in the driver seat so that the driver is not tempted to take the call. The proposed scheme is as follows. The phone sends a "beep" signal over Bluetooth to be played by the right speaker and records the round-trip time, then the phone sends a beep signal to be played by the left speaker and records the round-trip time. (Most cars at least have two channel speakers to make this scheme possible.) By using the offset round-trip times, the phone can localize itself to be in the driver seat or the passenger seat. (Yes, there are obvious/acknowledged problems with the scheme: it is not 100% robust; driver's phone sitting in the passenger seat defeats the scheme; the audible beep alerts the driver to an incoming call which may defeat the purpose.)
  • I am the antenna: accurate outdoor AP location using smartphones. The goal is to develop an app to escort a smartphone user that is connected to a WAP with a weak signal to walk towards the WAP so that he can get a stronger signal. The solution is to exploit the "body-blocking effect" to figure out the direction of the WAP. The human body blocks the RSS from the WAP significantly, so when the user's back is turned toward the WAP (that is when our body is in between the phone and the WAP) the RSS degrades significantly. In this scheme, the user fires up the app, makes a full rotation slowly, and the app tells him which direction to walk to  in order to get to the WAP. Rinse and repeat several times to locate the WAP (we could as well call this the whirling-dervish app). Unfortunately, this scheme does not work inside the buildings due to multipath effects. But it is still useful for a user outside to be able to locate the WAP in a building.

As evident from these selected talks, there is tangible excitement about smartphone research at Mobicom; but I guess the community has not completely figured out solid research directions to pursue in the smartphones area yet. In addition to the smartphone talks, there were talks on all kinds of wireless communication topics, including opportunistic routing (still kicking in 2011?), and physical and MAC layer work for wi-fi. With the help of software-defined radio platforms, the researchers can now fiddle with the wi-fi platform at granularity not possible before. As a result of this new-found flexibility, there were a couple of works which were essentially re-discovering/re-inventing some wireless sensor network MAC protocols done in 2003-2005 in the wi-fi domain.

At the end of the first day, there was an outrageous opinions session which was a lot of fun. It consisted of 8 talks with 5 minutes each. There were only two serious exploratory ideas, and the remaining 5-6 talks were in the spirit of stand-up comedy for CSE nerds. A majority of the talks were proposals (mostly tongue-in-cheek) about how to improve the review process and the conference. I like the concept a lot, and will try to include some outrageous posts of my own occassionally in this blog. By the way, here is my outrageous opinion about improving the conference experience. The keynote speaker should give $20 for each attendee as pre-compensation for their one hour. If the attendees think the talk was well-worth the $20, they will return the money back to the speaker else they keep the $20 bill as a compensation for the lost time.

During the coffee and lunch breaks I got to meet/catchup and chitchat with several colleagues. Those were probably the most fruitful time I had at the conference. We exchanged a lot of ideas, insights, stories, and gossip.  I think conferences are invaluable not because of the papers/talks, but because of these personal interactions/communications. You have to catch me in person to hear more of my Mobicom stories.

Finally, I should write a bit about Las Vegas. Vegas is home to fake Venetian canals, fake Roman statues, fake palaces, a fake Eiffel tower, fake volcanos, fake lakes, fake pirate ships, and fake hopes that fade at dawn in front of the slot machines (--while going to the registration desk at 7am the first day, I came across several people still gambling with red-eyes and frustrated faces at the casino). That said, I really liked the Bellagio fountain show; it was original and spectacular.  The conference hotel was nice, the food good. But... <bitching> the wireless in the conference was unusable the first day, and completely unavailable for me the second day. It is ironic to have these problems at a conference specializing on wireless communication. </bitching> To finish on a high note, the conference banquet was one of the best I have ever been to. It was held at the Secret Garden in the Mirage hotel. We got to see Siberian tigers, Albino lions, Albino tigers, leopards, and got to watch the dolphins' show.

Some dolphin facts. The trainers train the dolphins 6 times a day (total time spent a day is 2 hours). After 5 years of training the dolphin is able to do the tricks in typical SeaWorld show, but the trainings continue lifelong. Dolphins live around 40 years, but the trainer I talked to mentioned that he worked with some 50 year old dolphins before. The training is done mostly with positive reinforcements. If dolphins misbehave during training, the trainer stares at the dolphin's eyes and stays expressionless for 3-4 seconds. Dolphins are good at recognizing human body language (very much like dogs), and the trainers also learn to recognize dolphins' body language. Dolphins are smart, but the trainer I talked to thinks sea lions are even smarter: they can learn how to open a gate just by watching a human do it.

Comments

Anonymous said…
kind of feeling these topics are deviating from the theme of networking.
September 25, 2011 at 3:04 PM
Post a Comment

Popular posts from this blog

Hints for Distributed Systems Design

-
This is with apologies to Butler Lampson, who published the " Hints for computer system design " paper 40 years ago in SOSP'83. I don't claim to match that work of course. I just thought I could draft this post to organize my thinking about designing distributed systems and get feedback from others. I start with the same  disclaimer Lampson gave. These hints are not novel, not foolproof recipes, not laws of design, not precisely formulated, and not always appropriate. They are just hints.  They are context dependent, and some of them may be controversial. That being said, I have seen these hints successfully applied in distributed systems design throughout my 25 years in the field, starting from the theory of distributed systems (98-01), immersing into the practice of wireless sensor networks (01-11), and working on cloud computing systems both in the academia and industry ever since. These heuristic principles have been applied knowingly or unknowingly and has proven
Read more >>

Learning about distributed systems: where to start?

-
This is definitely not a "learn distributed systems in 21 days" post. I recommend a principled, from the foundations-up, studying of distributed systems, which will take a good three months in the first pass, and many more months to build competence after that. If you are practical and coding oriented you may not like my advice much. You may object saying, "Shouldn't I learn distributed systems with coding and hands on? Why can I not get started by deploying a Hadoop cluster, or studying the Raft code." I think that is the wrong way to go about learning distributed systems, because seeing similar code and programming language constructs will make you think this is familiar territory, and will give you a false sense of security. But, nothing can be further from the truth. Distributed systems need radically different software than centralized systems do.  --A. Tannenbaum This quotation is literally the first sentence in my distributed systems syllabus. Inst
Read more >>

Making database systems usable

-
Image
C. J. Date's Sigmod 1983 keynote, "Database Usability", was prescient. Usability is the most important thing to the customers. They care less about impressive benchmarks or clever algorithms, and more about whether they can operate and use a database efficiently to query, update, analyze, and persist their data with minimal headache. (BTW, does anyone have a link to the contents of this Sigmod'83 talk? There is no transcript around, except for this short abstract .) The paper we cover today is from Sigmod 2007. It takes on the database usability problem raised in that 1983 keynote head-on, and calls out that the king is still naked.  Let's give some context for the year 2007. Yes, XML format was still popular then. The use-case in the paper is XQuery. The paper does not contain any  reference to json. MongoDB would be released in 2009 with the document model; and that seems to be great timing for some of the usability pains mentioned in the paper! Web 2.0 was in
Read more >>

Looming Liability Machines (LLMs)

-
As part of our zoom reading group ( wow, 4.5 years old now ), we discussed a paper that uses LLMs for automatic root cause analysis (RCA) for cloud incidents. This was a pretty straightforward application of LLMs. The proposed system employs an LLM to match incoming incidents to incident handlers based on their alert types, predicts the incident's root cause category, and provides an explanatory narrative. The only customization is through prompt-engineering. Since this is a custom domain, I think a more principled and custom-designed  machine learning system would be more appropriate rather than adopting LLMs. Anyways, the use of LLMs for RCAs spooked me vicerally. I couldn't find the exact words during the paper discussion, but I can articulate this better now. Let me explain. RCA is serious business Root cause analysis (RCA) is the process of identifying the underlying causes of a problem/incident, rather than just addressing its symptoms. One RCA heuristic is asking 5 Why&#
Read more >>

Foundational distributed systems papers

-
I talked about the importance of reading foundational papers last week. To followup, here is my compilation of foundational papers in the distributed systems area. (I focused on the core distributed systems area, and did not cover networking, security, distributed ledgers, verification work etc. I even left out distributed transactions, I hope to cover them at a later date.)  I classified the papers by subject, and listed them in chronological order. I also listed expository papers and blog posts at the end of each section. Time and State in Distributed Systems Time, Clocks, and the Ordering of Events in a Distributed System. Leslie Lamport, Commn. of the ACM,  1978. Distributed Snapshots: Determining Global States of a Distributed System. K. Mani Chandy Leslie Lamport, ACM Transactions on Computer Systems, 1985. Virtual Time and Global States of Distributed Systems.  Mattern, F. 1988. Practical uses of synchronized clocks in distributed systems. B. Liskov, 1991. Expository papers
Read more >>

Advice to the young

-
Image
I notice I haven't written any advice posts recently. Here is a collection of my advice posts pre 2020. I've been feeling all this elderly wisdom pent up in me, ready to pour at any moment. So here it goes. Get ready to quench your thirst from my fount of wisdom. No man, think for yourself, only get what works for you. It is called foundations, not theory Foundations of computer science (or rather any field of study) are the most important topics you can learn. These lay down the frame of thinking/perspective for that area of study. Yet, I am saddened to hear these called as "theory", and labeled as "unpractical". This couldn't be farther from the truth. Take a look at how I recommend studying distributed systems . Don't you dare call this "theory" and "unpractical". This lays the bedrock that you build your practice on. Don't skimp on the foundations. Don't build your home on quicksand. Keep your hands dirty, your mind cl
Read more >>

Linearizability: A Correctness Condition for Concurrent Objects

-
Image
This paper is from Herlihy and Wing appeared in ACM Transactions on Programming Languages and Systems 1990. This is the canonical reference for the linearizability definition. I had not read this paper in detail before, so I thought it would be good to go to the source to see if there are additional delightful surprises in the original text. Hence, this post. I will dive into a technical analysis of the paper first, and then discuss some of my takes toward the end. I had written an accessible explanation of linearizability earlier; you may want to read that first. I will assume an understanding of linearizability to keep this review at reasonable length. Introduction I love how the old papers just barge in with the model, without bothered by pleasantries such as motivation of the problem. These are the first two sentences of the introduction. "A concurrent system consists of a collection of sequential processes that communicate through shared typed objects . This model encompass
Read more >>

Scalable OLTP in the Cloud: What’s the BIG DEAL?

-
Image
This paper is from Pat Helland, the apostate philosopher of database systems, overall a superb person, and a good friend of mine. The paper appeared this week at CIDR'24. (Check out the program for other interesting papers). The motivating question behind this work is: " What are the asymptotic limits to scale for cloud OLTP (OnLine Transaction Processing) systems? " Pat says that the CIDR 2023 paper "Is Scalable OLTP in the Cloud a Solved Problem?" prompted this question.  The answer to the question? Pat says that the answer lies in the joint responsibility of database and the application. If you know of Pat's work, which I have summarized several in this blog , you would know that Pat has been advocating along these lines before. But this paper provides a very crisp, specific, concrete answer. Read on for my summary of the paper. Disclaimer: This is a wisdom and technical information/detail packed 13-page paper, so I will try my best to summarize the sa
Read more >>

Understanding the Performance Implications of Storage-Disaggregated Databases

-
Image
Storage-compute disaggregation in databases has emerged as a pivotal architecture in cloud environments, as evidenced by Amazon ( Aurora ), Microsoft ( Socrates ), Google (AlloyDB), Alibaba ( PolarDB ), and Huawei (Taurus). This approach decouples compute from storage, allowing for independent and elastic scaling of compute and storage resources. It provides fault-tolerance at the storage level. You can then share the storage for other services, such as adding read-only replicas for the databases. You can even use the storage level for easier sharding of your database. Finally, you can also use this for exporting a changelog asynchronously to feed into peripheral cloud services, such as analytics. Disaggregated architecture was the topic of Sigmod 23 panel . I think this quote summarizes the industry's thinking on the topic. "Disaggregated architecture is here, and is not going anywhere. In a disaggregated architecture, storage is fungible, and computing scales independently.
Read more >>

Designing Data Intensive Applications (DDIA) Book

-
Image
We started reading this book as part of Alex Petrov's book club . We just got started, so you can join us, by joining the discord channel above. We meet Wednesday's 11am Eastern Time.  Previously we had read transaction processing book by Grey and Reuters. This page links to my summaries of that book. Chp 1. Reliable, Scalable, and Maintainable Applications I love the diagrams opening each chapter. Beautiful! The first chapter consists of warm up stuff. It talks about the definitions of reliabilty, scalability, and maintainability. It is still engaging, because  it is written with an educator and technical blogger voice, rather than a dry academic voice. This book came out on 2017. Martin is working on the new version. So if you have comments for things to focus on for the new version, it would be helpful to collect them in a document and email it to Martin. For example, I am curious about how the below paragraph from the Preface will get revised with 8 more years of hindsight:
Read more >>