Re: panic in TCP Limited Transmit after RTO

[Noritoshi Demizu <demizu@xxxxxxxxxxxxxx>]

> Limited Transmit is supposed to send new data, and, we are out of
> SACK recovery at this point, so I think we can safely ignore any old
> SACK blocks.  Please try this patch.

Now I start understanding what your patch does.

  o When doing Limited Transmit, ignore SACK blocks and send the data
    starting at snt_nxt, even if the data has been SACKed.

  o In Congestion Avoidance phase, ignore SACK blocks and send the data
    starting at snt_nxt, even if the data has been SACKed.

I do not think these are good ideas.

By the way, what would happen with your patch if
  t_maxseg = 1KB,
  snd_cwnd = 20KB,
  ssthresh = 20KB,
  snd_una  = 100KB,
  snd_nxt  = 130KB,
  SACKed bytes below snd_nxt = 10KB, and
  an acceptable ACK is received ?

First, let me brief what has happened until then.
Before snd_nxt reaches 130KB, since TCP was in slow start phase,
SACK blocks were consulted and snd_nxt grew up to 130KB
(= snd_una + snd_cwnd + "SACKed bytes below snd_nxt").

Now, let me think what will happen after then.
After snd_nxt reaches 130KB, since TCP is in congestion avoidance,
SACK blocks will be ignored.  So, the highest sequence number allowed to
be sent is decreased to 120KB (= snd_una + snd_cwnd).  But snd_nxt has
been grown to 130KB.  So, data cannot send until snd_cwnd grows to
30KB, while TCP is in congestion avoidance phase (i.e., snd_cwnd grows
by t_maxseg per RTT).  Retransmission timeout would be resulted.

Hence, I do not think the change below is not a good idea.

> -	if (TCP_DO_SACK(tp) && tp->snd_nxt != tp->snd_max &&
> +	if (TCP_DO_SACK(tp) && (tp->snd_cwnd < tp->snd_ssthresh) &&
>  	    !IN_FASTRECOVERY(tp))

I am sorry if I misunderstand something.

Regards,
Noritoshi Demizu