Collaborators - Massachusetts Institute of Technologyilp.mit.edu/images/conferences/2012/RD/presentation/...•Coding layer buffers packets given by TCP • For every packet coming

Collaborators • MIT: Jason Cloud, Flavio du Pin Calmon, Szymon

Jakubczak (now Google), Minji Kim (now Akamai), Marie-Jose Montpetit, Asuman Ozdaglar, Ali ParandehGheibi,, Devavrat Shah, Jay-Kumar Sundararajan (now Qualcomm) Danail Traskov (previously TUM, now Bain), Leo Urbina, Weifei Zeng

• Harvard: Michael Mitzenmacher • National University of Ireland Maynooth: Doug Leith • University of Porto: Joao Barros •  Texas A&M: Srinivas Shakkottai •  TUM: Michael Heindlmaier, Ashutosh Kulkarni

Network Coding and Reliable Communications Group 1

Sponsors


AFOSR DARPA NSF ARO Semiconductor Research Council (IFC)

Outline TCP for smooth traffic

•  Coded TCP (CTCP) •  Proxying •  Management - MPCTCP

Coding for probability of interruption Conclusions


What is QoE •  The notion of QoE is highly dependent on application-

specific user experience expectations: •  QoE as a probability of interruption of video: coding can be used to

reduce the probability of interruption, with a behavior akin to error exponents

•  High, reliable rate under wireless losses: network coding can avoid interruptions in TCP/IP, by coding over temporary network effects and over multiple networks


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

5

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…

6

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

7

Interpreting Feedback from TCP


TCP using Network Coding

•  MPTCP may poten.ally provide mul.-‐path communica.on •  Difficult and complex scheduling at the source needed

•  Or, inefficient round-‐robin scheduling

•  Longer paths leads to higher losses; resul.ng 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 mul.-‐path communica.on without complex scheduling at

the source •  Achieves cumula.ve bandwidth of all paths

•  Longer paths may lead to higher end-‐to-‐end losses; however, coding may be used to improve performance

p6 p7 p8 p9

The effective success rate for coding is 3-(max(p1,p2,p3,p4,5)+max(p6,p7,p8,p9)+max(p10,p11,p12,13))!


p1

p2 p3 p4

p5

p10 p11

p12

p13

1 2 4 3 FTP

sender

From given data

FTP receiver

Simulation Set-up

TCP End-to-end coding Re-encoding at node 3 only 0.0042 Mbps 0.1420 Mbps 0.2448 Mbps

(assuming each link has a bandwidth of 1 Mbps in the absence of erasures)

Time average throughput (over 641 seconds)

Performance Comparison

Proxy for Coded TCP •  TCP is end-‐to-‐end, and oLen requires changes at the source (and

some.mes even within the network) •  If a source is not setup/changed, the informa.on 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


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



Testbed Measurements

Hamilton Institute

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?


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



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



Request block i

Media file:

p1+p4

p2+p3

p1+p5

p2+p4

p3+p6

p4+p5


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


Numerical Results •  Three MPTCP schemes were considered: 1.  Uncoded MPTCP with dynamic allocation of packets for each

link 2.  MPTCP/NC with for each link 3.  MPTCP/NC with for each link •  Values used for round trip time and packet loss:

R = (1− p)−1

R = 1.05(1− p)−1

10−3

10−2

10−1

0.3

15 80 250 1500Lossless

Noisy

Low Delay High Delay

p

RTT

WLAN

Sat WIMAX/

LTE

(ms)


log10(File Size)

Ave

rage

com

plet

ion

time

(ms)

Link 1: RTT =1500ms p = 10−3 Link 2: RTT =80ms p = 10−2

3 4 5 6102

103

104

105

106

107

108

UncodedCoded, R=(1−p)−1

Coded, R=1.05(1−p)−1

log(File Size)

Ave

rage

Rat

e (p

acke

t/s)


3 4 5 60

200

400

600

800

1000

1200

1400UncodedCoded, R=(1−p)−1

Coded, R=1.05(1−p)−1

Case 1

Time (s)

Join

t win

dow

wiz

e (p

acke

ts)

Link 1: RTT=1500ms, p = 10−2 Link 2: RTT=80ms, p = 10−1

0 10 20 30 40 50 60 700

50

100

150

200

250Coded, R=(1−p)−1

Coded, R=1.05(1−p)−1

Uncoded

Jointwindow

size

(packets)

RTT

10−3

10−2

10−1

0.3

15 80 250 1500

p XX


log10(File Size)

Ave

rage

com

plet

ion

time

(ms)


3 4 5 6102

103

104

105

106

107

108


Coded, R=1.05(1−p)−1

log(File Size)

Ave

rage

Rat

e (p

acke

t/s)


3 4 5 60

200

400

600

800

1000

1200

1400

1600

1800


Coded, R=1.05(1−p)−1

Case 2

Time (s)

Join

t win

dow

wiz

e (p

acke

ts)

0 10 20 30 40 50 600

50

100

150

200

250

300 Coded, R=(1−p)−1

Coded, R=1.05(1−p)−1

Uncoded

Jointwindow

size

(packets)

RTT

10−3

10−2

10−1

0.3

15 80 250 1500

pXX


log(File Size)

Ave

rage

Rat

e (p

acke

t/s)


3 4 5 60

500

1000

1500

2000

2500

3000

3500

4000

4500


Coded, R=1.05(1−p)−1

log10(File Size)

Ave

rage

com

plet

ion

time

(ms)


3 4 5 6102

103

104

105

106

107

108


Coded, R=1.05(1−p)−1

Case 3

Time (s)

Join

t win

dow

wiz

e (p

acke

ts)

Link 1: RTT=1500ms, p = 10−3 Link 2: RTT=15ms, p = 0.3

0 5 10 15 200

20

40

60

80

100

120

140

160

180

200Coded, R=(1−p)−1

Coded, R=1.05(1−p)−1

Uncoded

Jointwindow

size

(packets)

RTT

10−3

10−2

10−1

0.3

15 80 250 1500

p

X

X


Outline TCP for smooth traffic

•  Coded TCP (CTCP) •  Proxying •  Management - MPCTCP

Coding for probability of interruption Conclusions



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



Request block i

Media file:

p1 p3

p5

p2 p4

p6



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



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]

Conclusions •  Network coding can help QoE and 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

interruptions

• Different approaches to using coding for smoothing service and meeting requirements can be blended together in different parts


Documents

Collaborators - Massachusetts Institute of Technologyilp.mit.edu/images/conferences/2012/RD/presentation/...•Coding layer buffers packets given by TCP • For every packet coming