[e2e] Question about FAST TCP

[Injong Rhee]

Hi Steve,

In my humble opinion, it remains to be seen how delay-based congestion
control schemes would live together with loss-based ones. I believe that
there are many desirable properties of delay-based schemes. However, in the
world that is dominated by loss-based Reno style congestion control, I see
some up-heel battle for delay-based schemes.

I have this wild idea (no flames) for some hybrid ones that react to *delay
reductions* rather than *delay increases* while keeping the loss reactions
the same as is now. This does not reduce queuing delays (maybe worsen it)
unlike existing delay-based schemes would do. However, it does increase
scalability during less loaded situations. In fact, during loaded cases
where many flows are competing, I am not sure whether there is any better
scheme than AIMD in achieving fairness (including rtt fairness).

Regards,
Injong



-----Original Message-----
From: end2end-interest-admin at postel.org
[mailto:end2end-interest-admin at postel.org]On Behalf Of Steven Low
Sent: Saturday, October 11, 2003 2:58 AM
To: Saverio Mascolo
Cc: lz6 at njit.edu; end2end-interest at postel.org
Subject: Re: [e2e] Question about FAST TCP

Hi Saverio

In principle, FAST TCP will indeed react to congestion in
the reverse path as well, by reducing its window.   Whether
one should react to congestion only in the forward path or
in both the forward and reverse paths may be debatable.
Without the help of the receiver and/or network, it seems
that delay-based algorithms will always react to both.
If receiver can help, then, indeed, one can implement
schemes such as TCP Santa Cruz; if both receiver
and network can help, one can implement Shiv's
Monoco.

Whether reverse path congestion is a serious issue
in practice remains to be seen.

Steven


Saverio Mascolo wrote:

>Hi Steven and all,
>
>in the msg below, FAST TCP is described as "a high speed version of Vegas".
>
>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.
>
>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.
>
>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.
>
>Saverio
>
>----- Original Message -----
>From: "Steven Low" <slow at caltech.edu>
>To: <lz6 at njit.edu>
>Cc: <end2end-interest at postel.org>
>Sent: Wednesday, August 06, 2003 8:04 AM
>Subject: Re: [e2e] Question about FAST TCP
>
>
>
>
>>The first two papers are more on background
>>theory, focusing just on the window control
>>algorithm.  The algorithms proposed in 1
>>and 2 all contain a q_dot term (derivative
>>of end to end price).  They have been
>>implemented in ns, but not yet in Linux,
>>so there is no performance measurement in
>>real network.
>>
>>The third paper (IETF Draft) is a small
>>subset of a paper we are revising (whose
>>extended abstract has been submitted),
>>and will hopefully be available online
>>soon.  The algorithm there can be thought
>>of as a high speed version of Vegas, and
>>does not use q_dot term.
>>
>>Steven
>>
>>
>>
>>
>>lz6 at njit.edu wrote:
>>
>>
>>
>>>As far as I know, there are three major FAST TCP based on control
>>>
>>>
>theory:
>
>
>>>1. Stabilized Vegas, D. H. Choe and S. H. Low
>>>2. A new TCP/AQM for stable operation in fast networks, F. Paganini, Z.
>>>
>>>
>Wang,
>
>
>>>S. H. Low and J. C. Doyle
>>>3. IETF Draft: FAST TCP for high-speed long-distance networks, Cheng
>>>
>>>
>Jin,
>
>
>>>David X. Wei and Steven H. Low
>>>
>>>Is there any performance comparison among these three appraoches in real
>>>network?
>>>
>>>
>>>
>>>
>>>
>>--
>>_____________________________________________
>>Steven Low                assoc prof, cs & ee
>>netlab.caltech.edu        tel: (626) 395-6767
>>slow at caltech.edu          fax: (626) 568-3603
>>
>>
>>
>>
>
>
>
>

--
_____________________________________________
Steven Low                assoc prof, cs & ee
netlab.caltech.edu        tel: (626) 395-6767
slow at caltech.edu          fax: (626) 568-3603




---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 10/6/2003

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 10/6/2003