Re: [lwip-users] processing Fast retransmit bag

[Kieran Mansley]

On Wed, 2006-06-21 at 18:38 +0200, Oleg Tychev wrote:
> Hello All!
> 
> My hub have found another bug:)
> 
> For example we have two node.
> Data are sent in both destination.
> 
> node1                              node2(lwip)
> [data1]--->
>                                    <---[data2] (1 byte/sec)
> ACK
>                                    <---[data3]
> data3 packet is dropped
> dup ACK 1->
>                                        pcb->dupacks==1
> dup ACK 2->
>                                    <---[data4]
>                                        pcb->dupacks==2
> dup ACK 3->
>                                        pcb->dupacks==3
> 
> Node2 starts Fast Retransmission
> see tcp_receive
>             if (!(pcb->flags & TF_INFR)) {
>                  pcb->flags |= TF_INFR;
>                  tcp_rexmit(pcb);
>              }    
>                                    <---data3
> data3 packet is dropped again
> 
> node1 sends dup ACKs again and again
> but we have TF_INFR flag set, it means no tcp_rexmit!!!
> 
> We doesn't have retrasmission timeout too, because data are sent in both 
> destination.
> 
> You can use this patch, but I don't now how behaves fast recovery and 
> slow start with it.
> At least it works:)

Although this patch may solve your particular problem, it shouldn't be
applied to the main tree.  I think how tcp retransmission is supposed to
work in the case you highlight (a fast retransmitted packet is lost) is
that it falls back to slow retransmission.  You should get a
retransmission timeout even though there is bidirectional traffic as
this timeout should only be reset when receiving an ACK that
acknowledges new data.  As Node1 will continue to only send dup ACKs,
there will be no ACKS that acknowledge new data received at Node2, and
so it should be a retransmission timeout and retransmit data3.  

If we're not generating a retransmission timeout in this example, that
is a bug and should be fixed.

The standard fast retransmission algorithms are known to not be
particular high performance when multiple packets are lost - the normal
solution to this is to implement selective acknowledges (RFC2582).

Kieran