Post on 04-Apr-2020
Collaborators • MIT: Jason Cloud, Flavio du Pin Calmon, Ulric Ferner,
Michael Kilian, Minji Kim, Asuman Ozdaglar, Ali ParandehGheibi, Devavrat Shah, Danail Traskov (previously TUM, now Bain), Leo Urbina, Luis Voloch, Weifei Zeng
• Harvard: Michael Mitzenmacher • Qualcomm: Jay-Kumar Sundararajan (previously MIT) • University of Porto: Joao Barros • Google: Szymon Jakubczak (previously MIT) • Alcatel-Lucent: Emina Soljanin • Texas A&M: Srinivas Shakkottai • TUM: Michael Heindlmaier, Ashutosh Kulkarni
Network Coding and Reliable Communications Group 1
Outline TCP for smooth traffic
• Coded TCP (CTCP) • Proxying
Heterogeneous links • Optimization • Management - MPCTCP
Managing the CDN
Conclusions
Network Coding and Reliable Communications Group 2
TCP TCP/NC sender window
sender window
p1 p2 p3 p4 p1 p2 p3 p4 p1 p2 p3
ACK(p1)
ACK(p1)
p2 p3 p4 p5 p5 ACK(p1)
• Can’t increment window by 1 • Partial sliding window
Σp SEEN(1)
SEEN(2)
p4 p5 p6 p7 SEEN(4) SEEN(5) SEEN(6)
Σp Σp
Σp Σp Σp
Prevents random losses being interpreted as congestion!
Triple-duplicate ACKs!
p2 p3
p4
Window closing: W ← W/2
Σp SEEN(3) ACK(p1)
p7 p8 p9 p10 p11
There is a lag in the “SEEN” acks: To avoid lag, introduce redundancy!
SEEN(7) Σp
p8 p9 p10 p11 p12
3
Random Losses
Network Coding and Reliable Communications Group
TCP TCP/NC sender window
sender window
p1 p2 p3 p4 p1 p2 p3 p4 p1 p2 p3
ACK(p1)
p2 p3 p4 p5
Σp SEEN(1) Σp
Σp
Still allows congestion control while masking random losses!
Time-out! p2
p4
Window closing: W ← 1
Σp
p2 p3 p4 p5
Time-out! p2
Window closing: W ← 1
Waiting… Waiting…
4
Congestion Losses
Network Coding and Reliable Communications Group
• Coding layer buffers packets given by TCP • For every packet coming from TCP, coding layer transmits r (>1) random
linear combinations of buffered packets to IP
• Acknowledgment: ACK a packet upon seeing it (even before it is decoded) • Can do this at intermediate nodes as well in a daisy chain (tandem) network
[Sundararajan et al. 09]
Redundancy factor
5
Interpreting Feedback from TCP
Network Coding and Reliable Communications Group
Sample Packet Structure
Proxy for Coded TCP • TCP is end-‐to-‐end, and o/en requires changes at the source (and
some8mes even within the network)
• If a source is not setup/changed, the informa8on not accessible
• Using proxies can avoid the problem
• Does not require the source to support CTCP
• TCP: unchanged source ↔ CTCP proxy CTCP: CTCP proxy ↔ client
• Successfully tested in accessing Youtube video, websites (e.g. CNN, BBC, etc.) without changing their servers via a proxy in Amazon EC2
unchanged source
CTCP proxy client
Network Coding and Reliable Communications Group
Experimental Results: Single Path • Server: Amazon EC2 instance in CA
• Client: Desktop at RLE MIT, using WiFi(s)
wlan0
Example: 2% loss
Loss rate 0% 1% 2% 3% 4% 5%
TCP (Mbps) 19.04 3.07 1.07 0.82 0.53 0.47
CTCP (Mbps) 20.40 18.99 16.52 15.20 13.46 13.53
> 100 ms
Network Coding and Reliable Communications Group
Streaming through Multiple Interfaces
IP flow 1 IP flow 2
Application layer
IP flow 1 IP flow 2
Application layer
Server Client
Lte NIC WiFI NIC
Block i Block i
Divide & Schedule Combine
Media player
p1 p2 p3 … pw p1 p2 p3 … pw p1 p2 p3 … pw
Block 1 Block 2 Block 3 … …
Request block i
Media file:
p1 p3
p5
p2 p4
p6
Network Coding and Reliable Communications Group
Streaming through Multiple Interfaces
IP flow 1 IP flow 2
Application layer
IP flow 1 IP flow 2
Application layer
Server Client
Lte NIC WiFI NIC
Block i Block i
(Network) Encoder (Network) Decoder
Media player
p1 p2 p3 … pw p1 p2 p3 … pw p1 p2 p3 … pw
Block 1 Block 2 Block 3 … …
Request block i
Media file:
p1+p4
p2+p3
p1+p5
p2+p4
p3+p6
p4+p5
Network Coding and Reliable Communications Group
System Model • Initially buffer D packets, then start the playback • Objective: Find control policy to minimize usage cost, while
meeting QoE requirement [ParandehGheibi et al. 11]
• Off-line policy (Queue-length not observable) • Use the costly server only for a certain time starting from zero
• Online policies (Queue-length observable) 1. Safe policy:
• Start using free server • Once hit a threshold, switch to costly
2. Risky policy: • Use the costly when queue-length below a threshold
Free Server
Costly Server
Receiver
Performance Comparison • Three regimes for QoE metrics
1. Zero-cost 2. Infeasible (infinite cost) 3. Finite-cost
zero-cost
infeasible
Finite-cost
Simulation Set-up - OPNET • Use 802.11 and LTE connections with NC TCP over OPNET • Use risky policy • Parameters:
• Playout rate: 64kbps • Initial Playout delay=0 • Threshold Buffer Size=8000 bytes • WiFi link has 10% packet losses. • FTP 500kBytes file transferred.
• Results: • If only WiFi link is used, download time = 19.546 seconds, • only LTE link requires 7.855 seconds • Heterogeneous Access needs 9 seconds. LTE connection is used only
for last few packets with optimized cost.
[Kulkarni et al. 2011]
• MPTCP may poten8ally provide mul8-‐path communica8on
• Difficult and complex scheduling at the source needed
• Or, inefficient round-‐robin scheduling
• Longer paths leads to higher losses; resul8ng in poor performance
p1 p2 p3 p4
The effective success rate for routing is (1-p1)(1-p2)(1-p3)(1-p4)!
Note: TCP’s performance degrades super-linearly with end-to-end loss rate
Problems with Multipath using Routing
Network Coding and Reliable Communications Group
Coded TCP: Multipath using Coding • CTCP provides mul8-‐path communica8on without complex scheduling at
the source
• Achieves cumula8ve bandwidth of all paths
• Longer paths may lead to higher end-‐to-‐end losses; however, coding may be used to improve performance
p1 p2 p3 p4
The effective success rate for coding is 1-max(p1,p2,p3,p4)!
Network Coding and Reliable Communications Group
Experimental Results: Multiple Path • Server: Amazon EC2 instance in CA
• Client: Desktop at RLE MIT, using WiFi(s)
• Limited each path to < 8-‐9 Mbps
wlan0
Loss rate 0% 1% 2% 3% 4% 5%
wlan0 (Mbps) 7.13 6.08 6.43 6.25 5.16 5.08
wlan1 (Mbps) 7.11 5.92 6.53 5.90 5.01 4.58
CTCP (Mbps) 14.23 12.03 13.08 11.88 10.10 9.34
wlan1
> 100 ms
Example: 0% loss
Combined throughput at Client Throughput on wlan0
Network Coding and Reliable Communications Group
Motivation • What do we need? • Multiple TCP links managed in one session (Multiple TCP support) • Efficient management of TCP window size and congestion control
• Masks random fading events over wireless networks • What do we have?
TCP CTCP MPTCP ??? Multiple TCP Support No Managed
as one Yes Yes
Efficient Window Management
No Yes No Yes
How?
Network Coding and Reliable Communications Group
MPTCP/NC Overview
All received packets are ACK’ed
All packets within the MPTCP/NC coding window are coded together and pushed to different sub-flows
Each packet from TCP generates R linearly independent coded packets where each packet is generated from the set of packets within the TCP window
Application
MPTCP/NC
TCP TCP Fast-
TCP/NC Fast-
TCP/NC
IP IP
NETWORK
Network Interface
Network Interface
Application
MPTCP/NC
TCP TCP Fast-TCP/
NC Fast-TCP/
NC
IP IP Network Interface
Network Interface
MPTCP/NC layer ACKs all new degrees of freedom received
Decoding only occurs at the MPTCP/NC layer
Each received packet is immediately forwarded to the TCP layer
Network Coding and Reliable Communications Group
Case 1 XX
Network Coding and Reliable Communications Group
Case 2 XX
Network Coding and Reliable Communications Group
Case 3 X
X
Network Coding and Reliable Communications Group
SANs are used in a Variety of Content Distribution Systems
22
• Facebook has 100 billion hits/day • 130TB of logs per day
• Google uses flushing toilets to cool DCs • Cannot simply endlessly provision
>
Energy Model
23
[Valancius et al. 09]
Blocking Probability - Key Performance Metric • SAN contains file , divided into chunks • File is blocked if there exists at least one chunk that is
in a blocked state. Chunk is available if there exists a drive that contains it and has an available I/O access-bandwidth slot
24
M/G/K/K Queue Network
25
NCS M/G/K/K Network
26
NCS Improvements Depend on Striping
27
No. copies
Blocking probability
NCS is Different from Amalgamation
28
No. copies
Blocking probability
NCS Deployment is Feasible
29
CDN Management
Amazon Web Services Interface
Amazon Web Services
Physical Servers and Drives
NCS Software
Redirection and content location management Proxy management Lighttpd HTTP server
Encoding CDN Management Interception Decoding
Conclusions • Network coding can help video distribution
• Providing high throughput smooth service • Coding both for variability within a channel and variability
across channels • Allowing opportunistic use of different streams to avert avert
interruptions • Managing blocking probability and energy use jointly.
• Different approaches to using coding for smoothing service and meeting requirements can be blended together in different parts of CDNs and
Network Coding and Reliable Communications Group 30