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

[Karl Jeacle]

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
reason for this is again the while() condition in tcp_output():

  while (seg != NULL &&
  ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd) {

Let's say a number of segments starting at seqno 100 are lost. When
seqno 100 is retransmitted, an ACK comes back telling us that the
receiver now wants 101, but that is not the first segment on the
unsent queue.

The old tcp_rexmit() code would have put 101 on the unsent queue, but
now, the first segment on the unsent queue is more likely to be, say,
seqno 150 i.e. the next in line for transmission before packet loss and
when the window was large. So 101 does not get sent until tcp_slowtmr()
calls tcp_rexmit() and 101 gets placed on the unsent queue.

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

Karl