lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] How to set a minimum RTT for TCP connections


From: Marco Jakobs
Subject: [lwip-users] How to set a minimum RTT for TCP connections
Date: Wed, 5 Feb 2014 17:32:39 +0100

Hi LwIP community,

 

we are facing a problem which seems to need some modification of our LwIP implementation.

 

Apart from the Ethernet connection we have a PPP connection open on a high latency wireless WAN network. The data rate is quite low (around 3.3 kBit/s) and the latency is up to 1000ms for a 32 bytes ping.

 

When we access our web server over this radio network we see a lot of retransmissions which seems to be caused by this behavior:

 

The browser opens a TCP connection ([SYN] – [SYN ACK] – [ACK]) to our webserver. As the radio link is idle and the data packets are not too big, the time between [SYN] – [SYN ACK] and [SYN ACK] – [ACK] is around 500ms each. This should be an initial value which is used by LwIP to calculate the RTT at this point.

 

Now the browser requests the web page (GET HTTP) and as a result 2000 Bytes webpage are sent out by our device in 2 segments. On the browser side the ACK for the HTTP GET is seen 1.5 seconds after the sent packet, the first segment of the webpage (1024 bytes) is seen another 2.5 seconds later. The browser sends an ACK for this segment (which will be important later).

 

The second segment (980 bytes) arrives at the browser another 2.5 seconds later. It's acknowledged and as the browser is happy it'll also close the connection by sending out [FIN, ACK].

 

At this point anything would be fine – but:

 

After 2.5 seconds a retransmission of the first segment with the webpage arrives at the browser. The PC sends back a [TCP Dup ACK], but another 2.5 seconds later the same retransmission appears again. This is also Dup Ack'ed, followed by another [FIN, ACK] as the acknowledgement of the initial FIN is still pending and in queue on our LwIP side. The slow wireless connection is still busy with the previous retransmissions on the way.

 

It takes at least around a minute before all this finally calms down – caused by a simple RTT problem.

 

 

I guess that LwIP calculates a RTT time based on the TCP connection opening which offers a round trip time of 500ms. After sending out the two TCP segments with the webpage I estimate that the ACK for the first segment will not arrive at LwIP before 5 seconds due to the busy packet data slot of the wireless network. I also think that the calculated RTT value has triggered the retransmissions of these segments a long time before these 5 seconds.

 

What I need to get around these problems is a "minimum RTT time" for this TCP connection. Whatever LwIP calculates as RTT value, this time should never drop below 5 seconds as suddenly the round trip time can increase to this value. It would be great if someone can tell me where to "inject" such a modification.

 

The problem here: The ideal solution would be the possibility to "tag" a TCP connection with this property after it was opened as TCP connections which arrive over the Ethernet interface should not be modified like this. So I need to find out over which network interface the TCP connection was established, modifying only connections which are handled over the PPP interface. Maybe the "minimum RTT time mechanism" can be implemented somewhere in the PPP code which would leave the Ethernet interface untouched?

 

 

I think if somebody uses PPP over GPRS he might face similar problems …

 

BR

Marco


reply via email to

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