@inproceedings{trickless,
  title = {Trickles: A Stateless Network Stack for Improved Scalability, Resilience and Flexibility},   
  author = {Alan Shieh and Andrew C. Myers and Emin Emin G Network Stack for Improved Scalability, Resilience, and Flexibility},
  booktitle = {Proceedings of the 2nd USENIX Symposium on Networked Systems Design and Implementation (NSDI '05)},
   address = {Boston, MA, USA},
   month = {May},
  YEAR = {2005},
abstract = {
Traditional operating system interfaces and network protocol implementations force system state to be kept on both sides of a connection. Such state ties the connection to an endpoint, impedes transparent failover, permits denial-of-service attacks, and limits scalability. This paper introduces a novel TCP-like transport protocol and a new interface to replace sockets that together enable all state to be kept on one endpoint, allowing the other endpoint, typically the server, to operate without any per-connection state. Called Trickles, this approach enables servers to scale well with increasing numbers of clients, consume fewer resources, and better resist denial-of-service attacks. Measurements on a full implementation in Linux indicate that Trickles achieves performance comparable to TCP/IP, interacts well with other flows, and scales well. Trickles also enables qualitatively different kinds of networked services. Services can be geographically replicated and contacted through an anycast primitive for improved availability and performance. Widely-deployed practices that currently have client-observable side effects, such as periodic server reboots, connection redirection, and failover, can be made transparent, and perform well, under Trickles. The protocol is secure against tampering and replay attacks, and the client interface is backwards-compatible, requiring no changes to sockets-based client applications.
},
notes = {
The paper describes a new API (to replace sockets) and a new protocol (to replace TCP) which allows all connection state to be handled by one endpoint. Since TCP distributes state scalability is limited - consider that a server requires explicit per-client buffers which can lead to memory exhaustion during a DoS attack. In trickles, the new protocol involves the stateful side (typically the client) sending a continuation (in the form of a serialised TCB) to the stateless side (typically the server). Additionally a new connectionless API is provided for the stateless side.
<p>
Naturally a whole pile of issues arise when a protocol is designed this way, which makes for interesting reading. For example, in TCP each packet reception changes the endpoint state and this (e.g. window-size) is reflected in the next packet transmission. Since each &quot;trickle&quot; is a stateless client-server ping-pong, the state does not get updated for a whole round-trip. The trickles system must also worry about malicious client changing server state and try to prevent this using MACs (there's an obvious analogy here between trickless and web-applications which also use a stateless protocol).
<p>
At the meta-level, it was interesting to see a paper propose an alternative to both the socket API and TCP, even if they compromise slightly by making a socket-compatible shim-layer and using a TCP-like protocol with TCP wire formats :-)
},
  bibtexurl = {http://www.recoil.org/~djs/bibtex/trickles.bib},
 pdf = {http://www.cs.cornell.edu/andru/papers/trickles.pdf}
},

}