Bug in tcp_time_to_recover

Bug in tcp_time_to_recover

[Ramana Juvvadi]

Consider the following code in tcp_input.c
-----------------------------------------------------------------
static int
tcp_time_to_recover(struct sock *sk, struct tcp_opt *tp)
{
   /* Trick#1: The loss is proven. */
   if (tp->lost_out)
       return 1;

   /* Not-A-Trick#2 : Classic rule... */
   if (tcp_fackets_out(tp) > tp->reordering)
                      ^^^^^^^^^
       return 1;

   /* Trick#3: It is still not OK... But will it be useful to delay
    * recovery more?
    */
   if (tp->packets_out <= tp->reordering &&
       tp->sacked_out >= max(tp->packets_out/2, sysctl_tcp_reordering) &&
       !tcp_may_send_now(sk, tp)) {
       /* We have nothing to send. This connection is limited
        * either by receiver window or by application.
        */
       return 1;
   }

   return 0;
}
----------------------------------------------------

Shouldn't it be a >= instead of > ?

Ramana    




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Bug in tcp_time_to_recover

[kuznet]

Hello!

>    /* Not-A-Trick#2 : Classic rule... */
>    if (tcp_fackets_out(tp) > tp->reordering)
>                       ^^^^^^^^^
>        return 1;
...
> Shouldn't it be a >= instead of > ?

No. fackets_out is equivalent of Reno dupacks+1.

F.e. look at the most common case, where FACK is equivalent to Reno:

| hole | sack1 | sack2 | sack3

fackets_out = 4
but
dupacks = 3

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/