lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] Reduce retransmission timeout


From: Frédéric BERNON
Subject: [lwip-devel] Reduce retransmission timeout
Date: Wed, 12 Sep 2007 17:35:29 +0200

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 :

      /* 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);  */

My experience is to transmit a big blocks of data each 40ms from my lwipserver 
to my pc. During the tranmission, I unplug my pc. Wireshark run on another pc 
which monitor my lwip device port. Which such patch, I can reduce the delays 
under 100ms (often less than 50ms), which is enought.

Of course, with such dirty patch, I could retransmit some packets twice (if 
tcp_slowtmr is called just after the segment sent, and before the ack 
reception). 

So, my question: do you have some suggestions, links or documentation about 
such cases (very fast recovery of ponctual tcp lost), and in a more general 
way, is it something "usual" to try to tune an IP stack for a specific network 
(I also think about specific tuning for UMTS networks for another product, in 
this case, increase the snd_queue to reduce latency problems)? Once again, 
don't forget I'm not expert on the tcp part...

Thank you for any information you can give me...


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

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


reply via email to

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