From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
To: Oumer Teyeb <oumer@kom.aau.dk>
Cc: netdev@vger.kernel.org
Subject: Re: Weird TCP SACK problem. in Linux...
Date: Wed, 19 Jul 2006 17:27:19 +0400 [thread overview]
Message-ID: <20060719132719.GA22143@ms2.inr.ac.ru> (raw)
In-Reply-To: <44BD38B1.1080807@kom.aau.dk>
Hello!
> DSACK) is used, the retransmissions seem to happen earlier .
Yes. With SACK/FACK retransmissions can be triggered earlier,
if an ACK SACKs a segment which is far enough from current snd.una.
That's what happens f.e. in T_SACK_dump5.dat
01:28:15.681050 < 192.38.55.34.51137 > 192.168.110.111.42238: P 18825:20273[31857](1448) ack 1/5841 win 5840/0 <nop,nop,timestamp 418948058 469778216> [|] (DF)(ttl 64, id 19165)
01:28:15.800946 < 192.168.110.111.42238 > 192.38.55.34.51137: . 1:1[5841](0) ack 8689/31857 win 23168/0 <nop,nop,timestamp 469778229 418948031,nop,nop, sack 1 {10137:11585} > (DF) [tos 0x8] (ttl 62, id 45508)
01:28:15.860773 < 192.168.110.111.42238 > 192.38.55.34.51137: . 1:1[5841](0) ack 8689/31857 win 23168/0 <nop,nop,timestamp 469778235 418948031,nop,nop, sack 2 {13033:14481}{10137:11585} > (DF) [tos 0x8] (ttl 62, id 45509)
01:28:15.860781 < 192.38.55.34.51137 > 192.168.110.111.42238: . 8689:10137[31857](1448) ack 1/5841 win 5840/0 <nop,nop,timestamp 418948076 469778235> [|] (DF) (ttl 64, id 19166)
The second sack confirms that 13033..14481 already arrived.
And this is even not a mistake, the third dupack arrived immediately:
01:28:15.901382 < 192.168.110.111.42238 > 192.38.55.34.51137: . 1:1[5841](0) ack 8689/31857 win 23168/0 <nop,nop,timestamp 469778238 418948031,nop,nop, sack 2 {13033:15929}{10137:11585} > (DF) [tos 0x8] (ttl 62, id 45510)
Actually, it is the reason why the FACK heuristics is not disabled
even when FACK disabled. Experiments showed that relaxing it severely
damages recovery in presense of real multiple losses.
And when it happens to be reordering, undoing works really well.
There is one more thing, which probably happens in your experiments,
though I did not find it in dumps. If reordering exceeds RTT, i.e.
we receive SACK for a segment, which was sent as part of forward
retransmission after a hole was detected, fast retransmit entered immediately.
Two dupacks is enough for this: first triggers forward transmission,
if the second SACKs the segmetn which has just been sent, we are there.
> One more thing, say I have FRTO, DSACK and timestamps enabled, which
> algorithm takes precedence ?
They live together, essnetially, not dependant.
Alexey
next prev parent reply other threads:[~2006-07-19 13:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-18 19:38 Weird TCP SACK problem. in Linux Oumer Teyeb
2006-07-19 9:38 ` Xiaoliang (David) Wei
2006-07-19 10:00 ` Oumer Teyeb
2006-07-19 13:27 ` Alexey Kuznetsov [this message]
2006-07-19 15:02 ` Oumer Teyeb
2006-07-19 15:49 ` Alexey Kuznetsov
2006-07-19 16:32 ` Oumer Teyeb
2006-07-19 17:32 ` Oumer Teyeb
2006-07-20 15:41 ` Oumer Teyeb
2006-07-20 23:23 ` Alexey Kuznetsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060719132719.GA22143@ms2.inr.ac.ru \
--to=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=oumer@kom.aau.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).