lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Jeacle
Subject: Re: [lwip-users] Recent tcp_rexmit() changes
Date: Sun, 25 Jul 2004 20:46:36 +0100

On Fri 23 Jul 04, 13:09:01 +0100, K.J. Mansley wrote:
> 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.

Here is a rough interpretation of what I think is happening:

A is sending to B.
A sends packets with seqno 1 through 149.
B does not receive a number of packets after 99.

tcp_rexmit() called, one segment (say, seqno 100) is placed on unsent queue.
wnd=1*MSS
tcp_output() called, segment at front of unsent queue sent (seqno 100).
ACK comes back; receiver wants seqno 101.
wnd=2*MSS
tcp_output() called, first segment on unsent queue is seqno 150; nothing sent.
500ms elapse
tcp_slowtmr() calls tcp_rexmit(); seqno 101 is placed on unsent queue.
Cycle repeats for n*500ms, where n is number of packets lost.

When slow start kicks in, a segment should be sent every RTT, but this
doesn't happen, because after 1*RTT, the seqno that the receiver wants
is not on the unsent queue (with the old code, it used to be!), and so
nothing happens until a timeout occurs, and tcp_rexmit() can get the
segment desired by the receiver onto the unsent queue.

The timeout would be OK, and as expected, if it happened just once, but a
timeout is taking place at each RTT... the sender is stalled for 500ms at
a time instead of one RTT at a time. I hope I am making some sense!

> 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

Assuming, I am correct about the above, I would suggest two versions of
tcp_rexmit() - one for fast retransmit (to solve Sam's original problem)
where just a single segment is placed on the unsent queue, and one for
all other cases, where the previous lwIP behaviour is maintained.

Ultimately, I can use my own rexmit() routines, so there's no need to
modify core lwIP behaviour to accommodate me, but I think there is a
problem above that needs to be addressed for lwIP users in general.

Finally, thanks for info re:SACK etc. My senders and receivers are both
lwIP, so SACK support would solve problems and definitely be beneficial.

Karl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]