> Why not, instead of touching the cwnd at all, just modify
> tcp_output() to send a segment if t_extra is non-zero
> (post-decrementing t_extra), otherwise send or not send as usual?
> I am nervous about inflating snd_cwnd in the presence of potential
> congestion, no matter how carefully one tries to do the
> bookkeeping to do later deflation.

Right.  This is precisley why my orignal note suggested that I was
not sure whether my method was the Right One.  

> (Your draft is equally paranoid: "The congestion window MUST NOT
> be changed when these new segments are transmitted".)

Sure, throw my own words at me...

I have poked through the code and am pretty sure that the
bookkeeping is pretty easy and I don't think this can blow up on
me.  So, I think this is a reasonable approach.  Of course, if you
would like to do something different, please submit the code!

> You need to zero t_extra when you get dupack #3, when you get a
> non-duplicate ack, or when you do an RTO.  The first case is
> sensible paranoia; in principle any dupack (4, 5, 6, 7, ...) is an
> indication that a packet has exited the network, but if you have a
> full FIFO somewhere that overflowed causing the drop that triggers
> the dupacks, continuing to pour packets into it will never let it
> drain.

I believe clearing t_extra when you clear t_dupacks is what we
want.  In other words, we get the chance to use limited transmit
every time we have a new chance to use fast retransmit.

> "Three" should be changeable easily, in case some day there is
> consensus that FT/FR should trigger on a different number of
> duplicate ACKs.

I think there is a variable for dupacks.

> | Also note that everywhere that t_dupacks is set to zero, t_extra
> | should also be set to zero (as shown above).
> 
> Hopefully that's all the cases. :-)

My reading of the code says so...  But, other opinions would be
appreciated.

allman