I believe TCP Tahoe (the flavor we are supposed to have in ns-3) does not support fast recovery.  I thought that Reno was essentially TCP Tahoe with fast recovery.  Maybe I am reading the discussion wrong.  My information on the basic TCP flavors comes from comes from the Kevin Fall / Sally Floyd paper: Simulation-based Comparison of Tahoe, Reno, and SACK TCP.

(In reply to comment #1)
> I believe TCP Tahoe (the flavor we are supposed to have in ns-3) does not
> support fast recovery.  I thought that Reno was essentially TCP Tahoe with fast
> recovery.  Maybe I am reading the discussion wrong.  My information on the
> basic TCP flavors comes from comes from the Kevin Fall / Sally Floyd paper:
> Simulation-based Comparison of Tahoe, Reno, and SACK TCP.

Yes, I think it is probably correct to say that Tahoe includes Fast Retransmit.  For a while, there were two variants of Tahoe in the wild; those with Fast Retransmit and those without.  See the TBIT paper "On Inferring Tcp Behavior" by Padhye and Floyd.  

But I think it is still OK to call what we have now "Tahoe".

(In reply to comment #2)
> Yes, I think it is probably correct to say that Tahoe includes Fast Retransmit.
>  For a while, there were two variants of Tahoe in the wild; those with Fast
> Retransmit and those without.  See the TBIT paper "On Inferring Tcp Behavior"
> by Padhye and Floyd.  
> 
> But I think it is still OK to call what we have now "Tahoe".

  Mostly I'm interested in this functionality since if I submit a paper on how TCP works in my particular network configuration the first reviewer with a clue will ask "Why are you running with such an ancient TCP variant, what about newer mechanisms". 

  (Network simulation cradle doesn't allow such in-depth tracing, unfortunately - goodput, sure, but not durations of pauses, e.g. when downloading a webpage, user will rather press cancel than wait out if the transmission stops for more than couple of seconds..)

changeset: a814f37d15bf