RE : [lwip-devel] Reduce retransmission timeout

[Frédéric BERNON]

>> 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.

Is there any RFC which give requirements about such timeouts (a minimal value 
by example) ? I can reduce TCP_TMR_INTERVAL to a smaller value, but there will 
be a constant "overload" in tcpip_thread. 

>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.

Yes, but to be honest, I'm not sure to understand the details of "rto" 
calculations in tcp_receive. I just saw it is to 3 the first time.

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

Yep !!! Horrible is the best word for that :)

>What you really want is to avoid TCP timeouts at all.

Not exactly, since, in this case, there is only one lost, I just want to reduce 
the first delay (and keep the calulcation of delay with "backlog" for next ones 
retransmissions). With TCP_TMR_INTERVAL=100, without rtime patch, delays 
between each retransmissions are (in ms): ~0.3009, ~0.6563, ~0.1.0938, 
~2.5158... If I could got something like ~0.80, ~0.3009, ~0.6563, ~0.1.0938, 
~2.5158... It would be good

>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()

I will take a look, thank
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Kieran Mansley
Envoyé : mercredi 12 septembre 2007 17:55
À : lwip-devel
Objet : Re: [lwip-devel] Reduce retransmission timeout


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




_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf