Blogroll! My Homepage! Berkeley NetSys!
SIGCOMM tried something new this year: they added an author response phase after the first round of reviews, allowing authors to address reviewer criticisms/concerns/questions during the review process. This is common practice in many other CS communities, but new to ours.
So, reflection time: How’d it go?
In my past submissions, I’ve had two classes of reviews where I wanted to “respond” to the reviewers.
a) Minor misunderstandings or confusions which the authors can clear up with a bit more explanation or pointing the reviewers to data they may have missed in their read-through.
b) Major misunderstandings that remind you that even a subfield like networking has a lot of breadth and you might as well be talking to a geologist about your paper rather than a networking researcher.
I can imagine that for the former class of reviews, the outcome in terms of reviewer opinion is likely to be minor - at best an upgrade from a “Weak reject” to a “weak accept” or a “weak accept” to an “accept”, etc.
I imagine in the latter class, that a 500 word author response is likely to help absolutely zilch.
But those are just imaginings - I wasn’t a reviewer and this is the first time I’ve written an author’s response. In the case of our paper, we only had responses in the (a) category - minor things we wanted to clear up by asking the reviewer to look closer at a graph or table (although a couple of the points were key to the argument for our paper). Ultimately, though, it didn’t look like the reviewers changed their opinions from the reviews we saw pre-response phase to the reviews we saw post-response phase.
However, one thing I can’t account for is the second round reviewers who read our paper and reviewed it /after/ seeing our author’s responses.
Anyway, how’d it go for everyone else? Reviewers, Authors: did you feel satisfied with the author response phase? Did the quality of the review process improve? Do you feel that author responses did anything to change the way reviewers thought about or rated a paper?
It’s been a few weeks since we launched TinyToCS to the community. Time to answer a question that I’ve been asked dozens of times since we launched: why are we doing this?! So here, I’m going relay a summary of the conversations I had with with Peter Bailis and Greg Valiant when we were planning TinyToCS.
For those of you who missed the memo: TinyToCS is a “tiny” CS publication venue, in which the core idea of the paper must be conveyed in 140-characters or less (yes, that’s the length of a tweet). Authors are allowed references, and an abstract of up to 250 words — but the abstract is only allowed to provide background on the result/core idea. The abstract is not allowed to elaborate on the result.
We think TinyToCS has a valuable role to play in the CS community.
We’re accustomed to sound-byte media. I find out about the latest news through Twitter/Facebook/My-RSS feed, and only then do I click through to read the whole article. The tech community at large disseminates a deluge of information through HackerNews, Slashdot, and the like.
The CS community doesn’t work that way. Our method of content distribution is research papers. Research papers are an important part of the scientific process and have been for hundreds of years: you present your idea, describe what you did, why, how it works, thoroughly describe it down to every last bolt and nut, and then evaluate the heck out of every aspect of it that matters. Let’s be clear about our respect for research papers. When I’m reading through related work for a project, and want to know how project X implemented system Y or exactly how algorithm Z works, 140 characters just isn’t going to cut it.
But research papers fail in some major ways: they’re slow to read (14 pages for a typical computer systems paper); they aren’t accessible to the community at large (I don’t understand the research papers that my Machine-Learning housemates publish); they’re slow to publish (months pass between a finding/result and when the work is actually presented at a conference); and they’re not aggregated in a timely way (my housemates found out about the latest and greatest in Software Defined Networking from New York Times article a few months back - SDN has been going on for years now at Berkeley).
There are a number of great efforts to resolve parts of these problems, most notably, Communications of the ACM. CACM is great. I subscribe to it, as do many of my fellow PC members. But CACM doesn’t cover the time problem (articles in CACM come out even later than the conference edition), they’re a lot of work for the authors to put together, and because they’re curated “best-of” sets of work they don’t cover the play-by-play of what’s going on in the field. Contrast this to my RSS feed, which has more headlines than I can possibly read on more topics in industry than I quite understand, that I (as a 21st century young person) am adept at quick-filtering and deciding what to dig deeper on and what to skip.
My generation is used to a fast-paced influx of information that we can quick-filter in to information we want to dig deeper on. There is no such medium for the CS community.
TinyToCS, starting this July, will fill this gap. Submission cycles will be every three months. TinyToCS focuses on the sound bytes to draw readers in and convey key ideas, but provides background and references to those who want to dig deeper. TinyToCS considers accessibility to the CS community at large to be a key component of the selection criteria.
We’re keeping the trappings of a program committee because we want to uphold a high standard of content. But we’re not filtering for what we think is the best work in a particular subfield - we’re filtering for what we think would be of interest to the community at large.
So maybe, TL;DR? Think of TinyToCS as your chance to submit an elevator pitch to the whole community, and have it get out there within weeks, not years.
Hope to see you submit!
Link: Bram Cohen: TCP Sucks
Supermoon over Cal (via Berkeleyside).
I’ve been doing some self-experimentation this week, running tcpdump persistently and logging the results to a (huge) directory of pcap files. Here’s a taste of 24 hours of the data…
Length of time in seconds:
MAX: 62182.238625 <— ssh
MIN: 1.7e-05 <— probably a bug?
MED: 2.046867
AVG: 60.9999384359015
STD. DEV: 736.853599230884
Same numbers for just HTTP/Port 80 traffic:
MAX: 5607.822474 <— seriously?
MIN: 0.003673
MED: 1.12272
AVG: 57.0826988090778
STD. DEV: 184.986012558513
We’ve been in a flurry of celebrating here at Cal; we found out this week that we’ll have several papers at HotCloud, several papers at SIGCOMM, and that one of the large AMPLab projects - Spark - won best paper at NSDI!
Anyway, I just wanted to share the list of papers with Berkeley authors to appear at SIGCOMM for all you networking folks:
“Surviving Failures in Bandwidth-Constrained Datacenters”
Authors: Peter Bodik (Microsoft Research), Ishai Menache (Microsoft Research), Mosharaf Chowdhury (UC Berkeley), Pradeepkumar Mani (Microsoft), Dave Maltz (Microsoft), and Ion Stoica (UC Berkeley)
“Making Middleboxes Someone Else’s Problem: Network Processing as a Cloud Service”
Authors: Justine Sherry (UC Berkeley), Vyas Sekar (Intel Research), Shaddi Hasan (UC Berkeley), Colin Scott (UC Berkeley), Arvind Krishnamurthy (University of Washington), and Sylvia Ratnasamy (UC Berkeley)
“DeTail: Reducing the Flow Completion Time Tail in Datacenter Networks”
Authors: David Zats (UC Berkeley), Tathagata Das (UC Berkeley), Prashanth Mohan (UC Berkeley), Dhruba Borthakur (Facebook), and Randy Katz (UC Berkeley)
“FairCloud: Sharing The Network In Cloud Computing”
Authors: Lucian Popa (HP Labs), Gautam Kumar (UC Berkeley), Mosharaf Chowdhury (UC Berkeley), Arvind Krishnamurthy (Univ. of Washington), Sylvia Ratnasamy (UC Berkeley), and Ion Stoica (UC Berkeley)
“Improving Internet Availability with LIFEGUARD”
Authors: Ethan Katz-Bassett (University of Washington), Colin Scott (UC Berkeley), David R. Choffnes (University of Washington), Ítalo Cunha (UFMG, Brazil), Vytautas Valancius (Georgia Tech), Nick Feamster (Georgia Tech), Harsha V. Madhyastha (University of California, Riverside), Tom Anderson (University of Washington), and Arvind Krishnamurthy (University of Washington)
“A Case for a Coordinated Internet-Scale Video Control Plane”
Authors: Florin Dobrian (Conviva), Junchen Jiang (CMU), Xi Liu (Conviva), Henry Milner (Conviva), Vyas Sekar (Intel Research), Ion Stoica (Conviva and UC Berkeley), and Hui Zhang (Conviva and CMU)
“Multi-Resource Scheduling for Middleboxes”
Authors: Ali Ghodsi (UC Berkeley and KTH), Vyas Sekar (Intel Research), Matei Zaharia (UC Berkeley), and Ion Stoica (UC Berkeley)
See you in Helsinki!
