internet protocols steven low cs/ee netlab.caltech.edu october 2004 with j. doyle, l. li, a. tang,...

35
Internet Protocols Steven Low CS/EE netlab.CALTECH.edu October 2004 with J. Doyle, L. Li, A. Tang, J. Wang

Upload: adrian-mellin

Post on 14-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

Internet Protocols

Steven Low

CS/EEnetlab.CALTECH.edu

October 2004

with J. Doyle, L. Li, A. Tang, J. Wang

Internet Protocols

Selects paths from sources to dests

TCP/AQM

IP

xi(t)

pl(t)

Selects source transmission rates

Link Selects topology, capacities, power,…

Application Selects user criteria, web layout, utility

Internet Protocols

TCP/AQM

IP

xi(t)

pl(t)

Link

Application Protocols determines network behavior Critical, yet difficult, to understand and

optimize Local algorithms, distributed spatially

and vertically global behavior Designed separately, deployed

asynchronously, evolves independently

Internet Protocols

TCP/AQM

IP

xi(t)

pl(t)

Link

Application Protocols determines network behavior Critical, yet difficult, to understand and

optimize Local algorithms, distributed spatially

and vertically global behavior Designed separately, deployed

asynchronously, evolves independently

Need to reverse engineer

… to forward engineer new large networks

Internet Protocols

TCP/AQM

IP

xi(t)

pl(t)

Link

Application Protocols determines network behavior Critical, yet difficult, to understand and

optimize Local algorithms, distributed spatially

and vertically global behavior Designed separately, deployed

asynchronously, evolves independently

Need to reverse engineer

… much easier than biologywith full specs

Internet Protocols

Minimize path costs (IP)

TCP/AQM

IP

xi(t)

pl(t)

Maximize utility (TCP/AQM)

Link Minimize SIR, max capacities, …

Application Minimize response time (web layout)

Internet Protocols Each layer is abstracted as an optimization

problem Operation of a layer is a distributed solution Results of one problem (layer) are parameters of

others Operate at different timescales

TCP/AQM

IP

Link

Application

cRx

xUi

iix

tosubj

)( max0

Application

IP Link

IP

TCP/AQM

Applications

Link

Chiang: X-ities??

Utility maximization

Utility maximization

Chiang: Wireless issues ??

Outline

General Approach:

1) Understand a single layer in isolation and assumeother layers are designed nearly optimally.

2) Understand interactions across layers

3) Incorporate additional layers, with the ultimate goal of viewing entire protocol stack as solving one giant optimization problem (where individual layers are solving parts of it).

IP

TCP/AQM

Applications

Link

Outline

Utility maximization

Some implications

Network model

F1

FN

G1

GL

R

RT

TCP Network AQM

x y

q p

))( ),(( )1(

))( ),(( )1(

tRxtpGtp

txtpRFtx T

Reno, Vegas

DT, RED, …

liRli link uses source if 1 IP routing

Network model - example

))( ),(( )1(

))( ),(( )1(

tRxtpGtp

txtpRFtx T

Reno, Vegas

DT, RED, …

liRli link uses source if 1 IP routing

ililill

llli

i

ii

tptxRGtp

tpRx

Ttx

)(),()1(

)(2

1)1(

2

2

TCP Reno: currently deployed TCP

AI

MD

TailDrop

Network model - example

))( ),(( )1(

))( ),(( )1(

tRxtpGtp

txtpRFtx T

Reno, Vegas

DT, RED, …

liRli link uses source if 1 IP routing

ilili

lll

llliii

i

iii

ctxRc

tptp

tpRtxT

txtx

)(1

)()1(

)()()()1( TCP FAST: high speed version of Vegas

Duality model Flow control problem (Kelly, Malloo, Tan 98)

TCP/AQM Maximize utility (& solve Dual) with different utility

functions (L 03): (x*,p*) primal-dual optimal iff

Primal-dual algorithm

Reno, Vegas, FAST

DT, RED, REM/PI, AVQ

Duality modelHistorically Packet level implemented first Flow level understood as after-thought But flow level design determines

performance, fairness, stability

Vegas, FAST, STCP HSTCP (homogeneous

sources) Reno (homogeneous

sources) infinity XCP (single link

only)

(Mo & Walrand 00)

Duality modelHistorically Packet level implemented first Flow level understood as after-thought But flow level design determines

performance, fairness, stability

Now: can forward engineerGiven (application) utility functions, cangenerate provably scalable TCP algorithms

Protocol decomposition

TCP-AQM: TCP algorithms maximize utility with different

utility functions

Congestion prices coordinate across protocol layers

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQM

IP

TCP/AQM

Applications

Link

Protocol decomposition

TCP-AQMIP

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQM

IP

TCP/AQM

Applications

Link

TCP/IP: TCP algorithms maximize utility with different

utility functions Shortest-path routing is optimal using congestion

prices as link costs

Congestion prices coordinate across protocol layers

Protocol decomposition

TCP-AQMIP

TCP/IP (with fixed c): Equilibrium of TCP/IP exists iff zero duality gap NP-hard, but subclass with zero duality gap is LP Equilibrium, if exists, can be unstable Can stabilize, but with reduced utility

Inevitable tradeoff bw utility max & routing stability

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQM

IP

TCP/AQM

Applications

Link

Protocol decomposition

IPLink

TCP/IP with optimal c: With optimal provisioning, static routing is optimal

using provisioning cost as link costs

TCP/IP with static routing in well-designed network

TCP-AQMIP

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQM

IP

TCP/AQM

Applications

Link

IP

TCP/AQM

Applications

Link

Outline

Utility maximization

Some implications

Implications

Is fair allocation always inefficient ?

Does raising capacity always increase throughput ?

Intricate and surprising interactions in large-scalenetworks … unlike at single link

Implications

Is fair allocation always inefficient

Does raising capacity always increase throughput

Fairness

Identify allocation with An allocation is fairer if its is

larger

(Mo, Walrand 00)

Fairness

maximum throughput proportional fairness min delay fairness

(Reno) infinity maxmin

fairness

(Mo, Walrand 00)

Efficiency

Unique optimal rate x() An allocation is efficient if T() is

large

Conjecture

Conjecture T() is nonincreasing

i.e. a fair allocation is always inefficient

Example 1

Conjecture T() is nonincreasing

i.e. a fair allocation is always inefficient

0

max throughput

1

1/(L+1)

proportionalfairness

L/L(L+1)

1/2

maxminfairness

1/2

Intuition

“The fundamental conflict between achieving flow fairness and maximizing overall system throughput….. The basic issue is thus the trade-off between these two conflicting criteria.”

Luo,etc.(2003), ACM MONET

Results

Theorem: Necessary & sufficient condition for general networks (R, c) provided every link has a 1-link flow

Corollary 1: true if N(R)=1

Counter-example There exists a network such that

dT/d > 0 for almost all >0 Intuition

Large favors expensive flows Long flows may not be expensive

Max-min may be more efficient than proportional fairness

expensive long

Counter-example

Theorem: Given any 0>0, there exists network where

Compact example

0

Implications

Is fair allocation always inefficient ?

Does raising capacity always increase throughput ?

Intricate and surprising interactions in large-scalenetworks … unlike at single link

Throughput & capacity

Intuition: Increasing link capacities always raises throughput T

Theorem: Necessary & sufficient condition for general networks (R, c)

Corollary: For all , increasing a link’s capacity can reduce T all links’ capacities equally can reduce T all links’ capacities proportionally raises T

Protocol decomposition

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQMIPLink

TCP algorithms maximize utility with different utility functions

IP shortest path routing is optimal using congestion prices as link costs, with given link capacities c

With optimal provisioning, static routing is optimal using provisioning cost as link costs

Congestion prices coordinate across protocol layers

Some implications

BccRx

xU

T

iii

xRc

, subject to

)( maxmax max0

TCP-AQM

TCP/AQM: TCP maximizes aggregate utility (not throughput) Fair bandwidth allocation is not always inefficient Increasing capacity does not always raise

throughputIntricate network interactions paradoxical behavior