Clean-slate Design Research Articles

30 seconds is not enough!

The basic system timer facilities used by applications and OS kernels for scheduling timeouts and periodic activities have remained largely unchanged for decades, while hardware architectures and application loads have changed radically. This raises concerns with CPU overhead power management and application responsiveness. In this paper we study how kernel timers are used in the Linux and Vista kernels, and the instrumentation challenges and tradeoffs inherent in conducting such a study. We show how the same timer facilities serve at least five distinct purposes, and examine their performance characteristics under a selection of application workloads. We show that many timer parameters supplied by application and kernel programmers are somewhat arbitrary, and examine the potential benefit of adaptive timeouts. We also discuss the further implications of our results, both for enhancements to the system timer functionality in existing kernels, and for the clean-slate design of a system timer subsystem for new OS kernels, including the extent to which applications might require such an interface at all.

Internet clean-slate design

Many believe that it is impossible to resolve the challenges facing today's Internet without rethinking the fundamental assumptions and design decisions underlying its current architecture. Therefore, a major research effort has been initiated on the topic of Clean Slate Design of the Internet's architecture. In this paper we first give an overview of the challenges that a future Internet has to address and then discuss approaches for finding possible solutions, including Clean Slate Design. Next, we discuss how such solutions can be evaluated and how they can be retrofitted into the current Internet. Then, we briefly outline the upcoming research activities both in Europe and the U. S. Finally, we end with a perspective on how network and service operators may benefit from such an initiative.

Editor's message

With this first 2006 issue, we are closing one year of the "new CCR formula." This aniversary makes me realize that we have not received many comments about CCR--just a couple of encouragement emails and one strong criticism. The authors of the criticism were mostly unhappy with the fact that we have made changes to the criteria to accept papers, and that these changes are not clearly described on the CCR web site. This is probably (at least partially) true, and we need your feedback to improve CCR. Please send us more feedback, positive or negative. You can send me or any of the area editors direct feedback. Alternatively, you can use the sigcomm mailing list sigcomm@postel.orgTo clarify, papers published in CCR should be of interest to our community. They should be mostly original (please do not send a paper based on material already published--the purpose of CCR is not to archive), with some evidence that it works or that the idea is worth being investigated. Novelty is certainly the heaviest acceptance criteria. So far, we have received around 15 to 20 submissions per issue and accepted 4 or 5 each time. This might be low as an acceptance rate for CCR, and we would love to publish more.Editorials seem to gain popularity. We are publishing 12 of them in this issue with some noticeable ones. Michalis Faloutsos accepted to run a new column on community news to appear in every issue. This editorial will provide news, gossips, practical information, etc. from our community in a humorous way. Michalis needs your input. Note that every gossip will be peer reviewed. Also in this issue Jim Kurose inaugurates a column entitled "10 recommended readings." Please send us the list of your 10 favority papers as well. Finally, we have a new episode of the CCR sitcom "buffers: size does matter!" This series has generated a lot of controversy (under the author's responsability). I believe this kind of argument is useful and I would like to encourage many more of such discussions. What about a new saga on QoS, on overlays, or on clean-slate design of communication architectures? And please keep sending us two-page papers on other topics. We will make our best to publish them as soon as possibleLast, in the previous issue I told you about a new junior reviewing program that I intended to deploy early 2006 (see the October issue for details). Unfortunately, I have received very little feedback on this project. In particular, nobody volunteered to help design the web interface for this service. If you really think such a service can help the community, please drop me a note and (a) volunteer!