fast retransmit does not work
Fast retransmit says that if 3 dupacks have been received by sender, then the sender should retransmit the lost packet. But my tcpdump output shows that it didn't work like this. It didn't retransmit the packet even more than 10 dupacks have been received.
Why didn't it triggerfast retransmit? Does anyone has idea about this? Thanks
cat /proc/version:
Linux version 4.2.0-42-generic (buildd@lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016
sysctl:
net.ipv4.tcp_congestion_control = cubic
ubuntu tcp ack
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
bumped to the homepage by Community♦ 2 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
Fast retransmit says that if 3 dupacks have been received by sender, then the sender should retransmit the lost packet. But my tcpdump output shows that it didn't work like this. It didn't retransmit the packet even more than 10 dupacks have been received.
Why didn't it triggerfast retransmit? Does anyone has idea about this? Thanks
cat /proc/version:
Linux version 4.2.0-42-generic (buildd@lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016
sysctl:
net.ipv4.tcp_congestion_control = cubic
ubuntu tcp ack
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
bumped to the homepage by Community♦ 2 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
In our systems,net.ipv4.tcp_timestamps=0andnet.ipv4.tcp_sack=0
– chengtcli
Aug 30 '16 at 1:38
add a comment |
Fast retransmit says that if 3 dupacks have been received by sender, then the sender should retransmit the lost packet. But my tcpdump output shows that it didn't work like this. It didn't retransmit the packet even more than 10 dupacks have been received.
Why didn't it triggerfast retransmit? Does anyone has idea about this? Thanks
cat /proc/version:
Linux version 4.2.0-42-generic (buildd@lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016
sysctl:
net.ipv4.tcp_congestion_control = cubic
ubuntu tcp ack
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
Fast retransmit says that if 3 dupacks have been received by sender, then the sender should retransmit the lost packet. But my tcpdump output shows that it didn't work like this. It didn't retransmit the packet even more than 10 dupacks have been received.
Why didn't it triggerfast retransmit? Does anyone has idea about this? Thanks
cat /proc/version:
Linux version 4.2.0-42-generic (buildd@lgw01-55) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016
sysctl:
net.ipv4.tcp_congestion_control = cubic
ubuntu tcp ack
ubuntu tcp ack
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
edited Aug 29 '16 at 0:54
chengtcli
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
asked Aug 28 '16 at 5:08
chengtclichengtcli
63
63
bumped to the homepage by Community♦ 2 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 2 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
In our systems,net.ipv4.tcp_timestamps=0andnet.ipv4.tcp_sack=0
– chengtcli
Aug 30 '16 at 1:38
add a comment |
In our systems,net.ipv4.tcp_timestamps=0andnet.ipv4.tcp_sack=0
– chengtcli
Aug 30 '16 at 1:38
In our systems,
net.ipv4.tcp_timestamps=0 and net.ipv4.tcp_sack=0– chengtcli
Aug 30 '16 at 1:38
In our systems,
net.ipv4.tcp_timestamps=0 and net.ipv4.tcp_sack=0– chengtcli
Aug 30 '16 at 1:38
add a comment |
1 Answer
1
active
oldest
votes
Please check "tcp_thin_dupack"
sysctl net.ipv4.tcp_thin_dupack
net.ipv4.tcp_thin_dupack = 0
tcp_thin_dupack - BOOLEAN
Enable dynamic triggering of retransmissions after one dupACK
for thin streams. If set, a check is performed upon reception
of a dupACK to determine if the stream is thin (less than 4
packets in flight). As long as the stream is found to be thin,
data is retransmitted on the first received dupACK. This
improves retransmission latency for non-aggressive thin
streams, often found to be time-dependent.
For more information on thin streams, see
Documentation/networking/tcp-thin.txt
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f306167%2ffast-retransmit-does-not-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Please check "tcp_thin_dupack"
sysctl net.ipv4.tcp_thin_dupack
net.ipv4.tcp_thin_dupack = 0
tcp_thin_dupack - BOOLEAN
Enable dynamic triggering of retransmissions after one dupACK
for thin streams. If set, a check is performed upon reception
of a dupACK to determine if the stream is thin (less than 4
packets in flight). As long as the stream is found to be thin,
data is retransmitted on the first received dupACK. This
improves retransmission latency for non-aggressive thin
streams, often found to be time-dependent.
For more information on thin streams, see
Documentation/networking/tcp-thin.txt
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
add a comment |
Please check "tcp_thin_dupack"
sysctl net.ipv4.tcp_thin_dupack
net.ipv4.tcp_thin_dupack = 0
tcp_thin_dupack - BOOLEAN
Enable dynamic triggering of retransmissions after one dupACK
for thin streams. If set, a check is performed upon reception
of a dupACK to determine if the stream is thin (less than 4
packets in flight). As long as the stream is found to be thin,
data is retransmitted on the first received dupACK. This
improves retransmission latency for non-aggressive thin
streams, often found to be time-dependent.
For more information on thin streams, see
Documentation/networking/tcp-thin.txt
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
add a comment |
Please check "tcp_thin_dupack"
sysctl net.ipv4.tcp_thin_dupack
net.ipv4.tcp_thin_dupack = 0
tcp_thin_dupack - BOOLEAN
Enable dynamic triggering of retransmissions after one dupACK
for thin streams. If set, a check is performed upon reception
of a dupACK to determine if the stream is thin (less than 4
packets in flight). As long as the stream is found to be thin,
data is retransmitted on the first received dupACK. This
improves retransmission latency for non-aggressive thin
streams, often found to be time-dependent.
For more information on thin streams, see
Documentation/networking/tcp-thin.txt
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
Please check "tcp_thin_dupack"
sysctl net.ipv4.tcp_thin_dupack
net.ipv4.tcp_thin_dupack = 0
tcp_thin_dupack - BOOLEAN
Enable dynamic triggering of retransmissions after one dupACK
for thin streams. If set, a check is performed upon reception
of a dupACK to determine if the stream is thin (less than 4
packets in flight). As long as the stream is found to be thin,
data is retransmitted on the first received dupACK. This
improves retransmission latency for non-aggressive thin
streams, often found to be time-dependent.
For more information on thin streams, see
Documentation/networking/tcp-thin.txt
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
answered Aug 28 '16 at 7:31
0x0C40x0C4
34516
34516
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
add a comment |
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
it seems that the tcp_thin_dupack is able to trigger fast retransmit with one DUP ack, so it can improve retransmission latency. But this seems can't explain why fast retransmit was not triggered with multi DUP acks.
– chengtcli
Aug 28 '16 at 8:29
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f306167%2ffast-retransmit-does-not-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
In our systems,
net.ipv4.tcp_timestamps=0andnet.ipv4.tcp_sack=0– chengtcli
Aug 30 '16 at 1:38