On Wednesday 31 August 2005 02:12, Angelo Dell'Aera wrote:
> TCP Westwood+ bandwidth estimation is
> done through the use of a low-pass filter which requires few RTTs for
> obtaining the right value for the estimation. This is a transient and
we
> simply can't avoid it. If the data transfer ends before the end of the
> transient you're simply not testing Westwood+.
We noticed about this Westwood+ dependency on connection duration about
one year ago. It seems that westwood+ needs more than few RTTs to fully
reach its benefits, and probably this could be a key subject for future
researches.
> Moreover, as a general way of proceeding, I think that running few
> different TCP congestion control algorithms for just few RTTs and then
> comparing the results is not a correct way to proceed.
Absolutely. Also, I think that an accurate analysis of behavior for TCP
variables during connection is required to understand how algorithms
are performing.
>
> In the first phase of a TCP connection it's not possible to know how
> large is the pipe and the Reno slow start was designed in that way
just
> for this reason (obtaining an estimation of the capacity of the pipe
as
> soon as possible). This is a blind phase and IMHO no algorithm could
be
> designed to be better than others during this phase.
This is not true in every scenario. TCP Hybla for example, is giving the
congestion window an "acceleration" during its slow start phase that is
proportional to the round trip time, since the cwnd growth is clocked
by acks, and newreno is not caring of connections having very different
RTTs. However, this makes sense only for "long & fat" pipes, like
satellite connections, where the RTT difference with terrestrial TCP
traffic sharing the same link is the main cause of penalties.
Regards,
--
Daniele Lacamera
root{at}danielinux.net
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
