Re: [lwip-users] Recent tcp_rexmit() changes

[K.J. Mansley]

On Fri, 2004-07-23 at 12:21, Karl Jeacle wrote:
> On Fri 23 Jul 04, 09:57:07 +0100, K.J. Mansley wrote:
> > On Thu, 2004-07-22 at 20:20, Karl Jeacle wrote:
> > > tcp_slowtmr() will eventually call tcp_rexmit(), and one more unacked
> > > segment will be moved to the unsent queue and transmitted. This cycle
> > > of tcp_slowtmr() calling tcp_rexmit() to send one segment will continue
> >
> > What should happen here, and this is where I'm not sure if we're right
> > or not, is that the sender should re-enter slow start.  The congestion
> > window should be set to 1 segment, and then increased by 1 segment each
> > time an acknowledgement is received.  (NB. I don't think the
> > acknowledgement needs to be for new data).  This should allow increasing
> > numbers of segments to be released from the unsent queue, but does
> > require many round trip times to recover to previous levels.
> 
> Yes, let's forget about Fast Retransmit. I am happy with those changes
> as per Stevens. What's happening now is that when a number of packets
> are dropped, FR does initially kick in, but it's the subsequent slow
> start that isn't working properly.
> 
> The window does drop down, but it doesn't increase on each round trip.
> This is because after a segment is retransmitted, the ACK that comes
> back does not trigger tcp_output() to send the next segment, and hence
> allow slow start to work. The ACK comes back, but nothing is sent out.
> We have to wait for tcp_slowtmr() to get the next packet out.

The theory is, I think, that you'll get multiple acks back after you
sent the "fast retransmitted" segment because you had many segments in
flight and each of those will result in a forced ACK as they're out of
order.  Each ack the sender receives will increase the congestion window
until it's able to send more.  If you have a copy of Stevens's TCP/IP
Illustrated Vol 1 there's an illustration of this on page 308 (figure
21.7): a number of acks are received (after a retransmission) before the
next in-sequence packet is sent. (Although the retransmitted segment has
not yet been acknowledged).

If insufficient acks are received by the sender to increase the
congestion window, then it has to wait for the slow timer to expire and
slow start (in addition to congestion avoidance) to kick in.

If I've misunderstood you though, and the congestion window should be
large enough to send data, but it's just not getting output, then that's
something that needs looking at and fixing.

> We need to factor in what the receiver is expecting us to send next
> (after a retransmission), and adjust the unsent queue accordingly.

The assumption is that only a single segment is lost, and so the
sequence should start where it left off.  It's the fact that many
segments are lost that is causing your problem I think, and lwIP is
eager to resume where it left off.

I can see in your case that this is a long way from optimal, but not
sure how we can address it while still conforming to the congestion
avoidance and slow start algorithms (as I've understood them - I could
have got it wrong though).  Any suggestions anyone?  Or any ideas what
other stacks do in this circumstance?

Perhaps we could alter the behaviour so that when there is a sudden
cut-off in ACKs (which suggests many segments lost), rather than a large
number of duplicate acks (which suggests a single segment lost), we
resume from the seqno of the first retransmitted packet?  It's a bit
ugly, and would be hard to code for this case accurately (e.g. what if
just a couple of ACKs (something in between) are received?) but might do
what you need.  Any thoughts on this?

Thanks

Kieran