Rich Draves chaired the third session, focused on networking. The first paper in this session, presented by Hariharan Rahul, described an approach to congestion management that centralizes currently-fragmented knowledge of networking conditions on various flows. The component responsible for maintaining this knowledge, called the Congestion Manager (CM), exports an API that enables applications to make queries and place callbacks triggered by changes in network conditions.
Buck Krasic asked the first question: does involving applications in congestion control increase CPU scheduling delays and thereby reduce agility of adaptation? Rahul replied that the CM was in the kernel, just like the rest of TCP, and so should incur little additional scheduling overhead. However, he did agree that the results in the paper were based on simulations and that only an actual implementation could reveal the incidental overheads of this approach. Peter Druschel asked whether the CM did policing to detect uncooperative or malicious applications. The reply clarified that the CM API assumed cooperative applications, and that policing would require the assistance of edge routers. Rich Draves expressed concern that the greater number of system calls due to increased application-kernel interactions would degrade performance. Rahul replied that buffering could reduce some of this overhead, and that the improved programming model offered to applications would more than compensate for the increased overhead. He also noted that if reducing context switching overhead became critical, as in a Web server, the CM could be implemented in the kernel along with the transport protocol.
The second paper, entitled ``The Case for Informed Transport Protocols'', was presented by Stefan Savage. In a hilarious introduction that won applause from the audience, Savage characterized early use of the Internet as two graduate students downloading the BSD Unix source tree; he then contrasted this with the current state of the Internet, characterized by every graduate student frantically performing short e-trades. The main point of his talk was that TCP's congestion control mechanisms were designed with a certain set of assumptions that no longer hold. His proposed solution is to allow different machines to share information about network resources they use in common. This approach allows TCP sessions with short lifetimes to make informed decisions about the correct rate for sending traffic.
Robert Haas began the question period by observing that Savage seemed to be making the case for application-specific transport protocols, not informed transport protocols. Savage's reply was that there was a spectrum of possibilities ranging from a purely end-to-end approach to an ATM-like approach where the network has full awareness; informed protocols support a broad range of possibilities in this spectrum.
This was followed by an extended interaction between Hari Balakrishnan and Savage. Balakrishnan pointed out that one of the scariest problems is figuring out how to age information. He disagreed with the proposed aging value of 10 seconds, and suggested that this number should be tightly coupled to the round trip time (RTT) since the state of congestion changes at that scale. Savage countered that Balakrishnan's own work showed that unless you examine fine-scale behavior, traffic behavior does not change that quickly. Therefore, variations below 10 seconds are not something you can control for. Further, TCP's existing congestion control mechanism already adapts at the time scale of RTT. Balakrishnan then pointed out that the factor of 2 by which TCP shrinks its window on congestion is not arbitrary, but is because you know during slow start that half the current window worked the last time. Savage agreed, but noted that the choice of 2 as the growth factor during slow start was an arbitrary choice proposed by Van Jacobson in his seminal TCP congestion control paper.
Hariharan Rahul asked how much overhead would be imposed by the sharing of control information in informed protocols. Savage's response was that this would depend on the implementation. If the information is piggybacked, then it would impose minimal overhead; but if additional packets are generated for pacing by the sender or receiver, that might pose some overhead. Rahul followed by asking if it was being assumed that there was adequate bandwidth in the network; Savage confirmed that this was the case, but added that it wasn't a big deal in modern networks.
Ian Pratt pointed out that the paper showed how an informed protocol could be helpful to the sender, but did not show how it was useful to the receiver. In practice, however, it is usually a server talking to many sites that is most in need of help. Savage agreed that servers suffered most from bottlenecks, but felt that they could also benefit from informed protocols through indirect control of traffic rates. David Mosberger closed the question session by requesting clarification on an apparent paradox: on the one hand, the talk claimed that a single flow is not long enough to get useful congestion information; on the other hand, the probability of having two or three flows close together within 30 seconds in a bottlenecked situation is low. Savage agreed in principle, but insisted that using older estimates under those circumstances was better than picking a random estimate for a new flow.
David Kidston presented the final paper in the session, entitled ``Transparent Communication Management in Wireless Networks''. The goal of this work was to improve application performance in wireless environments in a transparent manner, using proxies to intercept and modify network flows. An environment manager, running on each node, collects and shares information on network conditions with its counterparts on other nodes. The transformations of a proxy are guided by information from its environment manager.
Stefan Savage began the question period by noting that his work avoided proxies for two reasons: they introduce single points of failure, and they modify end-to-end RTTs in ways that mislead TCP sources. Kidston rebutted the first point by observing that wireless base stations already represent single points of failure. He addressed the second point by indicating that deliberate delays could be introduced by proxies to preserve end-to-end RTTs. In response to Savage's followup question as to whether the source code for this work was ftpable, Kidston replied that he wasn't sure but would check into it.
Srini Seshan asked whether stream compression by a proxy would interfere with packet retransmissions. After some debate on this issue by Seshan and Kidston, Hari Balakrishnan offered the suggestion that retransmitting a superset of missing packets would allow stream compression without affecting end-to-end packet boundaries. Balakrishnan then followed by asking why a simple split-TCP approach was not being used. Kidston's response was that the proxy approach allowed modification of both packet headers and contents, while conventional split stream only allowed modification of contents. The session ended by Armando Fox asking about the kinds of applications this work was directed at, and Kidston replying that MPEG video was a typical target application.