[lwip-devel] [bug #19434] Processing of Fast retransmit bug

[Oleg Tyshev]

URL:
  <http://savannah.nongnu.org/bugs/?19434>

                 Summary: Processing of Fast retransmit bug
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: olegreen
            Submitted on: Wednesday 03/28/2007 at 12:00
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I resubmit bug from lwip-user mail list
(http://lists.gnu.org/archive/html/lwip-users/2006-06/msg00028.html) and
answer, that Kieran Mansley wrote.
May be some one can sooner or later instead of my hack to find out correct
realization.
===
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 retransmission timeout too, because data are sent in both
destination.
...
===
Kieran's answer:

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





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?19434>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/