Network Protocols: Design and Analysis Polly Huang EE NTU

TCP Flows [Padhye98a] [Floyd99b]

[Padhye98a]

Polly Huang, NTU EE4 Key ideas define typical throughput for TCP flow in terms of loss rates, RTT, etc. why bother? –might define what’s “fair”: TCP friendliness –insight into what to expect from TCP first paper to consider some new things about TCP… (see next)

Polly Huang, NTU EE5 Context Series of increasingly complete models of TCP steady state performance –Floyd, 1991 –Mathis et al, 1997 –new contribution: considers TDP and timeouts Parallel line of research: modeling short connections: –Heidemann, Obrazcka, Touch 1997 –Cardwell, Savage, Anderson 1998 [Mathis97a, eqn 3]

Polly Huang, NTU EE6 Basic Approach model TCP in rounds –consider congestion avoidance (ignore slow- start) –each round is a flight of packets until their ACKs –model window size W model TDP: series of rounds followed by a drop and a Triple-Dup-ACK make assumptions where necessary –losses are i.i.d., but at end of round all pkts are lost solve for mean values using probability

Polly Huang, NTU EE7 Basic Approach, pictorially solve bandwidth via solving Y and A Y: number of segs sent in TDP A: duration of TDP in seconds A Y Y: A: round 1 round b … ()

Polly Huang, NTU EE8 Result for Triple-Dup-ACKs [Mathis97a, eqn 3] conclusion for triple-dup-ACK steady state (in segments): compare to Mathis et al’s earlier result (in bytes): [Padhye98a, eqn 20]

Polly Huang, NTU EE9 What About Timeouts? Z TO add Z TO to estimate timeouts

Polly Huang, NTU EE10 Modeling a Limited Window Define W max as the window limit What is performance if window limited? –data sent per round: W max –rounds until TDP: E[X] –so data sent in TDP = E[Y] = Wmax * E[X] / RTT

Polly Huang, NTU EE11 Back to B(p) with timeouts: with timeouts and limited windows: [Padhye98a, eqn 29] [Padhye98a, eqn 32]

Polly Huang, NTU EE12 Validation Ok, nice math, but does it really work? Validation approach: –set up bulk transfers –compare measured data vs. analysis with and without timeouts

Polly Huang, NTU EE13 Validation [Padhye98a, figs 7 & 9] (window limited)(non-window limited)

Polly Huang, NTU EE14 Insights and Results Users of this stuff –TCP friendly work –analytic-augmented simulation insights into TCP –timeouts are very frequent –why? get many burst error, TCP doesn’t recover very well from multiple loss in single RTT

Polly Huang, NTU EE15 Other observations xxx

[Floyd99b]

Polly Huang, NTU EE17 Key ideas xxx

Polly Huang, NTU EE18 Problem: Congestion Collapse [Floyd99b, figs 2&3] What was congestion collapse in [Jacobson88a]?  retransmitting packets it thought were lost (but they weren’t) What is cng. collapse for F&F?  lots of undelivered packets in the network (xxx) aggregate goodput TCP UDP offered and accepted TCP UDP accepted UDP offered aggregate goodput

Polly Huang, NTU EE19 F&F Congestion Collapse classical collapse: TCP retransmissions collapse from undelivered packets: –open-loop apps dump traffic into net –don’t react to congestion signals –example apps: RealPlayer, VOIP, etc. (these could be congestion reactive, but they traditionally haven’t been) why not just use fair queueing –breaks down with many many flows

Polly Huang, NTU EE20 Other Examples of Collapse classic collapse (unnecessary pkt retx) collapse from undelivered packets fragmentation based collapse –ex. retransmission unit >> loss unit increased control traffic collapse from stale packets –ex. sending audio that misses deadline  common thread: fewer useful bytes of data

Polly Huang, NTU EE21 How to fix problematic flows? pricing (but that’s a big change) per-flow queueing –pros: good isolation –cons: requires a lot of router state (per-flow) => slower routers F&F’s suggestions: –1) flows should be TCP friendly –2) identify the ones that aren’t and “punish” them—the “penalty box” potentally this requires less state (only need state for high bandwidth flows)

Polly Huang, NTU EE22 E2E Approach everyone should react to congestion signals if they don’t, we should make them :-)

Polly Huang, NTU EE23 TCP Friendliness What is good: TCP-friendly given R (RTT) and B (packet size), routers can identify conforming and non- conforming flows –requirements: tx rate need to observe for “long time” (>> RTT) need to know RTT, pkt size, drop rate

Polly Huang, NTU EE24 Flows that must be regulated Unresponsive: –fail to reduce load in response to increased loss Not TCP friendly –long-term usage exceeds that of TCP under same conditions Using disproportionate bandwidth –use disproportionately more bandwidth than other flows during congestion Assumptions: –We can monitor a flow’s arrival rate

Polly Huang, NTU EE25 Identifying non-TCP Friendly Flows Not TCP friendly: –use TCP model –B: packet size in bytes, p: packet drop rate –Better approximation in Padhye et al. paper –Problems: Needs bounds on packet sizes and RTTs

Polly Huang, NTU EE26 Identifying Unresponsive and Disporportionate Flows Flows are unresponsive if drops don’t cause rate reduction –p up by 4 => T down by 2 (if responsive) Flows are disporportionate if they use more bandwidth than others –T > 12000/sqrt(p) and T > ln(3n)/n

Polly Huang, NTU EE27 Other questions/observations? policing flows requires per-flow state, so what have we gained? –perhaps a simpler queueing discipline –but still a problem