From c541e5cc92e179c1510adb2a5088e58bc881cc19 Mon Sep 17 00:00:00 2001 From: Olivier Bonaventure Date: Tue, 17 Feb 2026 14:46:23 +0100 Subject: [PATCH] Variable length DSS option --- draft-baerts-tcpm-mptcpdss.md | 110 +++++++++++++++++++++------------- 1 file changed, 70 insertions(+), 40 deletions(-) diff --git a/draft-baerts-tcpm-mptcpdss.md b/draft-baerts-tcpm-mptcpdss.md index 2ec459f..59cacb1 100644 --- a/draft-baerts-tcpm-mptcpdss.md +++ b/draft-baerts-tcpm-mptcpdss.md @@ -1,5 +1,5 @@ --- -title: "Multipath TCP with longer DSS mappings" +title: "Multipath TCP with variable-length DSS mappings" category: std docname: draft-baerts-tcpm-mptcpdss-latest @@ -39,8 +39,10 @@ informative: --- abstract This document proposes an extension to improve Multipath TCP based on -operational experience by allowing Multipath TCP to use DSS mappings that are -longer than 64 KBytes. +operational experience by using variable-length encoding for the Subflow +Sequence Number and Data-Level Length fields of the DSS option. This allows +Multipath TCP to save option space for short connections while supporting +Data-Level Lengths larger than 64 KBytes. --- middle @@ -51,12 +53,15 @@ From a performance viewpoint, TCP stacks are optimised to leverage large segments and use TCP Segment Offload / Generic Receive Offload (TSO/GRO). The DSS option defined in Multipath TCP allows to map a series of bytes from the bytestream on a specific subflow. Unfortunately, the length of this mapping is -encoded in a 16-bit field. Since each Multipath TCP segment must include a DSS -mapping before being sent to the network interface, this restricts the size of -the segments that Multipath TCP can use. In particular in IPv6, it is impossible -for Multipath TCP to leverage IPv6 jumbograms {{RFC2675}} in contrast to regular -TCP. This document proposes a modification of the DSS option to support longer -mappings. +encoded in a 16-bit field and the Subflow Sequence Number always uses 4 bytes. +Since each Multipath TCP segment must include a DSS mapping before being sent to +the network interface, this restricts the size of the segments that Multipath TCP +can use. In particular in IPv6, it is impossible for Multipath TCP to leverage +IPv6 jumbograms {{RFC2675}} in contrast to regular TCP. Conversely, short +connections waste option space by always using a 4-byte Subflow Sequence Number. +This document proposes a modification of the DSS option to use variable-length +encoding for both the Subflow Sequence Number and the Data-Level Length, allowing +shorter encodings when possible and longer mappings when needed. # Conventions and Definitions @@ -66,12 +71,12 @@ mappings. # Extending the DSS option -The extension proposed in this document is pretty simple. Given that the DSS -Checksum is rarely used in practice, we propose to reuse the space reserved for -this checksum in the DSS option to support 32-bit data-level mappings. This -enables Multipath TCP servers to send segments that are longer than 64 KBytes. -This extension is negotiated using the TBD flag in the MP_CAPABLE option during -the handshake. +The extension proposed in this document modifies the DSS option to use +variable-length encoding for the Subflow Sequence Number (SSN) and the +Data-Level Length (DLL). Given that the DSS Checksum is rarely used in practice, +we propose to remove it and use flag bits in the reserved field to indicate the +length of the SSN and DLL fields. This extension is negotiated using the TBD +flag in the MP_CAPABLE option during the handshake. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -84,7 +89,7 @@ the handshake. ACK + MP_CAPABLE (+ data) -> [A's key, B's key, flags, (data-level details)] ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -{: #fig-dss-handshake title="Negotiation of the DSS option with longer mappings"} +{: #fig-dss-handshake title="Negotiation of the variable-length DSS option"} The DSS option defined in {{RFC8684}} reserves 16 bits for the Checksum. @@ -113,47 +118,69 @@ used by applications using Multipath TCP {{MPTCP-longitudinal}}. {: #fig-dss title="The DSS option in RFC8684"} -This document proposes to use a 32-bit Data-Level Length to support large TCP -segments. The new DSS option is shown in {{fig-newdss}}. The other fields of -this option and the procedures defined in {{RFC8684}} are unchanged. +## Variable-Length Encoding + +This document introduces a variable-length encoding for the SSN and DLL fields +of the DSS option. Two bits from the reserved field are used to indicate the +length of each field. The encoding is as follows: + +| Bits | Length | Maximum Value | +|------|---------|---------------| +| 00 | 2 bytes | 65,535 | +| 01 | 3 bytes | 16,777,215 | +| 10 | 4 bytes | 4,294,967,295 | +| 11 | Reserved | - | +{: #tab-varlen title="Variable-length encoding"} + +The `ss` bits indicate the length of the Subflow Sequence Number and the `dd` +bits indicate the length of the Data-Level Length. This encoding allows the DSS +option to use as few as 4 bytes for these two fields combined (when both use +2-byte encoding), compared to the 6 bytes used in {{RFC8684}} (4-byte SSN + +2-byte DLL) or the 8 bytes that would be needed with two fixed 4-byte fields. + +The Data-Level Length SHOULD NOT exceed 1,073,741,823 (about 1 GByte). + +The new DSS option is shown in {{fig-newdss}}. The Data ACK and Data Sequence +Number fields continue to use the existing `a`/`A` and `m`/`M` flags as defined +in {{RFC8684}}. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +---------------+---------------+-------+----------------------+ - | Kind | Length |Subtype| (reserved) |F|m|M|a|A| - +---------------+---------------+-------+----------------------+ + +---------------+---------------+-------+---+----+----+-+-+-+-+-+ + | Kind | Length |Subtype|rsv| ss | dd |F|m|M|a|A| + +---------------+---------------+-------+---+----+----+-+-+-+-+-+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ - | Subflow Sequence Number (4 octets) | - +-------------------------------+------------------------------+ - | Data-Level Length (4 octets) | - +-------------------------------+------------------------------+ + | Subflow Sequence Number (2, 3, or 4 octets, see ss) | + +--------------------------------------------------------------+ + | Data-Level Length (2, 3, or 4 octets, see dd) | + +--------------------------------------------------------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -{: #fig-newdss title="The new DSS option"} +{: #fig-newdss title="The new DSS option with variable-length SSN and DLL"} {{RFC8684}} defines the MP_CAPABLE option as shown in {{fig-oldmpc}}. This option contains several flags, A-H. Flags A, B, C, and H are specified in {{RFC8684}}. This document uses Flag TBD to indicate in a SYN that the initiator -of a connection requests the utilization of 32-bit Data-Level Length. If this -Flag is set in a SYN, Flag A must also obviously be set to 0 to indicate that -the Checksum is not required on this connection. If both Flags A and TBD are set -in a SYN, the receiver MUST not continue the MPTCP connection, and SHOULD -fallback to TCP. A server that receives a SYN with the TBD Flag set can reply -with: - -- a SYN+ACK with the TBD Flag set to 1 to confirm that it accepts to use 32-bit -Data-Level Length -- a SYN+ACK with the TBD Flag set to 0 to indicate that it prefers to use 16-bit -Data-Level Length +of a connection requests the utilization of the variable-length DSS option. If +this Flag is set in a SYN, Flag A must also obviously be set to 0 to indicate +that the Checksum is not required on this connection. If both Flags A and TBD +are set in a SYN, the receiver MUST not continue the MPTCP connection, and +SHOULD fallback to TCP. A server that receives a SYN with the TBD Flag set can +reply with: + +- a SYN+ACK with the TBD Flag set to 1 to confirm that it accepts to use the +variable-length DSS option +- a SYN+ACK with the TBD Flag set to 0 to indicate that it prefers to use the +standard DSS option as defined in {{RFC8684}} Even when the TBD Flag is set to 1, the MP_CAPABLE options continue to use a 16-bit Data-Level Length like before, to allow fallback if the receiver doesn't -support a 32-bit Data-Level Length. +support the variable-length DSS option. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -186,7 +213,10 @@ This document does not change the security considerations defined in This document requests the IANA to reserve flag TBD of the MP_CAPABLE option as defined in this document. It also proposes to change the format of the DSS -option. This document suggests using the D flag of the MP_CAPABLE option. +option by introducing variable-length encoding for the Subflow Sequence Number +and Data-Level Length fields using 4 bits (ss, dd) from the reserved field of +the DSS option. This document suggests using the D flag of the MP_CAPABLE +option. --- back