The document proposes RAMPTCP, a receiver-assisted extension to MPTCP for edge clouds. RAMPTCP aims to improve MPTCP performance in edge-to-edge networks by having the receiver send network condition information to help the sender make better scheduling decisions. Preliminary ns3 simulations show RAMPTCP achieves around 19% higher throughput and 58% fewer retransmissions compared to default MPTCP in a scenario where one network path experiences packet loss. Future work includes incorporating different access technologies and developing effective RAMPTCP control actions.

1. Redesigning MPTCP for Edge
Clouds
ACM Mobicom 2018 Student Research Competition
Delhi, India
Nitinder Mohan
⊥
Tanya Shreedhar
∤
Aleksandr Zavodovski
⊥
Otto Waltari
⊥
Jussi Kangasharju
⊥
Sanjit K. Kaul
∤
⊥
University of Helsinki, Finland
∤
IIIT Delhi, India

2. Edge Networks
• Small-scale server(s) equipped with multiple NIC at network “edge”
• Distribute data with other edge servers over last-mile wireless
links
• Support for cloud technologies and scenarios such as
container/VM migration etc. developed for managed networks
Edge-to-Edge networks must ensure network reliability from
A1
A2
Core
Network
B2
B1
VM
2

3. • Standardized kernel extension to TCP
• Forms multiple TCP flows over all available network interfaces
to simultaneously utilize them
Improvements: Increased robustness, bandwidth aggregation,
seamless handovers etc.
Multipath-TCP on Edge
MPTCP
TCP
Flow 1
A1
A2
Core
Network
B2
B1
TCP
Flow 1
TCP
Flow 2
TCP
Flow 2
VM
MPTCP
SRTTflow1
SRTTflow2
?SRTTflow1
<
SRTTflow2?
3

4. Default MPTCP Performance
How does MPTCP perform in real Edge ↔ Edge
scenario?
Setup: Both Sender and Receiver are equipped with two 802.11g WiFi over
MPTCP v0.94
Network test: B2 interface at receiver starts to experience packet loss with
20% probability
MPTCP
TCP
Flow 1
A1
A2
Core
Network
B2
B1
TCP
Flow 1
TCP
Flow 2
TCP
Flow 2
MPTCP
4

5. Default MPTCP Performance
t1
t2
t1: Packet errors start on flow 2
t2: MPTCP stops using flow 2 as
SRTTflow1 << SRTTflow2
5

6. Default MPTCP Performance
After t1:
→ 43% new packets injected on
flow 2
→ 74% packets re-transmitted
6

7. MPTCP Sub-optimal Flow Decisions
1. SRTT is a delayed metric for estimating network conditions
• Cannot pin-point exact source of delay in network
• Cannot react to cause of delay
2. Little to no interaction between individual flows
• Highly dependent on individual TCP flow throttling and adjustment
3. Sender is King!
Current MPTCP is a dumb collection of multiple
individual TCP connections
7

8. Receiver-Assisted MPTCP (RAMPTCP)
“Reliability-first” extension to MPTCP by reducing
packet re-transmission and re-ordering
1. Enables receiver to send its readily-available last-mile
characteristics to sender in ACK
e.g. channel utilization, signal strength, path loss% etc.
2. Sender can use extra information along with SRTT to better
estimate network conditions
8

9. RAMPTCP in Action
Data Delivery
Reverse-Path Information
Delivery
Per-Segment Delay
Estimation
Flow Control Actions
9

10. Path 2
A2
A1 B1
B2
Path 1
Data Delivery
Reverse-Path Information
Delivery
Per-Segment Delay
EstimationFlow Control Actions
Seq: 1
Data
Seq: 2
Data
10

11. Path 2
A2
A1 B1
B2
Path 1
Seq: 1
B1:
B2:
Data Delivery
Reverse-Path Information
Delivery
Per-Segment Delay
EstimationFlow Control Actions
10

12. Path 2
A2
A1 B1
B2
Path 1
RTTpath = Tsender + Tcore + Treceiver
Data Delivery
Reverse-Path Information
Delivery
Per-Segment Delay
EstimationFlow Control Actions
10

13. Path 2
A2
A1 B1
B2
Path 1
Data Delivery
Reverse-Path Information
Delivery
Per-Segment Delay
EstimationFlow Control Actions
Seq: 3
DataSeq: 4
Data
Possible control actions:
Limit packets on flow, Out-of-order injection,
Packet duplication, Change TCP send rate,
Boycott flow usage, …
10

14. Preliminary Evaluation
ns3 Simulation based on Direct Code Emulation (DCE)
B1 interface suffers packet losses due to interference from 2-5sMPTCP
TCP
Flow 1
A1
A2
Core
Network
B2
B1
TCP
Flow 1
TCP
Flow 2
TCP
Flow 2
MPTCP
11
0
5
10
15
Throughput(Mbps)
0 1 2 3 4 5 6 7 8 9 10
Time (secs)
0
5
10
15
Flow 1
Flow 2
MPTCP
RAMPTCP
≈19% increase in
throughput
≈ 58% reductions in
retrasmissions

15. Discussion and Future Work
1. Incorporate any access-layer technology i.e. WiFi, Ethernet,
LTE, 5G etc.
2. How to effectively send receiver-side information to sender?
3. Effective RAMPTCP control decisions?
RaspberryPi
Battery
LTE modem 12

16. Thank You!
nitinder.mohan@helsinki.fi

17. Rise of Edge Clouds
Network
DatacenterEdge
Server
User
→ Small servers deployed at network
edge to compute user data
→ Equipped with multiple NIC with
different access technology e.g. WiFi,
LTE, Ethernet etc.
Motivation:
Decreased latency and network traffic
Computing data of local relevance
Low network delay requirements 17

18. Preliminary Evaluation
ns3 Simulation based on Direct Code Emulation (DCE)
1. Both sender and receiver are running MPTCP v0.89
2. B1 interface suffers packet losses due to interference from 2-
5s
RAMPTCP configuration:
→ Sender is aware of receiver channel utilization, SNR, path loss
%
MPTCP
TCP
Flow 1
A1
A2
Core
Network
B2
B1
TCP
Flow 1
TCP
Flow 2
TCP
Flow 2
MPTCP
11

19. Preliminary Evaluation
RAMPTCP achieves:
1. ≈19% increase in application goodput
2. ≈ 58% reductions in retrasmissions
0
5
10
15
Throughput(Mbps)
0 1 2 3 4 5 6 7 8 9 10
Time (secs)
0
5
10
15
Flow 1
Flow 2
MPTCP
RAMPTCP
12