[Top][All Lists]
[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
- [lwip-users] Recent tcp_rexmit() changes, Karl Jeacle, 2004/07/22
- Re: [lwip-users] Recent tcp_rexmit() changes, K.J. Mansley, 2004/07/23
- Re: [lwip-users] Recent tcp_rexmit() changes, Karl Jeacle, 2004/07/23
- Re: [lwip-users] Recent tcp_rexmit() changes,
Karl Jeacle <=
- Re: [lwip-users] Recent tcp_rexmit() changes, K.J. Mansley, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, Karl Jeacle, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, Leon Woestenberg, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, K.J. Mansley, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, Leon Woestenberg, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, Sam Jansen, 2004/07/26
- Re: [lwip-users] Recent tcp_rexmit() changes, Kieran Mansley, 2004/07/27