On Sat, Jan 01, 2005 at 07:22:36PM +0000, Charles M. Hannum wrote:
[snip]
> Both of these behaviors are, on their face, more conservative than Reno.
> 
> My question is: what happens if you have rapid fluctuations; e.g. due to 
> sharing a link with another system that is doing occasional short 
> transactions that are not really congestion-controlled?  It appears to me 
> that Westwood is fairly slow to react in decreasing ssthresh and switching to 
> the more conservative linear growth.  This could be problematic in some 
> circumstances.

Fair enough.  Another thing that I noticed when I was implementing this is
that if the connection gets rerouted (longer rtt) the bandwith estimation code
will start to become inaccurate because the minMSS value that's being kept will
will be nolonger relevant.
 
> I also see a few problems with the implementation:
> 
> 1) In the fast-retransmit case, you are blindly setting cwnd to ssthresh; if 
> cwnd is already less than ssthresh, you should not do this.

That's what the paper describing the algorithm[0] said to do.

> 2) Your simple arithmetic in tcp_westwood_p_bwe() is potentially susceptible 
> to roundoff issues on low-bandwidth links, similar to the ones Brakmo and 
> Peterson complained about in the TCP Vegas paper (and that we fixed years 
> ago).  It's probably not as bad since you're dealing with byte counts rather 
> than packet counts, though.
> 
> 3) In tcp_westwood_p(), you are always setting dupacks to 0.  This is a bit 
> odd in that it could cause multiple fast-retransmit actions to fire within 
> one window.  It also breaks detection and recovery of cwnd after the fast 
> retransmit is acked and we're caught up -- but all that does it set 
> cwnd=max(cwnd,ssthresh), and we've already done that in the Westwood case.  I 
> think this effect is not very clear from the code.

Doh.  Ah well, all of those are relatively easy to fix.  It was a first attempt
at implementing it based off the research paper.
 
> I think the congestion control should be separated into pluggable functions.  
> WIth Reno, New-Reno and Westwood, there are getting to be far too many 
> conditionals in that code, and it's becoming a lot less clear how it operates 
> in the usual case.

*nods*.  I was considering spliting that off into functions when I was writing
this.  Most of the conestion control variants out there all need hooks in the
same places. (new data acked, dupacks, retransmit timeout)

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

[0]: http://www-ictserv.poliba.it/mascolo/tcp%20westwood/Tech_Rep_08_03_S.pdf