Re: panic in TCP Limited Transmit after RTO
> 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
討論串 (同標題文章)
完整討論串 (本文為第 7 之 11 篇)：