Skip to content

Variable length DSS option #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
obonaventure wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Variable length DSS option #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 70 additions & 40 deletions draft-baerts-tcpm-mptcpdss.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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.


~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand All @@ -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.
Expand Down Expand Up @@ -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.


~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down Expand Up @@ -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
Expand Down