Check out the new USENIX Web site. next up previous
Next: Impact of Varying Offered Up: Evaluation Previous: Performance Results from a

Simulation Results

We next use simulation to examine PCP's behavior in more detail. We chose not to use ns-2 for our simulations as it tends to be slow and scales poorly with the number of nodes or flows in the system. Using our own simulator also enabled us to reuse the same code for PCP and TCP that we ran on RON. Recall that we validated our TCP implementation against the TCP in the RON kernel.

For comparison, we also implemented centralized fair queueing [14] in our simulator. This mechanism achieves near-perfect isolation and fairness by scheduling packets from active flows in a bit-sliced round robin fashion. Given such a centralized router mechanism, it is possible for endpoints to infer their fair share by sending a pair of back to back packets, and observing their separation upon reception [35]. We model a fair-queueing system where the router also assists the endpoint in determining the optimal sending rate in the following manner. The endpoint transmits a control packet every RTT, and the router tags this packet with the flow's fair bandwidth allocation and the current queue for the flow. The endpoint simply sends at its fair share rate while compensating for queue buildups resulting from dynamic changes in the number of flows. While the resulting design might be difficult to realize in practice as it requires the router to communicate multiple bits of congestion information to the endpoint, it is intended as a bound on what is possible.



Subsections
next up previous
Next: Impact of Varying Offered Up: Evaluation Previous: Performance Results from a
Arvind Krishnamurthy 2006-04-06