collaborators - robert w. heath jr.•coding layer buffers packets given by tcp • for every packet...

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


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


•  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


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


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


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


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


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


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)!


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


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?


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


Case 1 XX


Case 2 XX


Case 3 X

X


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


collaborators - robert w. heath jr.•coding layer buffers packets given by tcp • for every packet...

Documents