A Report on NSDI'13: Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks

This is a report and summery of the presentation done by Keith Winstein on April 5th 2013. Paper co-authors are: Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan, M.I.T. Computer Science and Artificial Intelligence Laboratory.

Keith started by highlighting some special characteristics of current cellular networks. He explained how cellular networks have probably became the means by which a majority of users access the Internet, but that cellular networks differ in many ways from the traditional Internet. One of these differences is that cellular networks are very variable in link speed. Keith showed measurements they took in Boston using Verizon LTE cell phones where they measured the downlink and uplink as they kept them busy and kept recording how fast packets crossed each link.  Keith presented a graph that showed how extremely variable the network is. Keith also pointed out that another way that this network is different than the “old fashioned” networks is that that they are too reliable. We talk about best-effort network delivery, but in fact it is insane-effort network delivery. Keith showed another graph showing one TCP download and it showed how there is a big delay in the round trip time.

Then Keith presented a graph showing Skype performance over the Verizon LTE network. This is to show that Skype is not using all the bandwidth available because Skype is way conservative. Also Skype is not being careful and sends higher than the available bandwidth and the result is a huge delay. To overcome this problem, Keith presented their protocol, Sprout. Sprout is a transmit protocol designed for real time interactive applications over these variable, semi-reliable networks. Sprout has a goal to provide the application with the most throughput possible, but the higher priority is to bound the risk of accumulating a large delay in gateway queues.

In order to control the risk of delay, the authors have separate parts of their algorithm. At the Sprout receiver, the authors infer the current link speed and they do that with Bayesian inference on a stochastic model. Then, part two, the receiver tries to predict what it is going to happen to the link speed in the future.  It makes a “cautious forecast” and sends this to the sender as part of its acknowledgments. In part three, the sender uses this forecast to control an evolving window that compromises between the desire for more throughput and to control the risk that a packet will spend more than 100 ms in a queue.

Keith later showed Sprout compared with other applications, such as Skype and Google-Hangout and Facetime. From the graph, Sprout performed better in term of throughput and delay. Keith said that a Stanford networking class class had reproduced these plots and the two students who chose Sprout were awarded the best project in the class. And also MIT students were challenged to beat Sprout and came up with 3,000 different algorithms with different compromises between throughput and delay. Keith indicated several limitations in their measurements in the conclusion of his talk. That Sprout was only evaluated the case of video conference and all measurements in Boston. The source code and directions to use it is are at this link: http://alfalfa.mit.edu/

Phil Levis from Stanford University asked since I see you are using LEDBAT, so if we move on that and say LEDBAT is designed to solve suddenly different problem, but do you think you should replace LETBAT with Sprout in sense of I don’t want to increase the delay for competing application using that this is background transmit protocol? Keith answered that LETBET tries to coexist with TCP on the same bottleneck queue in sort of scavenge available bandwidth. Although there are similarities between LETBET and Sprout like counter filter and one way delay estimation, in this paper we did not test it when you compete TCP on the same queue, so we don’t want to say that we do better than LETBAT in this situation.

Kurdis Hermerl from University of California Berkeley asked if the authors have thought about using geographical knowledge to help in this, this is because falls of in throughput traffic when user is switching towers, for example driving a car, so how would Sprout use that to make better prediction. Keith answered that there is previous work in NSDI on this kind of thing , and he is not sure if speed and location may affect his results or not. The second question by Kurdis Hermerl,where he pointed out that with cellular networks, there is whole circuit switch piece of technology that essentially designed to solve this question for voice traffic, how is that related to the problem Sprout is trying to solve? Is it something Sprout could just solve by doing call over that circuit switch network? Keith replied that circuit switching networks in cellular systems have admission control that gives users certain amount of bits per second and they don’t have that for large bit rate flows that need to vary in speed. The problem is that the link quality varies which you can’t just solve it with better policy. Another person from the audience asked, looking at the graph with the available bandwidth even if the mobile it stationary, have you tested Sprout with Sprout? Keith replied that they did that by testing six phones at the same cell so we did that type of testing.

Today I received a nice (hand-written!) letter from a sophomore at the University of Delaware, where I recently gave an invited talk on our Princeton/Cornell Frenetic project on programming lanaguges for software-defined networks.  The student asked me some specific questions, and I thought the questions and answers might be interest.


Q: Since your bachelor's degree is in electrical engineering, what made you want to pursue graduate work in computer science?

A: My bachelor's degree in electrical engineering was heavily focused on computer engineering, so the transition to computer science wasn't all that big of a jump.  That said, while I enjoyed the "applied math" aspects of EE, I found I didn't have much physical intuition for analog circuits, signal processing, and the like.  What I really liked about computer engineering was that the "bottom layer" of what I was learning was as basic as Boolean logic -- the AND, OR, and NOT gates.  The prospect of being able to understand how computers work from that level up was quite tantalizing.  In graduate school, I was in a PhD program (at U. Michigan) that combined EE and CS into one department.  My thesis work (on hardware support for communication in parallel machines) also straddled the boundary between EE and CS.  Over time, I've gradually drifted toward more CS-oriented topics -- I should say that general trend is true for many computer engineers, as increasingly many of the interesting research problems in (for example) computer architecture lie at the boundaries with software (e.g., compilers, operating systems, and so on).


Q: You mentioned that you spent several years at AT&T.  How do your experiences there compare  to academia?  What are your favorite aspects of each?

A: I thoroughly enjoyed my 8.5 years at AT&T.  I had four internships at AT&T -- two during college and two during graduate school -- that whet my appetite for conducting research on real problems with access to real data.  While at AT&T, I had an "unfair advantage" of access to the people designing and running AT&T's part of the Internet, as well as measurement data from the network and an opportunity to "tech transfer" my ideas into making AT&T's network better.  Plus, as a researcher there, I could focus the bulk of my time on research, and working closely with my peers.  The thing I miss most about AT&T is the close collaboration with my peers, and serving as a bridge between practitioners in the company and more theoretically-inclined researchers in my lab.  That said, being a professor is a blast.  Teaching is even more rewarding than I expected, and not just because I feel like I am "making a difference," but also because I get to think hard about the right way to organize the material in my field and recognize the gaps in our ability to justify why things work the way they do.  Designing a technology like the Internet is a distinctly human endeavor, so it is not surprising that some parts of the design are better justified than others.  When I cannot motivate a design choice to the students in my class, I realize where we need to improve our understanding, and perhaps even change the design.  Plus, working with graduate students over a period of years -- and seeing them grow and develop so much during their time in graduate school -- is very rewarding.


Q: What sparked your interest in the Internet and network management?

A: My interest in the Internet was sparked by my summer internships at AT&T, and the arrival of the World Wide Web on the scene during the middle of my time in graduate school.  In some ways, I felt my PhD thesis research on parallel computing was a bit disconnected from real users and real data, but the Internet was rapidly moving from a research curiosity to a critical part of the world's communication's infrastructure.  How cool is that!  In networking textbooks, I read that the early designers of the Internet made the inside of the network simple, by placing most of the key functionality at the end hosts.  This belied the considerable complexity of managing the network that I saw over and over again at AT&T.  Interacting with network operators at AT&T exposed me to more about how the Internet actually works, and how hard it is to make IP networks efficient, reliable, secure, and cost-effective.  I sometimes "shadowed" the network operations team at AT&T, so I could learn what kinds of challenges they face, and better understand the limitations of existing tools (including the tools I was creating for them!).  That inspired me to create better tools and techniques, and ultimately to focus more of my research on how to design computer networks that are easier to manage in the first place!  That, in turn, spawned my interest in software-defined networking as a way to put networking (and network management, in particular) on a stronger foundation, while still keeping my "eye on the prize" of improving the practice of networking.


Q: When you started your research on BGP modeling, did you anticipate that the work would have impact?

A: At the time I started working on interdomain routing, several other researchers had uncovered important operational problems with BGP -- that the global Internet routing system could be unstable, for instance!  Yet, the research community had relatively little visibility into how BGP is configured in practice. That points to a general challenge is studying the Internet: while the Internet is man made, and we know a lot about the specific protocols underlying the system, we don't know as much about how these protocols are actually used and configured.  And that ends up mattering, a lot.  The modeling work on BGP focused on how network operators configure the protocol to achieve the economic goals of their companies, and also on helping them predict how changes to their networks (whether link failures or new routing policies) would affect the flow of traffic.  Here, as in much of my research at AT&T, I benefitted a great deal from working closely with network operators (to learn how they configure the network, and what "pain points" they have) and real data (to learn how the network is configured, and how the network behaves).  Creating theoretical results (in the form of analytical models, proofs, and algorithms) that faithfully connect with real operational practice is challenging, but I find that kind of research very rewarding.


Q: The subject of networks can be intimidating.  Where would you suggest young students being to study in order to build a solid foundation?

A: Diving in to networking is indeed intimidating at first.  Fortunately, much of the "background" in networking is something you can pick up as you go along, such as knowing how different protocols and mechanisms operate. (For more thoughts on how "details oriented" the networking field is, see "The networking philosopher's problem".)  In that sense, networking has a much gentler "learning curve" than some research areas like physics or mathematics.  Plus, often researchers have deep knowledge in only one aspect of networking, or conduct broader research through collaboration with colleagues who are experts in other areas.  For example, the Frenetic project I presented in my talk is a collaboration among several faculty, postdoctoral researchers, and students with a mix of backgrounds in networking, distributed systems, and programming languages.  Nobody on the team (myself included) has expertise in all of these areas. If you are interested in networking, my suggestion is to focus on one specific area or application, and learn that topic more deeply.  Another way to learn networking is to collect and analyze measurement data -- that's a fun way to learn how the network really works, and there are always some surprises lying in wait!  And, of course, taking a networking course!

A Report on NSDI'13: Embassies: Radically Refactoring the Web

This is a report of the presentation done by Jon Howell on 2013-04-05. Paper co-authors are Jon Howell, Bryan Parno, and John R. Douceur, Microsoft Research. Paper received Best Paper Award.

"We literally saved the best for the last!" It was with these words that the session chair Krishna Gummadi introduced Jon Howell, co-author of the best paper award winner "Embassies: Radically Refactoring the Web". Jon promptly started his talk stating that the web promises us a really nice isolation model, in which users are protected from malice even though they click on "dangerous links". He said however that the reality is quite far from that nice isolation model, as browsers have vulnerabilities that might compromise the system, if explored by a malicious web app. In this scenario, what kind of advices one should give to ordinary web users? Practice "safe web-surfing hygiene"? Do not click on "dangerous links"? What does define a "dangerous links"?

According to Jon, these security weaknesses are not caused by poor web API implementation; even a correct browser implementation cannot protect users from external protocol flaws. "The API itself [is broken and] needs to be changed", he said. Why? He first explained that the web API has a subset of methods that specify the behavior of the application when it arrives at the client; for that subset he called Client Execution Interface (CEI). To provide application isolation, CEI must be as simple as possible and have a well-defined semantics, so that it can be implemented correctly; in other words, it should pursue minimality. He also explained that the same API has served as a Developer Programming Interface (DPI), and developers have always wanted this interface to be richer and richer, so that fancier applications can be built with less and less code; in other words, it has also been pursuing richness. "This API [is broken because it] has been pulled off in two opposite directions", he said. To solve this problem, he proposed to re-factor the web API, separating these roles of CEI and DPI. In this re-factored model, web developers would still use fancy programming interfaces (DPI), which could be made even richer; in separate, the client would implement a lower level, simpler, and more enforceable model (CEI), which would be minimal. How minimal? Well, Jon showed the entire interface using a single slide! In the paper, the complete interface counted 30 functions.

Jon illustrated that the CEI would provide web applications an execution environment having the same philosophy (and isolation guarantees) of a multi-tenant datacenter, but in the client machine -- a "pico-datacenter", as he defined. The CEI would include cryptographic primitives, so that applications could provide for themselves privacy and integrity. IP would be the only protocol for enabling communication between web apps and the network, and also between web apps running in the pico-datacenter. By choosing binary code as the core of the CEI, it would accept any binary program from the vendor. In this case, web developers would be able to develop their applications using the libraries that best suit their needs (e.g. libraries for HTML rendering, JavaScript processing, etc.); not only browser incompatibility is gone in this "Embassies" model, but users would also be able to run applications such as Gimp on their browsers! To run an application in the pico-datacenter, the client would just need to load the required libraries. In the remainder of the talk, Jon discussed about a number challenges faced in this Embassies model and how they are addressed; examples include cross-app interactions (e.g. form submission, cookies, coloring of visited hyperlinks, and history navigation), library caching, and launching performance. From an experimental evaluation using a prototype, the Embassies model has shown to introduce some overhead. However, he argued that this model brings several advantages; the pico-datacenter analogy, for example, makes security trade-offs more obvious to vendors. More importantly, he strongly emphasized that the overhead caused (which can be reduced, one should note) comes in exchange of a truthful web promise of a nice isolation model. "Dangerous links"? No more!

This ambitious, thought-provoking, and even controversial research (according to the best paper award committee) really caught the audience's attention! The question & answer session started in a fun atmosphere. As Nikita Borisov (University of Illinois at Urbana-Champaign) approached the microphone, Jon quickly apologized and said he had to leave and catch a flight, because he sensed a challenging question coming around. After some laughs, Nikita mentioned he saw some similarities between the Embassies model and the one that does exist in the mobile platform, and then asked Jon if the two models would eventually become one. Jon replied that he definitively sees convergence there, since the mobile world is being pushed towards the right user model. However, he thinks all the opportunities of this model are not being explored, since mobile apps do not depend on a clean and narrow execution interface. Someone (not identified) asked about the effectiveness of web-indexing in this new model, and the burden it would cause to vendors such as Google and Yahoo!. Jon answered that this is a reasonable aspect to be worried about, but said that while web app vendors can go anywhere they want (by using any shared libraries they please), they would still attach to popular transit protocols, and also expose interactions one will be able to sniff on. Lakshminarayanan Subramanian (New York University) proposed to take the work in a different way, and asked if there is a problem on how web pages should be designed. Jon suggested that a way one can look at this work is asking why the web API developers use to design their pages must be bounded to the browser, instead of being just software libraries they are free to choose. Jon said it is inevitable there will be complexity in the stack used to design web pages. The advantage is that web developers will be free to make choices over that complexity.

Recommended reading for Software Defined Networking

This forum is probably best suited to answer this question. If I were to start reading up on Software Defined Networking as a beginning graduate student, where would I start ? To be concrete, if I had to pick five papers/videos/white papers to read/watch, what would they be ? At the end, I hope to be reasonably well versed with SDN concepts so as to carry on an intelligent conversation with someone conducting research in the area.

My hope is that once we have several opinions, I can aggregate them into a recommended reading list.

A Report on NSDI'13: P3: Toward Privacy-Preserving Photo Sharing

This is a report of the presentation done by Moo-Ryong Ra on 2013-04-05. Paper co-authors are Moo-Ryong Ra, Ramesh Govindan, and Antonio Ortega, University of Southern California.

 Cloud-based photo sharing service providers (PSPs) are very popular. However, there are a number of privacy concerns on the way sharing services are currently provisioned. In his talk, Moo-Ryong Ra argued that shared photos may be over-exposed, either by accident or because poor PSP system design. He also mentioned that the PSP itself may use inference techniques to extract information from shared photos. In other words, one can trust the (mobile) device, but cannot fully trust on everything else (e.g. the network and the PSPs).

On one hand, these privacy concerns are real. Moo-Ryong showed several news headlines that reported privacy issues with Photobucket, Facebook, and Instagram. On the other hand, PSPs provide valuable and useful services to users: a shared photo may be adapted to the various types of devices that see these photos (smart-phones, computers, etc), and perform image quality processing. The only question is: can we protect users' privacy while still performing cloud-side image transformation? The answer: yes, we can. In the remainder of his talk, Moo-Ryong described P3, a privacy-preserving photo encoding algorithm. The algorithm extracts and encrypts a small part of the photo that contains significant visual information (the "secret part"), while preserving the larger part (the "public part"), which contains no significant information, in a standards-compatible format. With P3, PSPs can still provide their services without being required to redesign their systems.

P3 concentrates on JPEG images, and exploits the fact that DCT (Discrete Cosine Transform) coefficients of natural images are sparse, with a few coefficients holding most of the useful information. To extract the "secret part", P3 encodes the most significant bits of the most important coefficients; the remaining coefficients (and the least significant bits of the most important ones) form the "public part". There is a challenge, however: how to reconstruct the original image out of the secret and public parts? If the public part has not been modified, a straightforward series of linear operations can reconstruct the image. In case it has been modified, the PSP must also send the linear operator used for processing it. Along the talk, Moo-Ryong discussed the (easy-to-deploy) architecture of P3, provided evidences regarding its privacy-preserving aspect (through a set of examples and evaluation experiments), and showed that it causes minimal storage overhead (in the worst case, the image file-size increased at most 20%). Regarding the privacy-preserving aspect, Moo-Ryong showed that P3 virtually broke face recognition algorithms: the number of successful face recognitions in the public part was decreased significantly.

Nikita Borisov (University of Illinois at Urbana-Champaign) started the question & answer session by asking if one can obtain the original picture solely with the secret part. Moo-Ryong answered negatively, saying that one needs both parts to obtain the original picture. In a follow up, Nikita posed the situation in which the P2P is fully malicious. Moo-Ryong said that in this particular case P3 is broken. However, it was emphasized that in this case it is a functionality problem rather than a privacy problem -- the P2P will not be able to do anything malicious without the secret part anyway. The session chair (Krishna Gummadi, Max Planck Institute for Software Systems) asked for the high-level intuition as for why the smallest part of the image contained most of the visual information, whereas the larger part of the image contained almost none information. Moo-Ryong replied that this is related to why JPEG works, and revisited the discussion about the process of extracting the secret part from the image. Finally, someone (not identified) asked about the privacy guarantees of P3. Moo-Ryong replied that they are still trying to prove privacy guarantees of P3 using mathematical tools. However, they are unaware of any techniques that could break the algorithm.

A Report on NSDI'13: πBox: A Platform for Privacy-Preserving Apps

Updated on 2013-04-10. This is a report of the presentation done by Sangmin Lee on 2013-04-05. Paper co-authors are Sangmin Lee, Edmund L. Wong, Deepak Goel, Mike Dahlin, and Vitaly Shmatikov, The University of Texas at Austin.

Do you pay attention to access permission requests when installing applications on your mobile devices? In his talk, Sangmin Lee pointed out a recent study which has shown that only 17% of users do. More alarmingly, just 3% of them actually fully understand these requests. But even though users read and fully understand these requests, there is no guarantee that apps will actually comply to them -- in fact, there are various evidences some apps out there are misusing users' private data! You may choose to believe that app publishers will not misuse your private data; but in which one of the 300,000+ publishers will you actually trust? Yes, the scenario is pretty obscure for users' privacy, and it strongly suggests that existing countermeasures to protect users' privacy are not working.

Sangmin proposed to shift the users' trust from the 300,000+ app publishers to a few major brands, such as Google, Microsoft, Apple, and Amazon.  In addition to the fact that one already has to trust these companies to use their device anyway, they also have a reputation to maintain, and thus more incentive to work correctly. The key to realize the proposed shift? πBox: a framework that combines app confinement through sandboxes and control channels to provide explicit and useful privacy guarantees.

Sangmin explained that πBox provides a per-user, per-app sandbox confinement. All users' data stays inside the sandbox along with an app instance, and the sandbox prevents the app from leaking the data. The sandboxes use a model which makes them span the users' device and the cloud -- and thus use resources from both the device and the cloud. Private vaults (which are in both the device and the cloud) and content storages are provided for storing user and app specific data, respectively. Both are secured to prevent privacy violation. The aggregate channels provide communication capabilities between the app and its publisher, and use differential privacy to introduce random noise and thus bound information leakage. Finally, The sharing channel allows one to have control of "when" and "with whom" to share, but provides weak guarantees on "what to share". However, it  makes it difficult for an adversary to access users private data directly. Sangmin mentioned though that shared channels are not entirely secure (for example, photo sharing remains subject to steganography). Along with a three-level classification model (green, yellow, and red), πBox enables to fine-grain control which security features will be enabled for each app, and provides explicit privacy guarantees users can rely on. Sangmin closed the talk arguing that real, existing applications can benefit from πBox, and highlighting that overhead is low: only a few lines of code were required to change in existing, popular apps; and the measured information throughput was marginally degraded.

During the question & answer session, Fengyuan Xu (Collegue of Willian and Mary) showed himself concerned about the burden πBox will place on users (who will have to decide what, when, and with whom contents will be shared, for example). Sangmin argued that there will be no much difference from how it is currently done, and that apps will provide support for that decision process. In a follow up question, Fengyuan asked if πBox is vulnerable to attacks that use covert channels. Sangmin replied that it depends on the implementation of sandboxes and the design of  πBox is orthogonal. He added that if there are any improvements on building better sandboxes, πBox can benefit from it by using it. Fengyuan then asked if πBox is something like a platform, in which you can plug-in other schemes to make it more secure. Sangmin simply replied that yes, it is. Yan Chen (Northwestern University) asked what aggregation channels can support. Sangmin replied that one big goal of aggregate channels is to provide information to app provides without violating users' privacy. He continued mentioning some examples of apps and how they could use aggregate channels to export information to app publishers. Yan then asked if πBox does protect social network information (i.e. the list of friends to whom one is sharing photos) from potential spammers. Sangmin replied that yes, it does.

Exploiting Your Social Network Through Delay Tolerant Talk Prep (DTTP)

What I Tried - Delay-Tolerant Talk Prep (DTTP)

While prepping for my NSDI talk, I ran into a variety of (relatively uninteresting) problems scheduling dry runs.  So I tried something new (to me and folks with whom I've spoken about it) - I recorded myself giving versions of my talk, distributed it to my social network, got feedback, and iterated.  While it started as a standard kludge, after thinking about it a bit more, it struck me that there might be more to it - so this post shares my thoughts on that, some questions to (hopefully) start up an interesting discussion, and details as to precisely how I implemented DTTP (tutorial below).  My hope is this will be of interest to the community and helpful to others (particularly those of us who are early in our career trajectories) in approaching what can be one of the most important and challenging parts of research - conveying one's ideas effectively in a live format.  

Why DTTP could be more than a kludge

Let's briefly consider some of the drawbacks of current talk prep mechanisms.  The three dominant ones which come to mind are:

1. A live dry-run: closest to what you'll actually be doing when you give your talk - both in terms of the delivery and interaction with an audience (answering questions, debugging verbal and non-verbal delivery/presentation issues).  But difficult to schedule and you are likely to get lots of overlapping feedback.  Its difficult to include colleagues who aren't geographically convenient - thus you can't make optimal use of your professional social network.  Moreover, most of the folks you'll get to attend will be from your research group and thus already fairly familiar with the work (and not much like your audience, most of whom will likely be seeing your work for the first time). 
2. A sit down one-on-one, walk through each slide: Very targeted, but requires a colleague who is willing to invest a lot of time - again won't leverage the power of your social network - and you won't get many of these for any given talk.  Doesn't necessarily give you a great idea of how things will actually flow.  
3. Asynchronous sending-out-a-slide-deck, receive written and/or verbal responses: Much lighter weight, fewer scheduling issues, get geography-independent feedback, and finally a much more continuous feedback loop (w/ correspondingly less overlapping feedback if you iterate quickly)!  But lots of context is lost. E.g., slides w/o narration can be confusing - especially to colleagues who aren't very familiar with your work, restricting again how much of your social network can be leveraged.  Moreover the feedback you get might be "say these five things in your verbal delivery" (which you'd already planned to say), instead of information that will actually be helpful to you.

Considered in this context, DTTP provides another point in the talk preparation mechanism design space.  By utilizing electronic capture, and delay tolerant dissemination, you get all the benefits of (3), but b/c you've included the full audio narrative and visual slide flow you get many of the advantages of (1) without its drawbacks.  Further, you make it possible to obtain meaningful feedback from far-flung colleagues who know relatively little about your work (and thus match your likely audience better) - greatly expanding the portion of your social network you can effectively leverage. 

Of course, what you don't get is the experience of speaking in front of a live audience including practice answering questions on the spot.  Nor will you get (at least with my method of recording) useful feedback on non-verbal presentation issues (which can be just as important as the verbal ones).  So while I definitely wouldn't recommend DTTP as a replacement for in person dry runs (particularly for those who are just starting out), I think it could definitely be a good option to add to our talk prep toolbox. 

What do you think?  Directly below are a couple of issues I've been mulling, after which I provide a tutorial for implementing DTTP on Mac OS X (anyone want to write one for Windows, Linux, or Haiku?)

Some questions for discussion

For what types of talk does this type of prep make sense?

• uninterrupted conference talk (good fit w/ recording)

• research group presentation, w/ lots of interruptions and possibly even dialogue expected (a less good fit, but still worthwhile?)

How wide a net to cast?

• Wide: wider range of feedback (less echo chamber), higher probability of smoother feedback loop. 

• Narrow: you might not want folks who know you less well and are still forming their opinion of you seeing you at less than your best yourself.  Making sure you don't make folks you know less well feel imposed upon?

Time-dependency?

•  Maybe increase the size of your net as your talk gets better?

• Maybe ping more junior colleagues (e.g., fellow students) first to fix obvious flaws to obtain greatest value density of feedback from the scarcer/more-valuable resources of more senior colleagues? 

Where does this fit with other talk prep mechanisms / when should it be done?

• Early on?  Feedback early is always good, but maybe it's better to iterate on an outline first.

• In the middle? Build up to a version that's worth getting spending a large group's time on.

• Close to the talk?  To fine tune.

How I Did It - Tutorial

Dependencies

• A reasonably up-to-date version of Mac OS X 
• Microsoft Powerpoint for Mac 2011
• SoundFlower - a "Free Inter-application Audio Routing Utility"
• Quicktime Player 10.2

Focus

On current students, though hopefully useful for others as well.  Many of the advice points may seem obvious, particularly to those who have already progressed in their research career.   The technical points are basically one way of obtaining a pretty good video with fairly standard tools (which is way more of a pain than it should be).

Steps

Step 1) Record yourself giving the talk (make a copy of your talk file to do this, b/c after you've done the recording the PowerPoint file will be bloated - and you don't want to have to go through and deleted the recorded audio from each page)

Step 2) Create a Movie from that recording. 

Step 2a) Set audio output to Soundflower (2ch)

Step 2b) Set Quicktime to use Soundflower (2ch) as input

Step 2c) Select the area to be recorded, start recording, and then play slide show starting from the first slide.  Don't forget to make sure "Play Narrations" and "Use Timings" are selected (also don't forget to disable these before actually giving your talk in person!).

Step 2d)  Walk away, set a timer to remind you when the playback will be done.  Take a break, put your feet up - you deserve it!

Step 2e)  Stop the recording, trim any extra recorded material at the beginning and end of your recording, save it with a clever and descriptive name (use a version number).  Also, don't forget to undo step 2a, resetting audio output to "Internal Speakers" or you'll find your video (and everything else) on your computer has no audio!

Step 3) Upload it to a read-only, private, shared folder which you've provided to your social network - I used SkyDrive.  Include the pre-recorded slides (so your friends and colleagues don't have to download a huge file if they want to do some marking up)

Step 4) Send out an email telling your social network what you've done.  Ask for their feedback and the meanest nastiest questions they can think of asking you.

Step 5) Wait for feedback, while doing something other than fretting about what you'll hear.

Step 6) Consider received feedback carefully, really thank each person who responded (after all they took time out of their undoubtedly busy schedules for you!), and revise accordingly.  If revision will be significant, ping your social network and let everyone know you've gotten enough feedback to realize how much better a version you will have in X hours, so, if-all-things-are-equal-for-them, please wait while you get that done.

Step 7) GOTO Step 1

A Report on NSDI'13:SoNIC: Precise Realtime Software Access and Control of Wired Networks

This is a summary of the presentation by Ki Suh Lee and the question and answer section that followed. If I have misattributed a question, let me know in the comments and I will fix.

Summary

Measuring and controlling interpacket delays can enable better understanding of network characteristics and new applications. For example, measuring these interpacket delays can give better characterization of network traffic, and controlling the interpacket delays can create new covert channels. Unfortunately, current techniques are insufficient to measure these interpacket delays precisely. However, the precision of network measurements could be improved with access to the PHY layer: Counting the number of PHY layer idle characters between packets can give network research applications sub-nanosecond precision.

Manipulating idle characters requires accessing the PHY, which is currently a black box that hides information (including idle character counts). One approach could use something like BiFocals, which uses physics equipment to measure the PHY layer. Unfortunately, this equipment is very expensive ($500k) and only works off-line. Since there is limited access to hardware, the authors propose using software to count idle characters.

The authors implement their approach as a new platform called SoNIC, which ports some of the PHY layer functionality of a 10 Gbps Ethernet link into software.  Specifically, SoNIC ports all of the functionality that manipulates bits into software (everything above the scrambler of the physical coding sublayer), but keeps the functions that translate bits into signals into hardware. This split requires high-performance software, which SoNIC implements using three techniques.  (1) SoNIC software threads are pinned to an individual CPU core. (2) Use polling and an optimized DMA rather than interrupts to interface with the network device. (3) Tightly optimize software (e.g., replace loops with bitwise operators).

These techniques give SoNIC precise measurement and control of interpacket delay and interpacket gaps, which allowed the authors to implement several functions that were previously impossible (including a new timing channel with data rates up to 250 kbps that is undetectable by current techniques).

Question and answer

Dong Zhou, Carnegie Mellon University

DZ: Are there any limitations to applications you can support? SoNIC seems to require a lot of CPU.

KSL: Yes, the applications must be able to work with data faster than 10 Gbps using the remaining resources of the system.

Nikita Borisov, University of Illinois Urbana-Champaign

NB: It's cool that your timing channel attack works even if there are unmodified routers along the path. Did you consider cross traffic while evaluating this attack?

KSL: Yes, we did, but our paper uses only unloaded routers to demonstrate feasibility. We're currently looking at implementing this attack on a real network with cross traffic.

Hongyi Zeng, Stanford University

HZ: This is a cool use of FPGAs. What are the requirements for an FPGA to implement SoNIC?

KSL: The FPGA must have transceivers that can support more than 10.3 Gbps.

HZ: You use a CDF when reporting the interpacket gap. Why is this a CDF, what could cause errors in the hardware.

KSL: SoNIC has no error because it's timestamping at the lowest layer.  Even within the kernel there's a lot of overhead: other tasks, interrupts, etc.

HZ: What about hardware timestamps (say in the NIC)?

KSL: Hardware clocks have lower resolution than our techniques. What's cool about SoNIC is that we get really precise timing from counting the idle characters.

Junda Liu, Google

JL: Every port has 5 dedicated kernel threads, does this require 5 cores?

KSL: Yes, we pin each thread to its own core, but the other cores are shared. More CPU intensive applications (e.g., full packet capture which requires disk access) are impossible right now because of application requirements (must handle > 10 Gbps of data)

A Report on NSDI'13: Wire Speed Name Lookup: A GPU-based Approach

This is a summary of the presentation by Bin Liu and the question and answer section that followed. If I have misattributed a question, let me know in the comments and I will fix.

Summary

Name lookup is an important problem, both in the context of networking and in domains outside of networking. This paper focuses on a particular use case of name lookup: routing in a content-centric networking.  Content-centric networking uses hierarchical names (e.g., /com/google/maps) of arbitrary length rather than fixed-length addresses to route packets. In order to be useful, content-centric networking needs a lookup mechanism that supports longest prefix matching, has high throughput (saturate a 100 Gbps Ethernet link), and low latency (100 microseconds per lookup).

Satisfying these constraints requires a carefully designed data structure that can work efficiently with GPU hardware. Some straightforward approaches won't work: character tries and state transition tables require too much memory.  Aligned transition arrays (ATAs) can greatly compact the information of a transition table, but they don't support incremental update and are still inefficient (each character must be looked up separately). To address both of these concerns, the authors implement multi-ATAs, which can use multiple characters in each transition and support incremental update.

There are some challenges to implementing multi-ATAs on a hybrid CPU-GPU platform: the PCI-e bus and GPU processor are limiting factors in achieving both high-throughput and low latency. Two techniques are used to improve performance. First, pipelining lookup and data transfer improves PCI-e bus and GPU processor utilization. Second, interweaving the memory layout of the input names in GPU memory reduces the memory accesses of threads, improving performance.

The implementation of the multi-ATA data structure performs well on the CPU-GPU platform. Using the multi-ATA requires two orders of magnitude less space than a baseline state transition table. The techniques to efficiently use the GPU allow up to ~70 million searches per second, an order of magnitude more than a state transition table. Furthermore, these techniques can saturate a 100 Gbps link with latencies of less than 100 microseconds per search.

Question and answer

Dong Zhou, Carnegie Mellon University

  DZ: In your evaluation, you worked only on a local machine, but you didn't actually transfer data onto a NIC. Is this a fair comparison with other systems?

  BL: Yes, we only work within the context of a single machine. We're looking at using the NIC in future work.

  DZ: Using the NIC will take additional CPU cycles, will the competing CPU used affect your results?

  BL: This is something we need to address, but we think that other hardware acceleration could help.

Srimat Chakradhar, NEC Labs

  SC: Right now you are keeping the entire state table on the GPU, will this be possible as state tables get larger?

  BL: Currently, we have a 10 million entry table on the GPU, which uses about 1/3 of the GPU’s external memory for a single GPU processor chip, actually we have two processor chips on the GTX590 board. We estimate that we could keep a 60 million entry table on this kind of GPU. Newer GPUs have more space, and we think

  that we could keep a 120 million entry table on the new hardware.

Michael Freedman, Princeton University

  MF: In the multi-ATA table it looks like collisions map into a second table. This seems to imply that lookups will require multiple accesses, is that the case?

  BL: No, we have a proof in the paper.

  MF: Did you consider comparing with other hashing algorithms (e.g., cuckoo hashing)?

  BL: No, this is a much more simple lookup algorithm

Gun Sirer, Cornell Univerity

  GS: It seems like I should be mining BitCoins with my GPUs. Right now, this CCN routing lacks security (e.g., self-verifying names). Lack of security as a first-class primitive plagues DNS today. How will your system address security challenges?

  BL: We haven't considered that specifically, but it's definitely the future work.

A Report on NSDI'13: Software Defined Traffic Measurement with OpenSketch

Updated on 2013-04-10. This is a report of the presentation done by Lavanya Jose on 2013-04-03. Paper co-authors are Minlan Yu, University of Southern California; Lavanya Jose, Princeton University; Rui Miao, University of Southern California.

Lavanya Jose started her presentation enumerating some questions existing measurement technologies are either unable to answer, or would require a prohibitive amount of resources to do so. Who is sending a lot of packets to a specific subnet, how are flow size distributions, is there anyone doing a port scan, etc. are some of the questions. NetFlow cannot answer many of the questions posed. For example, NetFlow typically does not sample light flows, such as port-scanning flows. Increasing sampling rate is an option, but then it becomes resource-consuming. Streaming algorithms could be used as well, though each algorithm answers one question only.

Given the above, the question now is: what measurement architecture can answer all the questions? The answer is: OpenSketch! OpenSketch is a software defined traffic measurement architecture which separates the measurement control and data-plane functions, and uses sketches (Count Min Sketch) as building blocks to provide a generic and efficient measurement API. Lavanya discussed about the basics of sketches, highlighting the trade-off between memory consumption and accuracy of the resulting measures. The error can be estimated, which thus can indicate the degree of confidence one can have on the accuracy of the obtained measures.

There is an issue with sketches, however: each one can estimate only one function. To solve this, Lavanya indicated a solution based on a three stage pipeline that can support many sketches. The first stage in this pipeline is to hash the packet (based on the header), then classify it (based on the packet header and hash values), and finally update a set of counters based on the results of the previous stages. This pipeline can be configured in the controller plane in order to obtain the required measures and implement the measurement tasks to solve the questions initially posed. Lavanya continued the presentation discussing possible strategies for implementing sketches with the pipeline, how one can provision the pipeline so that one can implement multiple, different sketches, and discussed evaluation results. The main take-away? OpenSketch truly adheres to the SDN philosophy: separate the measurement control and data-plane functions, and make measurement in switches efficient and easy.

After the presentation, the session chair (Dejan Kostić, Institute IMDEA Networks) asked about the possibility of achieving throughput of 10 Gbps. Lavanya said it is possible, but sequentially updating the SRAM might become a bottleneck for tasks which update many counters per-packet. The session chair continued by asking about the limitations of OpenSketch. Lavanya replied that the data plane is somewhat limited so that OpenSketch can be made simple enough to implement with commodity hardware and operate at line rate. For example, some sketches can not be implemented as they use more complex data structures (such as binary trees or heaps) not provided by the data plane.

A Report on NSDI'13: VeriFlow: Verifying Network-Wide Invariants in Real Time

Updated on 2013-04-10. This is a report of the presentation done by Ahmed Khurshid on 2013-04-03. Paper co-authors are Ahmed Khurshid, Xuan Zou, Wenxuan Zhou, Matthew Caesar, and P. Brighten Godfrey, University of Illinois at Urbana-Champaign.

Tons of devices, running different protocols, from various types and vendors. Intricate relationship between devices, with several operators configuring them. This is just a glimpse on the existing challenges that Ahmed Khurshid enumerated for networking debugging. These challenges make it difficult for one to test every possible scenario. As a consequence, bugs may go hidden and affect production networks in a variety of ways (e.g., degrading their performance and/or making them more prone to attacks).

Ahmed enumerated some existing network debugging techniques, e.g., traffic flow monitoring and configuration verification. With regard to configuration verification, he emphasized a crucial problem: the only input taken is configuration scripts. Everything else (control-plane state, data-plane state, and network behavior) is predicted. To bridge this gap, Ahmed introduced a novel approach: data-plane verification. It considers data-plane state as input for the verification process, thus making it less dependent on predictions, and closer to actual network behavior. He also emphasized on running this verification task in real time (in contrast to existing approaches such as FlowChecker, Anteater, and Header Space Analysis), as the network evolves.

This approach brings us to VeriFlow, a tool for checking network-wide invariants in real time. VeriFlow introduces a layer between the controller and devices in a Software-Defined Network (SDN), thus enabling the verification of rules before they are deployed in the network. In summary, VeriFlow operates by intercepting new rules, and building the equivalence classes associated to them -- a set of packets that are affected by the rule. For each equivalence class computed, VeriFlow generates individual forwarding graphs, which model the forwarding behavior of the packets in the equivalence class through the network. Finally, VeriFlow runs custom queries to find problems. VeriFlow has a set of built-in queries to verify certain invariants. However, it also exposes an API for writing custom invariant checkers. During his talk, Ahmed discussed extensively on the computation of equivalence classes (which uses multi-dimensional prefix tries), always highlighting the aspects that make it an efficient and quick process. From the set of experiments carried out, one of the main take-away was that VeriFlow checked 97.8% of the updates from a real BGP trace within 1 millisecond. Some updates took longer, however, because of the larger number of equivalence classes affected by new rules.

The question & answer session of this paper had some quite good activity! Sanjay Rao (Purdue University) asked about the coverage of error detection -- the types of errors VeriFlow cannot detect. Ahmed argued that if the problem is visible at the data plane, it can be detected. Rao continued by asking about errors that span to multiple devices. Ahmed replied that yes, these type of errors can be captured as well, since VeriFlow has a global view of the network. Yan Chen (Northwestern University) asked if VeriFlow is applicable to inter-domain routing. Ahmed replied that yes, VeriFlow can be used in this context as long as the controller is able to receive reports about changes. He also mentioned that the accuracy of the detection depends on receiving updates in the network change in real time. Masoud Moshref (University of Southern California) asked whether one can reorder rules in order to improve VeriFlow's performance. Ahmed answered they have not looked at this option yet, but they wish to investigate it. He also said that as VeriFlow targets real-time processing of the stream of rules coming from the controller, it may not have the liberty to reorder those. Takeru Inoue (Japan Science and Technology Agency) asked about VeriFlow's memory requirements for verification. Ahmed replied it is expensive; for a BGP experiment shown in the evaluation section, VeriFlow took 6 GB of memory.

A Report on NSDI'13: Composing Software Defined Networks

Updated on 2013-04-11. This is a report of the presentation done by Joshua Reich on 2013-04-03. Paper co-authors are Christopher Monsanto and Joshua Reich, Princeton University; Nate Foster, Cornell University; Jennifer Rexford and David Walker, Princeton University. Paper received Community Award.

Do you want to build a robust, large, complex network system using OpenFlow? Fine, you can do it -- but it is going to be cumbersome, time-consuming, and even error-prone. In a brief example, Joshua Reich described how complex it is currently to implement even simple sequential composition of logic such as simple load balancing and routing functions. The problem is that existing platforms for network programming only expose part of the network, lacking proper support for enabling the programming of various aspects in an integrated fashion. Building network applications using existing frameworks is pretty much like building complex software using assembly language, he said.

It was after drawing such a picture of the current state-of-the-art that Joshua presented Pyretic, a modular and intuitive language (and system) for enabling network programmers to build sophisticated network traffic management applications. Pyretic approaches the problem of designing complex network traffic management applications by providing three abstractions to programmers: policy abstraction, network abstraction, and packet abstraction. The first one enables programmers to use composition operators (sequential and parallel), which opens the door for doing all sorts of functional composition. The network abstraction lies on top of that, enabling programmers to decompose network software logic based on topologies. Finally, the packet abstraction provides extensive headers, which form the foundation for the previous abstractions.

Along the talk, Joshua navigated through a series of examples that highlighted the potentialities provided by each kind of abstraction -- which now enables network programmers to focus on the meaning of their applications, instead of concentrating on low level details. "One single line, absolutely precise", he said. He also emphasized that Pyretic captures the full power of OpenFlow, by providing one high level policy for each natively supported policy, and that Pyretic can be used to implement both static and dynamic policies -- a MAC-learning example described the power of these policies. Joshua concluded his technical discussion by sketching the implementation of the topology abstraction function in the context of a one-big-switch transformation example. Finally, he encouraged the audience to experience the full power of Pyretic by referring to the project website: http://www.frenetic-lang.org/pyretic.

The paper and presentation really caught the audience's attention! Srimat Chakradhar (NEC Labs Princeton) asked about the things one can do with OpenFlow but cannot with Pyretic. Joshua responded they did not find any limitations regarding this aspect. In terms of capabilities, Joshua does not think there is anything one can implement with OpenFlow but not with Pyretic, though he noted that what one does give up is the ability to finely manage table resource usage -- much in the same way that a Java programmer can no longer mange physical registers and memory. Chakradhar also asked about impact on end-to-end latency. Joshua replied that the current prototype is mostly an interpreter, but that the micro-flow compiler that will be released shortly one would have the same performance. Rajesh Nishtala (Facebook) asked about the impact on queuing behavior. Joshua responded that they haven't yet done this testing, but expect performance comparable to other systems.

What can't OpenFlow do?

Today's talks about software-defined networking have led to some lively hallway discussions about OpenFlow and the research it jumpstarts, by separating the control and data planes of a router or switch and exposing a well-defined interface between them.

At the risk of making this an all-SDN blog, I thought it would be instructive to try to understand OpenFlow by the light of what it isn't. That is: What kinds of practical networking policies can't OpenFlow currently express?

My understanding is that this list would include:

• RED, BLUE, or CoDel
• ensuring that contending endpoints or flows share the capacity of a congested link equally (e.g. with per-user queueing)
• serving as an endpoint for an IPIP or IPsec tunnel or VPN
• specifying that Skype's UDP datagrams should jump to the front of the line waiting to egress on a port
• limiting queue lengths to control "bufferbloat"
• ...?

This is not my area, and I may be wrong here. In any event I don't mean to suggest that OpenFlow is somehow inappropriate for its actual intended uses.

But I do wonder whether the phrase "software-defined networking" has turned out to be a bit broad compared with what the practitioners mean when they use that term.

NSDI 2013 Opening Remarks

Jeff Mogul, NSDI co-chair, opened the conference by telling attendees
that there were 170 paper submissions, and each paper received three
first round reviews. About half the papers made it into the second
round, and also received three or four reviews. By the time there
PC meeting occurred, there were 64 papers left. In total, each PC
member performed 25.8 reviews on average. In the end, 38 papers
were accepted, more than usual. Because of this, each presentation
can only be 20 minutes, including questions at the end. And by the
end of the first session, things were going well.

Jeff also pointed out that, with 250 attendees, this is the
almost the largest NSDI ever. Jeff then singled out three PC committee
members for work above and beyond the 'call of duty':
Jeff Chase, James Mickens, and Renata Teixeira.

Glancing at the hot topics graphic, their most mentioned terms were:
network, data, system, applications, paper, power. Jeff magnified
a small section of the chart, where the words "Looking for work"
were visible as a significant topic. Finally, Jeff mentioned that
Ratul Mahajan and Ion Stoica would be the co-chairs for NSDI 2014.

Nick Feamster, the other co-chair, took over for the presentation
of awards. There were two Best Paper and two Community awards:

Embassies: Radically Refactoring the Web
Jon Howell, Bryan Parno, and John R. Douceur, Microsoft Research

F10: A Fault-Tolerant Engineered Network
Vincent Liu, Daniel Halperin, Arvind Krishnamurthy, and Thomas Anderson,
University of Washington

Composing Software Defined Networks
Christopher Monsanto and Joshua Reich, Princeton University; Nate Foster,
Cornell University; Jennifer Rexford and David Walker, Princeton University

Expanding Rural Cellular Networks with Virtual Coverage
Kurtis Heimerl and Kashif Ali, University of California, Berkeley;
Joshua Blumenstock, University of Washington; Brian Gawalt and Eric Brewer,
University of California, Berkeley

Howell et al received their Best Paper award for being ambitous,
thought-provoking and even controversial in their paper. Liu et al
got their award for applying simple effective insights to the
co-design of network topology and protocols and evaluating them well.

Community Awards were given to paper authors for contributions to the
community above and beyond the typical paper. Monsanto et al received
their award for releasing the code release of their software, which
the award committee believed would be useful and built upon by the
Software Defined Networking community.  Heimerl et al received their
community award on the basis that this will help with rural cellular
deployments.

The magic of V-edge

"At a first glance, this paper felt like magic," says a reviewer quoted in Dave Levin's summary of the V-edge paper by Xu et al.

It's awesome that a novel and elegant technique for measuring the drain of smartphone batteries would be discovered by researchers in computer systems. (Game on, chemical and electrical engineers.)

One thing surprised me: Fengyan Xu's slides tell us that V-edge "Works on most phones." But the conference version of the paper says, "We conduct all experiments on a Nexus S smartphone running Android 4.0." (Sec. 8.1; some battery profiling was also done on Galaxy Nexus batteries.) The 4% figure for average difference seems to apply to the Nexus S specifically.

To what extent have these results been generalized (or can they be generalized) to more than one model of smartphone? This seems like such an exciting way to get more reliable per-program accounting of power usage for zillions of smartphone apps and users. App stores should report this information.

Is software defined networking really just OpenFlow?

Pyretic's Q&A had an interesting question: Is there anything you can do in OpenFlow that you can't do in Pyretic?

This question digs deeply into Pyretic's capabilities, but we don't have a formal framework to compare the capabilities of different SDN programming models, so any negative answer ("No, they are equally powerful") is hard to justify.

Are we (as a community) missing the opportunity to formally define control plane and data plane functionality, perhaps creating a hierarchy of capabilities and examining the trade-offs in implementing those capabilities? Or are we just excited to have a more powerful leg to stand on (OpenFlow) and using that to create cool systems (e.g., NSDI 2013's first session)?

There is some work questioning the OpenFlow abstraction and providing alternate SDN abstractions (e.g., DevoFlow), but I don't know of any formalism to compare functionality. Am I new to the area and missing something important?

SDN confusion

I found the Monsanto et al. paper (Composing Software Defined Networks) fascinating, in part because it forced me to continue confronting how little I "get" about software-defined networking. I'm grateful to Aditya Akella for his very readable public summary for non-experts -- this is a great innovation that I hope NSDI continues and other conferences adopt.

Two things about this paper stuck out for me:

1. The suggestion that the authors have outgrown the OpenFlow interface, and in order to implement Pyretic they needed a controller-maintained mapping layer on top of OpenFlow:

   Ideally, OpenFlow switches would support our extended packet model directly, but they do not. Our run-time system is responsible for bridging the gap between the abstract model and the OpenFlow-supported packets that traverse the network. It does so by generating a unique identifier that corresponds to a unique set of non-OpenFlow-compliant portions of the packet (i.e., all virtual fields and everything but the top of the stack in an OpenFlow-compliant field). This identifier is stored in spare bits in the packet. [Any source of spare bits (e.g., MPLS labels) could be used. Our current implementation uses the VLAN field.] Our run-time system manages a table that stores the mapping between unique ids and extended data.

   To this non-expert, that raises a bunch of questions. To what extent does OpenFlow draw the boundary between hardware- and software-defined networking in the right place, to enable this kind of high-end research into elegant abstractions? If every configuration of virtual fields is a totally separate flow as far as the switch is concerned, what are the performance implications of requiring the switch to query the controller and maintain an entry for each separate "flow"? The VLAN field is only 12 bits -- surely this constrains the complexity of the flows or the rules that can exist on the network? The state could be enlarged another 20 bits by adding in the MPLS label field, but is it realistic to have 2^32 flow table entries in the switch anyway?
   
   
2. The paper highlights an "interesting twist" (sec. 5.2) that "the correct processing order of load balancer and firewall turns out to be direction-dependent." In other words, incoming packets need to be firewalled and then load-balanced, while packets headed in the opposite direction need the same steps to be un-applied in the opposite order. The example application solves this with a conditional check:
   

   fwlb = if_(from_client, afw >> alb, alb >> afw) 

   But naively, shouldn't it be "obvious" that if we compose a load-balanced service inside a firewalled subnetwork, the order that transformations are applied for incoming packets must be reversed when those same transformations are removed from outgoing packets? This is the case any time we invert the composition of two functions! Given that the authors here are proposing a new and powerful system of high-level abstractions, why should the programmer have to worry about this detail explicitly?
   
   I think the issue may be that this paper is not about the composability of networks (whose gateways may apply transformations and enforce rules), but about the composability of packet-processing policies. But I am not, frankly, very sure I really got it. There may be considerable subtleties abound as the SDN folks continue searching for the right abstractions to elegantly control the behavior of large networks.

Arrival

This blogger made it to the conference hotel late Tuesday night. Hailing originally from the Chicago suburbs myself (and a sometimes visitor to the Yorktown mall!), I know this to be an auspicious place to launch our experiment in group-blogging the NSDI conference and beyond.

We don't know what this venue will become, but it will surely be shaped by the people who choose to participate. Anybody who is attending NSDI or publishing here will be an asset to this community and is encouraged to email <signup at layer9.org> for an account and to join in.

My own hope is that this becomes a venue where networking & systems results are discussed and put in context, both by their authors and others who care, because for me, it is the conversation and the back-and-forth that make research interesting. An eminent computer science professor recently told me, not cynically but ruefully, that the average number of readers of a systems paper was less than 4. Let us prove this person wrong.

In a past life, I was a newspaper reporter who covered medical conferences. There was always a certain frisson the night before, because nobody (except for the reporters under embargo and the authors and their corporate sponsors) knew what the results of the high-stakes late-breaking clinical trials would be. Here at NSDI, things are a little different, thanks to Usenix's policy of opening up all the papers to attendees weeks ago. For me, the frisson comes from a different place this time: this will be my first NSDI presentation, on the last day of the conference.