Re: panic in TCP Limited Transmit after RTO
> Looking at the second graph it appears to be sending data at both
> snd_nxt and snd_max, just like Jeff's, but the difference being
> that Jeff's was also sending bursts from snd_nxt while yours does
> not. Am I correctly identifying the difference between the two
> patches?
The most significant difference between Jeff's second patch and my
second patch is in the first Limited Transmit after an retransmission
timeout.
(Limited Transmit (RFC3042) allows to send a new data segment upon
the arrival of the first and the second duplicate ACK.)
On the first Limited Transmit, Jeff's second patch sends a burst of
data from snd_nxt through snd_max + MSS when snd_nxt < snd_max.
On the other hand, my second patch sends only one segment at snd_max
on the first Limited Transmit.
I made another web page that shows the difference at.
http://www.demizu.org/~noritosi/memo/2005/0317/
This page focuses on the first Limited Transmit.
> From my visual inspection wouldn't it be better to still send a burst
> of old (snd_nxt based) data while simultaniously sending just one
> segment at snd_max via limited_transmit? Obviously the burst should not
> be as long as the one Jeff's patch produces, but sending just one packet
> at snd_nxt also seems wrong when, clearly, the link is able to handle
> more then one-packet bursts and snd_nxt.
It is not an easy task to estimate the network capacity. When a
duplicate ACK segment is received, it may be an indication of
a lost of a data segment due to a congestion or an error on
a wireless link. Or it may be a result of a reordering on the
path to the receiver.
Limited Transmit just postpones the decision whether it is an
indication of a congestion or not for a while. :-) And it sends
one new data segment for the first and the second duplicate ACK.
But when the third duplicate ACK is received, the sender infers
those duplicate ACKs are indications of a congestion. And it
reduces congestion window and enters FastRecovery or SACK recovery.
The behavior of Limited Transmit may be too aggressive or may be
too conservative. But it is the algorithm called Limited Transmit.
If DragonFlyBSD sends more data segments than Limited Transmit
specifies, it is a new algorithm against duplicate ACKs. Its
performance may be good, may be bad. But, I think the new
algorithm should have its own name.
> This is a combination of cases that would only occur when the
> connection has both SACK AND limited_transmit capabilities and perhaps
> the RFC is not considering this combination of cases properly?
For the first and the second duplicate ACK, Limited Transmit works.
For the third and later algorithms, SACK works. So, I think there
will be no conflict between SACK and Limited Transmit.
Regards,
Noritoshi Demizu
ps. I am sorry today I cannot reply to your e-mail on
"Delayed ACK triggered by Header Prediction",
because it took much time to prepare the web page above.
討論串 (同標題文章)
完整討論串 (本文為第 11 之 11 篇)：