On Sat, Jan 01, 2005 at 07:36:42PM +0000, Charles M. Hannum wrote:
> On Saturday 01 January 2005 19:22, Charles M. Hannum wrote:
> > a) A running bandwidth estimate based on the ack rate is kept, and ssthresh
> > is set according to that -- in other words, we do exponential growth up to
> > the estimated bandwidth, and then linear growth thereafter, whereas Reno
> > will just keep trying to increase ssthresh forever.
> 
> Actually, that's not quite right.  In Reno, ssthresh is set to half the 
> current window (meaning the lower of the congestion window or how much data 
> is outstanding at the time of the retransmit) -- so the Westwood behavior is 
> potentially more aggressive.  This raises the question of whether it's too 
> slow to adapt and might be *too* aggressive, hurting other traffic.  I don't 
> see where this has been tested.

Theoretically the bandwidth estimation code is "accurate" enough that it won't
hurt other traffic.  The numbers that are in the research paper look good,
but they probably have no relation to what will happen in the real world.

Well, this was more of an exercise in relearning the BSD tcp/ip stack code.
Looked at this algorithm breifly when doing dayJob, and figured that it'll be
sufficiently intresting to implement, and potentially useful.  That being said,
I'm also poking at implementing the HighSpeed tcp RFCs, which would probably be
a lot more useful to people.

-- 
Kentaro A. Kurahone
SIGUSR1 Research and Development
"I am having a hallucination now, I don't need drugs for that."