<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Saveri and al.<br>
I 've made few tests from SLAC to NsLabs with Fast TCP on this side and
with TCP Reno 16 streams in the other side. We have a decrease of the
performance of Fast TCP only with the 8 MB window size but not 4 MB.
Also with the reverse traffic, note that we have more variation on the
RTT. <br>
The plots are avalaible here :
<a class="moz-txt-link-freetext" href="http://www.slac.stanford.edu/~hadrien/reversefast/index.html">http://www.slac.stanford.edu/~hadrien/reversefast/index.html</a><br>
<br>
Hadrien<br>
<br>
<br>
Cottrell, Les wrote:<br>
<blockquote type="cite"
cite="mid2846497B437BF84BAD1A4CC407418D2603A91167@exchange1.slac.stanford.edu">
<meta content="text/html; " http-equiv="Content-Type">
<meta content="MS Exchange Server version 5.5.2655.63"
name="Generator">
<title>FW: [e2e] Question about FAST TCP</title>
<br>
<br>
<p><font size="2">-----Original Message-----</font>
<br>
<font size="2">From: Saverio Mascolo [<a
href="mailto:mascolo@poliba.it">mailto:mascolo@poliba.it</a>] </font>
<br>
<font size="2">Sent: Friday, October 10, 2003 3:53 AM</font>
<br>
<font size="2">To: Steven Low; <a class="moz-txt-link-abbreviated" href="mailto:lz6@njit.edu">lz6@njit.edu</a></font>
<br>
<font size="2">Cc: <a class="moz-txt-link-abbreviated" href="mailto:end2end-interest@postel.org">end2end-interest@postel.org</a></font>
<br>
<font size="2">Subject: Re: [e2e] Question about FAST TCP</font>
</p>
<br>
<p><font size="2">Hi Steven and all,</font>
</p>
<p><font size="2">in the msg below, FAST TCP is described as "a high
speed version of Vegas".</font>
</p>
<p><font size="2">We have found that the main problem with Vegas is
that, being based on RTT measures as indication of congestion, it is
not able to get bandwidth in the presence of reverse traffic because
the reverse traffic increases the RTT. For instance 1 Vegas flow would
not be able to grab bandwidth when going "against" 10 Vegas reverse
connections. So it would be important to test Fast TCP with reverse
traffic.</font></p>
<p><font size="2">A solution could be to measure the forward
propagation time instead of measuring the rtt, basically doing what has
been done in TCP Santa Cruz.</font></p>
<p><font size="2">The problem with these kind of solutions is that,
when coexisting with probing algorithms such as Reno, Reno would get
more bandwidth since it would tend to get more queuing.</font></p>
<p><font size="2">Saverio</font>
</p>
<p><font size="2">----- Original Message -----</font>
<br>
<font size="2">From: "Steven Low" <a class="moz-txt-link-rfc2396E" href="mailto:slow@caltech.edu"><slow@caltech.edu></a></font>
<br>
<font size="2">To: <a class="moz-txt-link-rfc2396E" href="mailto:lz6@njit.edu"><lz6@njit.edu></a></font>
<br>
<font size="2">Cc: <a class="moz-txt-link-rfc2396E" href="mailto:end2end-interest@postel.org"><end2end-interest@postel.org></a></font>
<br>
<font size="2">Sent: Wednesday, August 06, 2003 8:04 AM</font>
<br>
<font size="2">Subject: Re: [e2e] Question about FAST TCP</font>
</p>
<br>
<p><font size="2">> The first two papers are more on background</font>
<br>
<font size="2">> theory, focusing just on the window control</font>
<br>
<font size="2">> algorithm. The algorithms proposed in 1</font>
<br>
<font size="2">> and 2 all contain a q_dot term (derivative</font>
<br>
<font size="2">> of end to end price). They have been</font>
<br>
<font size="2">> implemented in ns, but not yet in Linux,</font>
<br>
<font size="2">> so there is no performance measurement in</font>
<br>
<font size="2">> real network.</font>
<br>
<font size="2">></font>
<br>
<font size="2">> The third paper (IETF Draft) is a small</font>
<br>
<font size="2">> subset of a paper we are revising (whose</font>
<br>
<font size="2">> extended abstract has been submitted),</font>
<br>
<font size="2">> and will hopefully be available online</font>
<br>
<font size="2">> soon. The algorithm there can be thought</font>
<br>
<font size="2">> of as a high speed version of Vegas, and</font>
<br>
<font size="2">> does not use q_dot term.</font>
<br>
<font size="2">></font>
<br>
<font size="2">> Steven</font>
<br>
<font size="2">></font>
<br>
<font size="2">></font>
<br>
<font size="2">></font>
<br>
<font size="2">></font>
<br>
<font size="2">> <a class="moz-txt-link-abbreviated" href="mailto:lz6@njit.edu">lz6@njit.edu</a> wrote:</font>
<br>
<font size="2">></font>
<br>
<font size="2">> > As far as I know, there are three major FAST
TCP based on control</font>
<br>
<font size="2">theory:</font>
<br>
<font size="2">> > 1. Stabilized Vegas, D. H. Choe and S. H. Low</font>
<br>
<font size="2">> > 2. A new TCP/AQM for stable operation in
fast networks, F. Paganini, </font>
<br>
<font size="2">> > Z.</font>
<br>
<font size="2">Wang,</font>
<br>
<font size="2">> > S. H. Low and J. C. Doyle</font>
<br>
<font size="2">> > 3. IETF Draft: FAST TCP for high-speed
long-distance networks, Cheng</font>
<br>
<font size="2">Jin,</font>
<br>
<font size="2">> > David X. Wei and Steven H. Low</font>
<br>
<font size="2">> ></font>
<br>
<font size="2">> > Is there any performance comparison among
these three appraoches in </font>
<br>
<font size="2">> > real network?</font>
<br>
<font size="2">> ></font>
<br>
<font size="2">> ></font>
<br>
<font size="2">> ></font>
<br>
<font size="2">></font>
<br>
<font size="2">></font>
<br>
<font size="2">> --</font>
<br>
<font size="2">> _____________________________________________</font>
<br>
<font size="2">> Steven Low assoc prof, cs & ee</font>
<br>
<font size="2">> netlab.caltech.edu tel: (626) 395-6767</font>
<br>
<font size="2">> <a class="moz-txt-link-abbreviated" href="mailto:slow@caltech.edu">slow@caltech.edu</a> fax: (626) 568-3603</font>
<br>
<font size="2">></font>
<br>
<font size="2">></font>
</p>
</blockquote>
</body>
</html>