Subject: Bandwidth estimation

From: "Chadi M. BARAKAT" <[email-masked]>
Date: Wed, 10 Mar 1999 17:32:40 +0100

Hello,

Two weeks ago, I talked about some kind of packet spacing to send many
packets at the beginning of slow start so that to avoid some RTTs and to
reduce the time required to reach the available bandwidth. It is clear
that such solution involves certain implicit bandwidth estimation.
Another mechanism is required to estimate the bandwidth on the path and
to set the timer accordingly. This lets us avoid the situation Neal
mentioned, that of a slow modem and large packets. How to estimate the
bandwidth, I think that Timestamp option provide us with the required
information. Namely, the time elapsed between the transmission of two
ACKs, together with the number of packets acked, can give the source an
idea about the bottleneck bandwidth. Now, the time between the beginning
of the connection and the obtaining of such information guarantees that
the network is not very congested (because a certain number of packets
has succeeded to cross it) and hence a faster increase of the window
with separated packets is possible. We can use the same algorithm
proposed by Hoe to estimate the bandwidth and then the slow start
threshold. The difference is that here whence the bandwidth is
estimated, a large window is transmitted by spacing the packets.

But here I ask, once such estimation is accomplished, why to not profit
from it to spread any subsequent burst sent by TCP even in congestion
avoidance. It is known that the loss and the compression of ACKs cause
burstiness at the source. With some estimation of the bandwidth, these
bursts can be spread out and some losses avoided (this is can beneficial
in asymmetric paths). Do you think that some kind of bandwidth
estimation and packets spread is feasible and form a practical solution?
I am seeing this as a way to separate the transmission rate of the
source from the arrival rate of ACKs (to don't rely on the ACK clock
when it is disturbed). With asymmetric paths and reverse traffic, ACK
stream doesn't represent what is happening on the forward path. 

I am currently studying the feasibility of such solution, any help will
be very appreciated.

Chadi

-- 
                    **  Chadi Mohamad BARAKAT  **
           http://www.inria.fr/mistral/personnel/Chadi.Barakat
                                  /\
PhD Student - MISTRAL - INRIA    /  \   [email-masked]
2004, Route des Lucioles BP 93   \  /   Phone : + 33 4 92 38 71 99
06902 Sophia Antipolis - France   \/    Cell  : + 33 6 10 42 36 30