Re: panic: sackhint rexmit == 0

From: Noritoshi Demizu <demizu_at_dd.iij4u.or.jp>
Date: Tue, 30 Aug 2005 12:06:04 +0900 (JST)
> > #23 0xc063ae06 in tcp_input (m=0xc1e56400, off0=20)
> >     at /usr/home/build/src/sys/netinet/tcp_input.c:1915
> > 1915						KASSERT(tp->sackhint.

> Should already be fixed in -current.

The change of tcp_input.c rev 1.283 does not *fix* the problem.
It is just a workaround of the problem.

I believe the real problem is that tp->snd_cwnd, tp->snd_ssthresh,
tp->snd_recover, and tp->snd_nxt are falsely recovered by an algorithm
using tp->t_badrxtwin in the following scenario.

  1. An Retransmission Timeout occurs.  Now, t_rxtshift is 1.
     (snd_cwnd, snd_ssthresh, snd_recover are saved in tcp_timer_rexmt().)

  2. Before t_rxtshift is reset to zero, Fast Retransmit is triggered
     and TCP enters Fast Recovery.  (Note: t_rxtshift is reset to zero
     by tcp_xmit_timer() when a new RTT measurement is taken.  If my
     memory serves correctly, this behavior is specified in RFC2988).

  3. A partial ACK or a full ACK is received before "ticks" reaches at
     tp->t_badrxtwin.

     In this case, lines 2047-2056 in tcp_input.c 1.283 recovers
     snd_cwnd, snd_ssthresh, snd_recover and snd_nxt.
     (Note: t_rxtshift has not been reset to zero.  It will be reset
     at line 2074 or 2076 of tcp_input.c 1.283.)

     I believe those variables must not be recovered in this case.
     Since snd_recover is recovered, snd_recover becomes smaller than
     the actual value.  Hence, the condition at line 2134 of tcp_input.c
     1.283 falsely becomes true, and TCP falsely exits Fast Recovery.
     It breaks internal states of TCP SACK.

In tcp_input.c 1.282 or before, the possible corruption was detected
by the lines removed in the change of tcp_input.c 1.283.  Since the
check was not so significant, the check was removed as a workaround.

I believe the following change fixes the problem by avoiding step 3
above.  Introducing a new flag indicating whether t_badrxtwin is valid
would be a better solution because a TCP connection may live longer
than 2^32 ticks of time.

  <<Quoted from tcp_input.c rev 1.283>>
  1915:					ENTER_FASTRECOVERY(tp);
  1916:					tp->snd_recover = tp->snd_max;
  1917:					callout_stop(tp->tt_rexmt);
  1918:					tp->t_rtttime = 0;
+					tp->t_badrxtwin = ticks;
  1919:					if (tp->sack_enable) {

Regards,
Noritoshi Demizu
Received on Tue Aug 30 2005 - 01:05:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:42 UTC