Re: [lwip-devel] Reduce retransmission timeout

[Kieran Mansley]

On Wed, 2007-09-12 at 17:35 +0200, Frédéric BERNON wrote:
> Hi,
> 
> I got a question about tcp retransmission timeout. I would like to reduce the 
> first tcp retransmission (don't worry, only in my repository, not in the cvs 
> head). Don't forget I'm not expert on the tcp part. But, first, a little bit 
> background to explain why: I want to do that because we have to deploy 
> products on an existing radio network. The bandwidth is good (>30Mbps), 
> latency is low (<1ms) but each ~10s, where is a "perturbation in the air", 
> and we lost one packet. Tcp works, and retransmit segment after ~800 ms (it's 
> a mean, it's not constant, of course). Problem: the data transported is a 
> mpeg4 bitstream, and should be see in "real time" (understand: "with the 
> lower latency possible"). So, the retransmit delay cause problem. Of course, 
> the customer don't want any other technical solutions (change some networks 
> devices, use udp+jpeg, or a accept a bigger latency on display). Since the 
> network doesn't meet our technical requirements, I don't "have to" find a 
> solution. In a perfect world, such stream shouldn't be used on such network. 
> But, for several reasons, I'm interrested about find a workaround for this 
> study case.
> 
> Since, the lost is only each ~10s, there is only one retransmission. So, got 
> a faster first retransmission could be a good solution. I take a look in 
> tcp.c to try to understand which variables are used for retransmission, read 
> some whitepapers on that, take a look to "tcp/ip illustrated", etc... Now, I 
> have start to experiment.
> 
> First remarks, in some tcp.c/.h comments, we talk about explicit delays like 
> "500 ms" or "250 ms". I think it will be better to replace them by 
> TCP_TMR_INTERVAL, TCP_FAST_INTERVAL or TCP_SLOW_INTERVAL.
> 
> I see we have in tcp_alloc() :
> 
> pcb->rto = 3000 / TCP_SLOW_INTERVAL;
> pcb->rtime = -1;
> pcb->nrtx should be 0 (memset done on the pcb)
> 
> I have experiment to set TCP_TMR_INTERVAL=100 (fast=100, slow=200). Next, in 
> tcp.c, in tcp_slowtmr() function, and to replace :

I think that's fine, and not really a hack.  Our defaults are rather
cautious.  You might even get away with faster than that.  The initial
setting of pcb->rto using the 3000ms constant shouldn't affect you as it
will be set properly as soon as a the first ACK for new data is
received.

>       /* Increase the retransmission timer if it is running */
>       if(pcb->rtime >= 0)
>         ++pcb->rtime;
> 
> By
> 
>       /* Increase the retransmission timer if it is running */
>       if(pcb->rtime >= 0)
>         pcb->rtime+=10; /*beurkkkk, I should test something like 
> "pcb->rtime+=(((pcb->nrtx==0) && (pcb->unacked!=NULL))?pcb->rto:1);  */

This is a bit more horrible, and I'd first try just changing the
TCP_TMR_INTERVAL values to be smaller.

What you really want is to avoid TCP timeouts at all.  If you are
regularly sending data as a stream you should be able to trigger the TCP
fast retransmission mechanism instead, and so have almost immediate
retransmissions.  This requires three packets to be received after the
one that was lost though, and so that might not always be the case.  You
could try reducing the number of "duplicate acks" that are required to
trigger this though: see the use of pcb->dupacks in tcp_receive()

Kieran