Is there a TCP Maximum Segment Size (MSS) Minimum?
4
I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet).
EDIT: Reason: OpenVPN mssfix was mistakenly set to 1
36 92.064383 10.102.0.43 10.1.151.50 TCP 52 49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37 92.064763 10.1.151.50 10.102.0.43 TCP 52 63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
There are two devices on this network, which behave different.
- Win 10 PC with Filezilla FTP Server
- Embedded device (PLC) based on VxWorks with internal FTP server
The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.
41 92.171676 10.1.151.50 10.102.0.43 FTP-DATA 576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67 17.385576 10.1.151.1 10.102.0.43 FTP-DATA 100 FTP Data: 60 bytes (PASV) (RETR TCData.br)
Is that implemented on the right way on both sides?
I know that the default TCP MSS is 536, but is there a required minimum size?
ip tcp tcpip
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
add a comment |
4
I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet).
EDIT: Reason: OpenVPN mssfix was mistakenly set to 1
36 92.064383 10.102.0.43 10.1.151.50 TCP 52 49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37 92.064763 10.1.151.50 10.102.0.43 TCP 52 63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
There are two devices on this network, which behave different.
- Win 10 PC with Filezilla FTP Server
- Embedded device (PLC) based on VxWorks with internal FTP server
The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.
41 92.171676 10.1.151.50 10.102.0.43 FTP-DATA 576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67 17.385576 10.1.151.1 10.102.0.43 FTP-DATA 100 FTP Data: 60 bytes (PASV) (RETR TCData.br)
Is that implemented on the right way on both sides?
I know that the default TCP MSS is 536, but is there a required minimum size?
ip tcp tcpip
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49
add a comment |
4
4
4
I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet).
EDIT: Reason: OpenVPN mssfix was mistakenly set to 1
36 92.064383 10.102.0.43 10.1.151.50 TCP 52 49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37 92.064763 10.1.151.50 10.102.0.43 TCP 52 63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
There are two devices on this network, which behave different.
- Win 10 PC with Filezilla FTP Server
- Embedded device (PLC) based on VxWorks with internal FTP server
The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.
41 92.171676 10.1.151.50 10.102.0.43 FTP-DATA 576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67 17.385576 10.1.151.1 10.102.0.43 FTP-DATA 100 FTP Data: 60 bytes (PASV) (RETR TCData.br)
Is that implemented on the right way on both sides?
I know that the default TCP MSS is 536, but is there a required minimum size?
ip tcp tcpip
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet).
EDIT: Reason: OpenVPN mssfix was mistakenly set to 1
36 92.064383 10.102.0.43 10.1.151.50 TCP 52 49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37 92.064763 10.1.151.50 10.102.0.43 TCP 52 63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
There are two devices on this network, which behave different.
- Win 10 PC with Filezilla FTP Server
- Embedded device (PLC) based on VxWorks with internal FTP server
The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.
41 92.171676 10.1.151.50 10.102.0.43 FTP-DATA 576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67 17.385576 10.1.151.1 10.102.0.43 FTP-DATA 100 FTP Data: 60 bytes (PASV) (RETR TCData.br)
Is that implemented on the right way on both sides?
I know that the default TCP MSS is 536, but is there a required minimum size?
ip tcp tcpip
ip tcp tcpip
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
edited Jan 26 at 3:37
Michael Uray
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
asked Jan 26 at 2:15
Michael UrayMichael Uray
212
212
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49
add a comment |
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
});
}
});
draft saved
draft discarded
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%2fserverfault.com%2fquestions%2f950862%2fis-there-a-tcp-maximum-segment-size-mss-minimum%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Server Fault!
- 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.
draft saved
draft discarded
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%2fserverfault.com%2fquestions%2f950862%2fis-there-a-tcp-maximum-segment-size-mss-minimum%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
I have browsed through relevant RFCs and found no mention of a minimum value for MSS. The most relevant sources I could find were tools.ietf.org/html/rfc1122#page-85 and tools.ietf.org/html/rfc6691#section-2. From this it sounds like there is no minimum value. But a sender may need to subtract as much as 80 from the value to account for IPv4 and TCP options, thus an MSS smaller than 81 can potentially lead to breakage. It's not clear to me what the implication of IPv6 option headers would be.
– kasperd
Jan 26 at 12:41
Since the MTU can be as low as 68 bytes it may be necessary to fragment a TCP segment. So for the discussion in tools.ietf.org/html/rfc6691#section-2 to make sense it would have to apply before fragmentation. That means if a sender needs to use the full 40 bytes for IPv4 options and 40 bytes for TCP options and has received an MSS of 81 and has an MTU of 68. It would first produce a 121 byte TCP packet with 1 byte of payload, which is then fragmented into 8 fragments (7 of 68 bytes and one of 65 bytes). That would be a ridiculous overhead, but from my reading it's within specs.
– kasperd
Jan 26 at 12:49