Other Implementation Issues

We will now briefly discuss some of the salient implementation issues:

Application-dependent proxy: An important aspect of interfacing with legacy applications is to use an application proxy that can signal an application's requirements to the OverQoS network. In the case of MPEG streaming, the application proxy interprets the packets in the stream and marks the priority of recovery for each packet. For smoothing losses, all packets in a stream are associated with the same priority. For obtaining bandwidth guarantees, the proxy needs to use a signaling mechanism like RSVP [10] to reserve the resources along an overlay path.

Choosing parameters: The parameters $N$, $RTT$ and $p_{avg}$ need to be estimated for determining the sending rate $b$. While $N$ can be estimated as the instantaneous number of flows, we set $N$ as the average number of flows observed over a larger period of time (certain flows have a very short lifetime). This is to reduce the variations in the sending rate induced by $N$. Only flows that generate a minimum number of packets, are used in calculating $N$. We leverage the techniques used in equation based congestion control [16] for estimating the $RTT$ and $p_{avg}$ between two OverQoS nodes. We choose a reasonably low value of the target loss-rate, $q=0.1\%$, for most of our experiments. For FEC+ARQ based CLVLs, we choose the packet recovery time, $T_r$ to be $2 \times RTT$.

Startup phase: During periods of no usage (i.e. when $N$=0), we do not send additional traffic to estimate the virtual link parameters. After such a phase, OverQoS nodes need to determine an initial value of $b$ along a virtual link. Like TCP, we use a slow-start phase to estimate the initial value of $b$. During the slow-start phase, OverQoS does not use loss recovery.

FEC implementation: Our implementation can perform FEC encoding and decoding (for a redundancy factor as high as 50%) at over $300$ Mbps on a Pentium III 866 MHz running Linux 2.4.18 kernel. Since we operate on small window sizes, ($n<1000$), Reed Solomon coding is not a bottleneck. For example, on a virtual link with an $RTT=100$ ms, the window size is bounded by $1000$ for sending rates less than $40$ Mbps. Other coding techniques like Tornado codes [23] while faster, may not provide the same level of error correction for small window sizes.