lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Deadlocked tcp_retransmit due to exceeded pcb->cwnd


From: Kieran Mansley
Subject: Re: [lwip-users] Deadlocked tcp_retransmit due to exceeded pcb->cwnd
Date: Fri, 25 Jul 2008 08:56:46 +0100

On Thu, 2008-07-24 at 19:26 +0200, address@hidden wrote:
> Hi
> 
> I do transfer over a gprs network with lwip1.3.0. The amount of data
> is fairly low, around 0.5MB per session. But every third or so
> session, the transfer stucks.
> 
> I encountered that GPRS network very often lose ACK's. However that's
> not surprising. My MPC555 IC-debugger shows me that retransmission
> done by calling tcp_output always fail on the test:
> 
> /* begin of code snippet */
> while (seg != NULL &&
>            ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd)

Sounds like an ACK returning to us has been lost, and so we don't have
sufficient window to send a new packet.  We should always have
sufficient window to retransmit a packet though.  Are you sure it's a
retransmission that is failing?  If it were a retransmission I would
expect seg->tcphdr->seqno to be equal to pcb->lastack so that test would
simply become "seg->len <= wnd".  As wnd is guaranteed to be at least
1MSS when limited by the congestion window (cwnd) we should then be able
to send.  We might not be able to retransmit all the data we have sent
but that's OK.  As long as we can send one packet, we should get an ack
(eventually, they may get lost again) and then can carry on.

This is an interesting case though and I'm sure lwIP hasn't been highly
tested in environments with high ACK loss so I'd be grateful if you
could investigate further.

Thanks

Kieran





reply via email to

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