CONGESTION CONTROL AND

PACKET REORDERING FOR

MULTIPATH
TRANSMISSION CONTROL
PROTOCOL
 Introduction
• Connections generally had only one path to
transfer data from source to destination.
• With new mobile devices have more than one
connections between the source and
destination.
• Newer technology was required to use them
at the same time to improve the throughput
like MultiPath Transmission Control Protocol.
 MPTCP
• Basic idea is that if flows are able to
simultaneously use more than one path through
the network, then they will be more resilient to
problems on particular paths and they will be
able to pool capacity across multiple links.
• These multiple paths might be obtained for
example by sending from multiple interfaces, or
sending to different IP addresses of the same
host, or by some form of explicit path control.
 MPTCP
Main Mechanism
• The Multipath TCP protocol uses new TCP options to
exchange signaling information between peers:
– MPC (Multipath Capable) is used during the three-way
handshake to establish a MultipathTCP connection.
– DATA FIN is used to inform the remote peer of the end of
data and to close the multipath TCP connections.
– ADD and REMove address are used to inform the remote
peer of the availability of a new address or to ask it to
ignore an existing one.
 MPTCP
Main Mechanism
– JOIN is used to initiate a new subflow between
nodes already used couple of addresses.
– DSN (Data Sequence Number) is used to map
between the subflow level and the data sequence
space number.
 MPTCP
Connection Establishment
 MPTCP
Subflow Initiation
 MPTCP
Congestion Control
• The following three goals as per IETF draft
capture the desirable properties of a practical
multipath congestion control algorithm:
– Improve Throughput: A multipath flow should perform at least as well
as a single path flow would on the best of the paths available to it.
– Do no harm: A multipath flow should not take up more capacity from
any of the resources shared by its different paths, than if it was a
single flow using only one of these paths. This guarantees it will not
unduly harm other flows.
– Balance congestion: A multipath flow should move as much traffic as
possible off its most congested paths, subject to meeting first two
goals.
 MPTCP
uncouple Congestion Control
• Uncoupled TCP
• when we run separate TCP congestion control
on each of the paths
• Increase wr by 1/wr per ack on path r.
– Decrease wr by wr/2 per loss event on path r.
 Couple congestion
What is changing?
• We only change behavior in congestion
avoidance phase
• All other algorithms are unchanged, and
will run independently per subflow
– Slow start
– Fast retransmit/fast recovery
– SACK
– RTT estimation
Coupled Congestion Control Algorithm

The algorithm we present only applies to the increase phase of the

congestion avoidance state specifying how the window inflates upon
receiving an ACK. The slow start, fast retransmit, and fast recovery
algorithms, as well as the multiplicative decrease of the congestion
avoidance state are the same as in standard TCP

Each subow in MPTCP maintains a congestion control

state (e.g., CWND and ssthresh) of itself and runs coupled
congestion control algorithm. This algorithm mainly makes
some modications of congestion avoidance phase in regular
TCP: when subow j receives an ACK, the increase of its
CWND is shown in (2) in unit of packet.
 Fully coupled
• Consider a multipath flow with available paths r
= 1, . . . , N, and suppose it uses window-based
flow control on each. Let wr be the window size
on flow r, and let
be the total window size. Use the following rule:
ALGORITHM: FULLY COUPLED
• increase wr by 1/w per ack on path r;
• decrease wr to max(wr − w/b, 1) per loss event
on path r; if there is truncation then do a
timeout but no slow-start; use b = 2 to mimic
TCP
 MPTCP
Congestion Control
• Fully Coupled
– Increase wr by 1/w per ack on path r.
– Decrease wr to max(wr - w/b, 1) per loss event on
path r
 MPTCP
Packet Reordering Techniques

• DSACK Algorithm :Using TCP Duplicate Selective cknowledgement

(DSACKs) andStream Control Transmission Protocol (SCTP) DuplicateTransmission

Sequence Numbers (TSNs) to Detect SpuriousRetransmissions

 packet scheduling for multipath TCP (Hwang j, Yoo j 2015)

• MPTCP shows worse performance than SPTCP that exploits the best
path when the flow size is small ,e.g only hundreds of KB.

• In this case, it would be better to use only the fastest path since the
delay is much more important than the network bandwidth in such
small data delivery.
 Problem statement :
 Default MPTCP packet scheduler may choose a slow path if the
congestion window of the fast path not available ,resulting in a long
flow completion time.
 MPTCP gives performance enhancement to the long-lived flows.
However, short flow are important since a large no of mobile
app,eg.,web browsing or messaging ,normally generate short flow
data traffic.
 packet scheduling for multipath TCP (Hwang j, Yoo j 2015)

The proposed solution (short flows and long-lived flow)

New MPTCP packet scheduler that freezes the slow path

temporarily when the delay difference between the slow and fast
paths is significant, so that the small amount of data can be
transmitted quickly via the fast path.
MPTCP maintains two types of sequence numbers, namely sub flow
sequence and data sequence ,to provide reliability and global
ordering.
 packet scheduling for multipath TCP (Hwang j, Yoo j 2015)

The packet scheduler responsible for distributing data packets over

multiple paths.
The scheduler choose the path that has the lowest –RTT. This policy
works better than the round robin policy.
Round robin policy takes an equal share of something in turn.
 packet scheduling for multipath TCP (Hwang j, Yoo j 2015)

The scheduler choose the path that has the lowest RTT among the
available paths while its congestion window is enough to send more
packets. When the congestion window become unavailable, the
scheduler choose the next lowest-RTT path.
Ex: suppose 2 paths _RTT1=10ms ,RTT2=100ms ,congestion
window size=10 for both paths.
If MPTCP app has 11 packets to send .how?
 Multipath TCP Packet Scheduling for Streaming video
(Ryota Matsufuji, Dirceu Cavendish, Kazumi Kumazoe, Daiki Nobayashi, Takeshi Ikenaga , japan 2017 )

 MPTCP packet scheduler works in two different configuration modes:

uncoupled, and coupled.
 In uncoupled mode, each sub-flow congestion window cwnd is adjusted independently.

 In coupled mode, MPTCP couples the congestion control of the sub-flows, by adjusting
the congestion window cwndk of a sub-flow k according with parameters of all sub-flows.
(change behavior in congestion avoidance phase)
Although there are several coupled mechanisms, we focus on Linked Increase Algorithm
(LIA) ,balanced linked increase algorithm (LIA), Opportunistic Linked Increase Algorithm
(OLIA) and Delay-based congestion control algorithm (w vegas).
 Multipath TCP Packet Scheduling for Streaming video
(Ryota Matsufuji, Dirceu Cavendish, Kazumi Kumazoe, Daiki Nobayashi, Takeshi Ikenaga , japan 2017 )
 Multipath Scheduling :(path selection and packet injection mechanisms)
 Shortest Packet Delay default scheduler,(SPD): In shortest packet delay, shortest RTT
 Scheduler ignore any path for which there is no space in its sub flow CWND
 Among the available paths, the scheduler then selects the path with small smooth RTT.
 Smooth rtt is computed as an average rtt of recent packets transmitted at that sub-flow.
 Largest packet credits(LPC):
 LPC addresses the path scenario in which a large rtt path has plenty of bandwidth.
 Among the sub-flows with space in their cwnd, this scheduler selects the one with largest
available space.
 Available space is the number of packets allowed by cwnd size minus the packets that
have not been acknowledged yet.
 Largest Estimated Throughput(LET):
 among the sub-flows with large enough cwnd to accommodate new packets, the
scheduler estimates the throughput of each sub-flow and selects the one with largest
throughput.
 LET addresses the scenario of a short path with plenty of bandwidth.
 MPTCP
Packet Reordering Technique

• Eifel Algorithm
 MPTCP
Packet Reordering Technique
• F-RTO Algorithm :Forward RTO-Recovery (FRTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP. the F-RTO algorithm declares a timeout spurious

– When the retransmission timer expires, retransmit the

segment that triggered the timeout.
– When the first acknowledgement after RTO arrives at
the sender, the sender chooses the following actions
depending in whether the ACK advances the window
or whether it is a duplicate ACK.
• If the acknowledgement advances SND.UNA (send
unacknowledged), transmit up to two new (previously unsent)
segments.
• If the acknowledgment is duplicate ACK, set the congestion
window to one segment and proceed with the conventional
RTO recovery.
 MPTCP
Packet Reordering Technique

– When the second acknowledgment after the RTO

arrives, either continue transmitting new data, or
start retransmission with the slow start algorithm,
depending on whether data was acknowledged.
• If the acknowledgement advances SND.UNA, continue
transmitting new data following the congestion
avoidance algorithm.
• If the acknowledgement is a duplicate ACK, set
congestion window to three segments, continue with
the slow start algorithm retransmitting
unacknowledged segments.
NS-3
 Results
• Topology 1
 Results
• Throughput for Uncoupled TCP congestion
control and No Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and D SACK Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and FRTO Packet reordering
 Results
• Round Trip Time for RTT Compensator
congestion control and FRTO Packet
reordering
 Results
• Topology 2
 Results
• Throughput for Uncoupled TCP congestion
control and No Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and D SACK Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and FRTO Packet reordering
 Results
• Round Trip Time for RTT Compensator
congestion control and FRTO Packet
reordering
 Results
• Topology 3
 Results
• Throughput for RTT Compensator congestion
control and F-RTO reordering
 Results
• Throughput for Uncoupled TCP congestion
control and No Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and D SACK Packet reordering
 Results
• Round Trip Time for RTT Compensator
congestion control and D SACK Packet
reordering
 Results
• Topology 4
 Results
• Throughput for RTT Compensator congestion
control and F-RTO reordering
 Results
• Throughput for Uncoupled TCP congestion
control and No Packet reordering
 Results
• Throughput for RTT Compensator congestion
control and D SACK Packet reordering
 Results
• Round Trip Time for RTT Compensator
congestion control and D SACK Packet
reordering
Heuristic Packet Scheduling Algorithm
• Send (Current + |delay1 − delay2| + 1) packet number with
maximum transmission unit bytes on the slower link first.
• Send (|delay1−delay2|+1) number of packets each with
(maximum transmission unit)/ (|delay1−delay2|+1)bytes on
the faster link.
• Send Cumulative Acknowledge on the faster link.
• Buffer on the receiver side save packets received.
• In case of loss of packet send the packet on slower or faster
link as the size of the packet and it is rearranged on the
receiver side.
 Conclusion
• We described the architecture and implementation of the
multipath transmission control protocol (MPTCP) in ns-3.6,
with various congestion control algorithms and packet
reordering algorithms.
• We also presented the throughput and round trip time for
various topologies using different congestion control and
packet reordering algorithms.
• We found out that congestion control algorithm given by IETF
namely, RTT Compensator and packer reordering technique F-
RTO gives good results but not the best results.
Thank You
and
Questions