Subject: Re: TCP limited transmit
To: Sean Doran <email@example.com>
From: Mark Allman <firstname.lastname@example.org>
Date: 11/29/2000 18:54:03
> 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
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