Sharing Information across Congestion Windows CSE222A Project Presentation March 15, 2005 Apurva Sharma

Motivation WWW growth causing significant change in the composition of Internet traffic. Distinct characteristics of HTTP:  Each TCP connection initiated by HTTP tends to be short.  Web browsers often launch multiple simultaneous TCP connections. Technology trends indicate that the future Internet will have a large number of very high-bandwidth, high latency links. Result:  TCP slow start becomes bottleneck for short connections.  Connections belonging to a flow compete with each other. Internet studies indicate that available bandwidth tends to be stable at least for several minutes. Each HTTP Session typically involves downloading multiple web objects over a duration of few minutes.

Current Solution: Disadvantages Persistent Connections (HTTP/1.1)  Specifically tied to single application or application level protocol (HTTP)  By multiplexing data streams onto a single TCP connection introduces undesirable coupling between the streams that might otherwise be independent.  Still doesn’t address the use of concurrent connections by Web clients.

Proposed Solution Cache observed congestion window information by destination. Use it to initialize the congestion window for a new connection thus avoiding slow start penalty. Combine the congestion window across concurrent connections to the same destination.

Simulation Environment Implemented the enhancement as a specialization of TCP in GTNetS named TCP-Int. Used the WebBrowser class in GTNetS to generate traffic:  Traffic model based on “Empirical Model of HTTP Network Traffic” [Infocom ’97].  WebBrowser uses two concurrent TCPReno connections.  60 time units upper bound on browser think time. Server based on TCPServer class in GTNetS. Compared server running over TCPReno versus TCP-Int for different bandwidth-delay configurations. Each simulation run lasts 5000 units of simulator time. Use the GTNetS histogram class to produce a CDF of HTTP download times. Why only one client/server is enough?  There are two cases where TCP-Int behavior is different from TCPReno During slow start, if the cached estimate is incorrect we could cause congestion. This is addressed later under Deployment Concerns. If there are concurrent connections to the same destination. In this case they behave as a single TCPReno connection and thus TCP-Int is more responsive to congestion.  Thus TCP-Int behavior in response to congestion is always better or same as TCPReno and thus need not be measured in these experiments.  The Bottleneck Link bandwidth in these measurements can be taken as the bandwidth available to a single client/server. The goal of the experiment is to see how well TCP-Int utilizes it compared to TCPReno.

Results

Results (contd.)

Deployment Concerns Easy to deploy – only update at servers. Low overhead at connection setup only. Susceptible to false sharing:  Networks with QoS enhancements such as differentiated services.  Networks with path diversity, where different flows to the same destination are routed differently. Robustness issues - we need to guard against worst case scenario:  Preferentially drop fast start packets – router support?  Abort fast start on loss – revert to defaults.  Smooth out sending of data packets – avoid bursts.

Network Simulation Basics Discrete Event Simulation  Events model packet transmission, receipt, timers, etc.  Future events maintained in sorted Event List  Processing events results in zero or more new events Packet transmit event generates a future packet receipt event at next hop Create Topology  Nodes, Links, Queues, Routing, etc. Create Data Demand on Network  Web Browsers, FTP transfers, Peer-to-Peer Searching and Downloads, On--Off Data Sources, etc. Run the Simulation Analyze Results

Reflections on GTNetS Considered GTNetS, NS2 and FreeBSD as platforms. Found GTNetS to be easiest to setup and work with.  Good documentation  Little code bloating (10MB versus 300MB for NS2)  Single language C++ (versus TCL/C++ mess in NS2) “Virtual” trouble with GTNetS – only declares members that are needed by the functionality implemented in GTNetS as virtual. No activity on GTNetS mailing list – is anyone else using it? False advertising – works on Windows.

Summary Goals achieved  Project goals: Demonstrated the benefits of congestion window information sharing for a variety of high bandwidth-delay links Analyzed the deployment issues and proposed solutions to resolve them.  Personal goals: Learn to work with a network simulator Better understand TCP implementation Thoughts for future work:  Implement in a OS stack and test with some popular HTTP destination.  Think up other applications where this might be useful.