Users.ConfigureMPTCP History
Hide minor edits - Show changes to output
October 28, 2024, at 09:42 AM
by - Banner: only for <5.6
Added lines 1-8:
%p bgcolor=#ffeeee font-weight=bold text-align=center% [+If you are looking for MPTCP in Linux >= v5.6:+]
\\
\\
https://mptcp.dev
\\
\\
For Linux <= 5.4, you can stay on this website.
\\
\\
https://mptcp.dev
\\
\\
For Linux <= 5.4, you can stay on this website.
June 14, 2021, at 11:54 AM
by - netlink PM
Added line 47:
* '''New in v0.95''': 'netlink': This path-manager can be controlled from the userspace. See the [[https://github.com/multipath-tcp/mptcp/blob/mptcp_trunk/include/uapi/linux/mptcp.h|source code]] for the API documentation or [[https://github.com/intel/mptcpd|mptcpd]] for an Open-Source daemon.
March 11, 2021, at 10:29 AM
by - fix len getsocktopt(MPTCP_INFO)
Changed lines 80-82 from:
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
to:
struct tcp_info others[3]; // increase it if needed
struct mptcp_sub_info others_info[3]; // same
socklen_t len;
len = sizeof(minfo);
struct mptcp_sub_info others_info[3]; // same
socklen_t len;
len = sizeof(minfo);
Changed line 95 from:
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
to:
getsockopt(<fd>, IPPROTO_TCP, MPTCP_INFO, &minfo, &len);
September 16, 2019, at 08:33 AM
by - fix typo reported on Github https://github.com/multipath-tcp/mptcp/issues/362
Changed line 49 from:
char *pathmanager = "ndiffports";
to:
char pathmanager[] = "ndiffports";
Changed line 67 from:
char *scheduler = "redundant";
to:
char scheduler[] = "redundant";
Added lines 95-101:
The initial subflow might have disappeared at the time when you call the getsockopt. To make sure that the information about the initial subflow is stored, you can let MPTCP know by using setsockopt on MPTCP_INFO with the flag MPTCP_INFO_FLAG_SAVE_MASTER (defined as 0x01):
#define MPTCP_INFO_FLAG_SAVE_MASTER 0x01
int val = MPTCP_INFO_FLAG_SAVE_MASTER;
setsockopt(..., ..., MPTCP_INFO, &val, sizeof(val));
That way, even if the initial subflow has been closed, you will be able to get the information later on when you call the getsockopt.
#define MPTCP_INFO_FLAG_SAVE_MASTER 0x01
int val = MPTCP_INFO_FLAG_SAVE_MASTER;
setsockopt(..., ..., MPTCP_INFO, &val, sizeof(val));
That way, even if the initial subflow has been closed, you will be able to get the information later on when you call the getsockopt.
Changed lines 19-20 from:
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
to:
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 42) to 1. MPTCP_ENABLED is part of SOL_TCP:
Added lines 25-26:
You can use MPTCP_ENABLED also to get information about whether MPTCP has been successfully negotiated by using getsockopt.
Changed line 76 from:
You can use our new socket-option MPTCP_INFO (defined as 42), to get detailed information about each subflow (e.g., struct tcp_info):
to:
You can use our new socket-option MPTCP_INFO (defined as 45), to get detailed information about each subflow (e.g., struct tcp_info):
Changed lines 41-42 from:
'New in v0.92': If you want to re-create subflows after a timeout (e.g., if the NAT-mapping was lost due to idle-time), you can set /sys/module/mptcp_fullmesh/parameters/create_on_err to 1.
to:
'''New in v0.92''': If you want to re-create subflows after a timeout (e.g., if the NAT-mapping was lost due to idle-time), you can set /sys/module/mptcp_fullmesh/parameters/create_on_err to 1.
Changed lines 12-13 from:
!!New in Version 0.92.x
to:
!!Version >= 0.92.x
Changed line 45 from:
'New in v0.92': Alternatively, you can select the path-manager through the socket-option MPTCP_PATH_MANAGER (defined as 44) by doing:
to:
'''New in v0.92''': Alternatively, you can select the path-manager through the socket-option MPTCP_PATH_MANAGER (defined as 44) by doing:
Changed line 63 from:
'New in v0.92': Alternatively, you can select the scheduler through the socket-option MPTCP_SCHEDULER (defined as 43) by doing:
to:
'''New in v0.92''': Alternatively, you can select the scheduler through the socket-option MPTCP_SCHEDULER (defined as 43) by doing:
Added lines 70-71:
'''New in v0.92'''
Changed lines 14-18 from:
char *scheduler = "redundant";
setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
* Select an MPTCP path-manager with the socket-option MPTCP_PATH_MANAGER (defined as 44). For example:
to:
To set a sysctl variable, just do:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]],[[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
'New in v0.92': If you want to re-create subflows after a timeout (e.g., if the NAT-mapping was lost due to idle-time), you can set /sys/module/mptcp_fullmesh/parameters/create_on_err to 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
'New in v0.92': Alternatively, you can select the path-manager through the socket-option MPTCP_PATH_MANAGER (defined as 44) by doing:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]],[[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
'New in v0.92': If you want to re-create subflows after a timeout (e.g., if the NAT-mapping was lost due to idle-time), you can set /sys/module/mptcp_fullmesh/parameters/create_on_err to 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
'New in v0.92': Alternatively, you can select the path-manager through the socket-option MPTCP_PATH_MANAGER (defined as 44) by doing:
Changed lines 49-69 from:
struct mptcp_info minfo;
struct mptcp_meta_info meta_info;
struct tcp_info initial;
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
minfo.tcp_info_len = sizeof(struct tcp_info);
minfo.sub_len = sizeof(others);
minfo.meta_len = sizeof(struct mptcp_meta_info);
minfo.meta_info = &meta_info;
minfo.initial = &initial;
minfo.subflows = &others;
minfo.sub_info_len = sizeof(struct mptcp_sub_info);
minfo.total_sub_info_len = sizeof(others_info);
minfo.subflow_info = &others_info;
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
* Allow creating a new TCP subflow on an interface after a timeout when the fullmesh path-manager is used by doing:
echo 1 > /sys/module/mptcp_fullmesh/parameters/create_on_err
to:
Added lines 51-66:
!!!!Configure the scheduler:
We have a modular scheduler infrastructure. At compile-time you can select the
schedulers that should be compiled in.
At run-time you can select one of the compiled schedulers through the sysctl net.mptcp.mptcp_scheduler.
You have the choice between:
* 'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.
* 'roundrobin': This scheduler will transmit traffic in a round-robin fashion. It is configurable, how many consecutive segments should be sent with the tunable "num_segments" in the sysfs (default 1). Additionally, you can set the boolean tunable "cwnd_limited", to specify whether the scheduler tries to fill the congestion window on all subflows (true) or whether it prefers to leave open space in the congestion window (false) to achieve real round-robin (even if the subflows have very different capacities) (defaults to true). In case you are unsure, never ever enable this scheduler. Its performance is bad and it is only interesting for academic/testing purposes. The default scheduler is the best known up to today.
* 'redundant': This scheduler will try to transmit the traffic on all available subflows in a redundant way. It is useful when one wants to achieve the lowest possible latency by sacrificing the bandwidth.
'New in v0.92': Alternatively, you can select the scheduler through the socket-option MPTCP_SCHEDULER (defined as 43) by doing:
char *scheduler = "redundant";
setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
Changed lines 69-95 from:
to:
!!!!Get detailed information of your subflows
You can use our new socket-option MPTCP_INFO (defined as 42), to get detailed information about each subflow (e.g., struct tcp_info):
struct mptcp_info minfo;
struct mptcp_meta_info meta_info;
struct tcp_info initial;
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
minfo.tcp_info_len = sizeof(struct tcp_info);
minfo.sub_len = sizeof(others);
minfo.meta_len = sizeof(struct mptcp_meta_info);
minfo.meta_info = &meta_info;
minfo.initial = &initial;
minfo.subflows = &others;
minfo.sub_info_len = sizeof(struct mptcp_sub_info);
minfo.total_sub_info_len = sizeof(others_info);
minfo.subflow_info = &others_info;
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
\\
\\
!!Version == 0.91.x
You can use our new socket-option MPTCP_INFO (defined as 42), to get detailed information about each subflow (e.g., struct tcp_info):
struct mptcp_info minfo;
struct mptcp_meta_info meta_info;
struct tcp_info initial;
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
minfo.tcp_info_len = sizeof(struct tcp_info);
minfo.sub_len = sizeof(others);
minfo.meta_len = sizeof(struct mptcp_meta_info);
minfo.meta_info = &meta_info;
minfo.initial = &initial;
minfo.subflows = &others;
minfo.sub_info_len = sizeof(struct mptcp_sub_info);
minfo.total_sub_info_len = sizeof(others_info);
minfo.subflow_info = &others_info;
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
\\
\\
!!Version == 0.91.x
Added lines 40-42:
* Allow creating a new TCP subflow on an interface after a timeout when the fullmesh path-manager is used by doing:
echo 1 > /sys/module/mptcp_fullmesh/parameters/create_on_err
Changed lines 19-21 from:
to:
char *pathmanager = "ndiffports";
setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
Changed lines 23-39 from:
to:
struct mptcp_info minfo;
struct mptcp_meta_info meta_info;
struct tcp_info initial;
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
minfo.tcp_info_len = sizeof(struct tcp_info);
minfo.sub_len = sizeof(others);
minfo.meta_len = sizeof(struct mptcp_meta_info);
minfo.meta_info = &meta_info;
minfo.initial = &initial;
minfo.subflows = &others;
minfo.sub_info_len = sizeof(struct mptcp_sub_info);
minfo.total_sub_info_len = sizeof(others_info);
minfo.subflow_info = &others_info;
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
struct mptcp_meta_info meta_info;
struct tcp_info initial;
struct tcp_info others[3];
struct mptcp_sub_info others_info[3];
minfo.tcp_info_len = sizeof(struct tcp_info);
minfo.sub_len = sizeof(others);
minfo.meta_len = sizeof(struct mptcp_meta_info);
minfo.meta_info = &meta_info;
minfo.initial = &initial;
minfo.subflows = &others;
minfo.sub_info_len = sizeof(struct mptcp_sub_info);
minfo.total_sub_info_len = sizeof(others_info);
minfo.subflow_info = &others_info;
getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
Changed lines 15-16 from:
to:
char *scheduler = "redundant";
setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
Changed lines 15-16 from:
@@setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
to:
@@char *scheduler = "redundant";
@@setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
@@setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
Changed lines 15-17 from:
@@ char *scheduler = "redundant";
@@ setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
@@
to:
@@char *scheduler = "redundant";
@@setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
@@setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
Changed lines 19-20 from:
@@ char *pathmanager = "ndiffports";
@@ setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
@@
to:
@@char *pathmanager = "ndiffports";
@@setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
@@setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
Added lines 11-39:
!!New in Version 0.92.x
* Select an MPTCP-scheduler with the socket-option MPTCP_SCHEDULER (defined as 43). For example:
@@ char *scheduler = "redundant";
@@ setsockopt(fd, SOL_TCP, MPTCP_SCHEDULER, scheduler, sizeof(scheduler));
* Select an MPTCP path-manager with the socket-option MPTCP_PATH_MANAGER (defined as 44). For example:
@@ char *pathmanager = "ndiffports";
@@ setsockopt(fd, SOL_TCP, MPTCP_PATH_MANAGER, pathmanager, sizeof(pathmanager));
* Get detailled information on the subflows with MPTCP_INFO (defined as 42). For example:
@@ struct mptcp_info minfo;
@@ struct mptcp_meta_info meta_info;
@@ struct tcp_info initial;
@@ struct tcp_info others[3];
@@ struct mptcp_sub_info others_info[3];
@@ minfo.tcp_info_len = sizeof(struct tcp_info);
@@ minfo.sub_len = sizeof(others);
@@ minfo.meta_len = sizeof(struct mptcp_meta_info);
@@ minfo.meta_info = &meta_info;
@@ minfo.initial = &initial;
@@ minfo.subflows = &others;
@@ minfo.sub_info_len = sizeof(struct mptcp_sub_info);
@@ minfo.total_sub_info_len = sizeof(others_info);
@@ minfo.subflow_info = &others_info;
@@ getsockopt(..., ..., MPTCP_INFO, &minfo, sizeof(minfo));
Changed lines 12-13 from:
to:
!!Version >= 0.91.x
To set a sysctl variable, just do:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]],[[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
\\
!!!!Configure the scheduler:
We have a modular scheduler infrastructure. At compile-time you can select the
schedulers that should be compiled in.
At run-time you can select one of the compiled schedulers through the sysctl net.mptcp.mptcp_scheduler.
You have the choice between:
* 'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.
* 'roundrobin': This scheduler will transmit traffic in a round-robin fashion. It is configurable, how many consecutive segments should be sent with the tunable "num_segments" in the sysfs (default 1). Additionally, you can set the boolean tunable "cwnd_limited", to specify whether the scheduler tries to fill the congestion window on all subflows (true) or whether it prefers to leave open space in the congestion window (false) to achieve real round-robin (even if the subflows have very different capacities) (defaults to true). In case you are unsure, never ever enable this scheduler. Its performance is bad and it is only interesting for academic/testing purposes. The default scheduler is the best known up to today.
* 'redundant': This scheduler will try to transmit the traffic on all available subflows in a redundant way. It is useful when one wants to achieve the lowest possible latency by sacrificing the bandwidth.
\\
\\
!!Version == 0.90.x
To set a sysctl variable, just do:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]],[[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
\\
!!!!Configure the scheduler:
We have a modular scheduler infrastructure. At compile-time you can select the
schedulers that should be compiled in.
At run-time you can select one of the compiled schedulers through the sysctl net.mptcp.mptcp_scheduler.
You have the choice between:
* 'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.
* 'roundrobin': This scheduler will transmit traffic in a round-robin fashion. It is configurable, how many consecutive segments should be sent with the tunable "num_segments" in the sysfs (default 1). Additionally, you can set the boolean tunable "cwnd_limited", to specify whether the scheduler tries to fill the congestion window on all subflows (true) or whether it prefers to leave open space in the congestion window (false) to achieve real round-robin (even if the subflows have very different capacities) (defaults to true). In case you are unsure, never ever enable this scheduler. Its performance is bad and it is only interesting for academic/testing purposes. The default scheduler is the best known up to today.
* 'redundant': This scheduler will try to transmit the traffic on all available subflows in a redundant way. It is useful when one wants to achieve the lowest possible latency by sacrificing the bandwidth.
\\
\\
!!Version == 0.90.x
Changed line 29 from:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
to:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]],[[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
Changed line 76 from:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
to:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[http://tools.ietf.org/html/draft-xu-mptcp-congestion-control/|@@wVegas@@ (alias Delay-based Congestion Control for MPTCP)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
Changed lines 12-13 from:
to:
!!Version >= 0.90.x
To set a sysctl variable, just do:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
\\
!!!!Configure the scheduler:
We have a modular scheduler infrastructure. At compile-time you can select the
schedulers that should be compiled in.
At run-time you can select one of the compiled schedulers through the sysctl net.mptcp.mptcp_scheduler.
You have the choice between:
* 'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.
* 'roundrobin': This scheduler will transmit traffic in a round-robin fashion. It is configurable, how many consecutive segments should be sent with the tunable "num_segments" in the sysfs (default 1). Additionally, you can set the boolean tunable "cwnd_limited", to specify whether the scheduler tries to fill the congestion window on all subflows (true) or whether it prefers to leave open space in the congestion window (false) to achieve real round-robin (even if the subflows have very different capacities) (defaults to true). In case you are unsure, never ever enable this scheduler. Its performance is bad and it is only interesting for academic/testing purposes. The default scheduler is the best known up to today.
\\
\\
!!Version == 0.89.x
To set a sysctl variable, just do:
@@sysctl -w net.mptcp.[name of the variable]=[value]@@
* @@net.mptcp.mptcp_enabled@@ Disable/Enable MPTCP on this machine. Possible values are 0 or 1. (default 1)
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
@@int enable = 1;@@
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
* @@net.mptcp.mptcp_checksum@@ Disable/Enable the MPTCP checksum. As described in the draft, both sides (client and server) have to disable DSS-checksums. If one side has it enabled, DSS-checksums will be used. Possible values are 0 or 1. (default 1)
* @@net.mptcp.mptcp_syn_retries@@ Specifies how often we retransmit a SYN with the MP_CAPABLE-option. After this, the SYN will not contain the MP_CAPABLE-option. This is to handle middleboxes that drop SYNs with unknown TCP options. Default is 3.
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
\\
!!!!Configure the path-manager:
We have a modular structure for the path-manager. At compile-time you can enable the path-managers through "MPTCP: advanced path-manager control" and select for example the full-mesh path-manager. If you do not select a path-manager, the host will not trigger the creation of new subflows, nor advertise alternative IP-addresses through the ADD_ADDR-option.
At run-time, to select one of the compiled path-managers just set the sysctl net.mptcp.mptcp_path_manager.
You have the choice between:
* 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows.
* 'fullmesh': It will create a full-mesh of subflows among all available subflows. Since v0.90 it is possible to create multiple subflows for each pair of IP-addresses. Just set /sys/module/mptcp_fullmesh/parameters/num_subflows to a value > 1.
* 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysfs /sys/module/mptcp_ndiffports/parameters/num_subflows to a value > 1.
* 'binder': The path-manager using Loose Source Routing from the paper [[http://dl.acm.org/citation.cfm?id=2502894|Binder: a system to aggregate multiple internet gateways in community networks]].
\\
!!!!Configure the scheduler:
We have a modular scheduler infrastructure. At compile-time you can select the
schedulers that should be compiled in.
At run-time you can select one of the compiled schedulers through the sysctl net.mptcp.mptcp_scheduler.
You have the choice between:
* 'default': This scheduler is the default one. It will first send data on subflows with the lowest RTT until their congestion-window is full. Then, it will start transmitting on the subflows with the next higher RTT.
* 'roundrobin': This scheduler will transmit traffic in a round-robin fashion. It is configurable, how many consecutive segments should be sent with the tunable "num_segments" in the sysfs (default 1). Additionally, you can set the boolean tunable "cwnd_limited", to specify whether the scheduler tries to fill the congestion window on all subflows (true) or whether it prefers to leave open space in the congestion window (false) to achieve real round-robin (even if the subflows have very different capacities) (defaults to true). In case you are unsure, never ever enable this scheduler. Its performance is bad and it is only interesting for academic/testing purposes. The default scheduler is the best known up to today.
\\
\\
!!Version == 0.89.x
Changed lines 29-30 from:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
to:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm)]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
Changed line 94 from:
%newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@coupled@@ (alias Linked Increase Algorithm)]] and %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm]] are available through @@net.ipv4.tcp_congestion_control@@.
to:
%newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@coupled@@ (alias Linked Increase Algorithm)]] and %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm)]] are available through @@net.ipv4.tcp_congestion_control@@.
Added lines 27-29:
You can also configure different congestion controls. The available congestion controls are %newwin%[[https://datatracker.ietf.org/doc/rfc6356/|@@lia@@ (alias Linked Increase Algorithm)]], %newwin%[[https://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control/|@@olia@@ (alias Opportunistic Linked Increase Algorithm]] and [[https://datatracker.ietf.org/doc/draft-walid-mptcp-congestion-control/|@@balia@@ (alias Balanced Linked Adaptation Congestion Control Algorithm]]. You can change them via the sysctl @@net.ipv4.tcp_congestion_control@@.
Changed line 19 from:
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SO_TCP:
to:
Since release 0.89, you can set mptcp_enabled to 2. In this case MPTCP will be enabled if the application has set the socket-option MPTCP_ENABLED (value 26) to 1. MPTCP_ENABLED is part of SOL_TCP:
Changed line 23 from:
@@setsockopt(fd, SO_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@
to:
@@setsockopt(fd, SOL_TCP, MPTCP_ENABLED, &enable, sizeof(enable));@@