Reduce retransmission timeout

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Reduce retransmission timeout

Frédéric BERNON
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 : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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




_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE : Reduce retransmission timeout

Frédéric BERNON
In reply to this post by 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 : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] 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
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment