[lwip-users] Huge differences in TCP retransmission times - why?

[Marco Jakobs]

Hi,

 

I need to send a "huge" amount of TCP data (60-100kBytes) over a slow wireless connection (PPP, around 3-4 kbit/s). With my first attempts I sometimes see TCP retransmissions from my LwIP stack, so I did some measurements on this. I know that a 1024 bytes packet will take around 2.5 seconds, in addition to the travel time of the returning ACK I should not do a TCP retransmission before 5 seconds.

 

I did some measurements over the wire then:

 

- Opening a TCP connection from my device to a TCP test server

- Sending a 1024 bytes payload TCP packet over to the server (which is immediately ACKed)

- Pulling the wire to the server

- Sending another 1024 bytes packet

- Tracing all this in Wireshark and see after which time LwIP does the first retransmission

 

With this setup I see a first retransmission sent out around 13 seconds after the initial packet which was not ACKed. That's OK and will definitely work also on my slow PPP connection.

 

But then a bit different:

 

- Opening a TCP connection from my device to a TCP test server

- Sending a 1024 bytes payload TCP packet over to the server (which is immediately ACKed)  <- LEAVING THIS STEP AWAY 

- Pulling the wire to the server

- Sending another 1024 bytes packet

- Tracing all this in Wireshark and see after which time LwIP does the first retransmission

 

Now LwIP sends the first retransmission right after around 2.5 seconds (which is way too early for my slow connection).

 

So, I'm wondering why LwIP uses totally different times to the first TCP retransmission in both scenarios. This is followed by a major question: How can I set a defined minimum retransmit time of 5 seconds for my connection?

 

 

 

A second issue/question:

 

As I have this amount of data stored in my memory, but the outgoing connection is that slow, I'd like to have knowledge how many packets are "in the transmit queue" in LwIP here.

When my NETCONN_WRITE sends the data out to LwIP (using NETCONN_COPY), the data is copied into LwIP's memory. So I can repeat that a few times until LwIP's buffers are full (remember: The outgoing PPP connection for this is slooooow) and my NETCONN_WRITE blocks.

 

To get around this and avoid filling up LwIP's buffers (which would block also local Ethernet connections like my webserver), a "dumb" way would be to have a fixed delay of 3 seconds between two consecutive NETCONN_WRITE to this TCP connection.

 

More elegant would be if there is any way/variable to "poll" if there are still packets in the queue / in the transmit process for my TCP connection. Once the buffers are empty again, I could send the next packet over to LwIP.

 

Any ideas here?

 

 

Thanks a lot,

Marco