Achievable Service Differentiation with Token Bucket Marking for TCP S. Sahu, D.Towsley University of Massachusetts P. Nain INRIA C. Diot Sprint Labs V. Firoiu Bay Architecture Lab.

Problem Statement Assured forwarding (AF) for TCP –Is it possible to provide service differentiation across a set of TCP flows? –Is it feasible to provide minimum rate guarantee to a TCP flow? –How to set “parameters” to achieve a desired rate?

Talk Overview Diffserv architecture TCP model Model validation Performance results Conclusion

Diffserv Architecture: Background Edge router: - per-flow traffic management - marks packets as in-profile and out-profile Core router: - per class traffic management - buffering and scheduling based on marking at edge End-host: - negotiates a profile with edge-router

Diffserv Architecture Edge router: - per-flow traffic management - marks packets as in-profile and out-profile Core router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profile packets - Assured Forwarding scheduling... r b marking

Leaky-bucket Marking at Edge Profile: pre-negotiated rate A, bucket size B Packet marking at edge based on per-flow profile Rate A B User packets

Assured Forwarding at Core Active queue management –Maintains average queue length, x Compute –p 1 : drop prob. of a green pkt –p 2 : drop prob. of a red pkt 1 Avg. queue length, x Drop prob

TCP over AF Service Questions: –Is it possible to provide a TCP flow a fixed (minimum) rate through proper choice of parameters (A,B) –Is it possible to provide service differentiation across a set of TCP flows? Determine “achieved throughput” r Related work [Jain99, Nichols99, Yeom99] TCP bottleneck core marker Profile:A,B Other flows

Quick Review of TCP Window-based congestion control protocol Sender maintains window size W –limits data that can be sent (thus limits send rate) W adjusted: –increases window by one per round trip time T ( or 1/W per ACK), W <- W +1 (i.e., additive increase) –decreases window by half on detection of loss (triple duplicate loss), W <- W/2 (i.e., multiplicative decrease) –timeouts due to lack of ACKs -> window reduced to one, W <-1 Previous modeling focused on best-effort service

Our Approach: Simple Loss Model non-overlapping loss model –if p 2 < 1 p 1 = 0; under- subscribed case –if p 1 > 0 p 2 = 1; over- subscribed case derive –“achieved rate” for each case separately conjecture –overlapping loss model reduces to one or the other Drop probability Avg. queue length x 1 p2p2 p2p2 p1p1

TCP Throughput: A simple deterministic model define assured window size, W a : W a = A x T, where T is a constant round trip time W, avg. window size at the begin of a cycle 2W, avg. window size just prior to a loss event W(t) W 2W WaWa marked green Under-subscribed case: p 1 =0, p 2 <1 avg. number of red packets prior to first loss: 1/p 2 equate achieved rate, r = 3 W/ 2 T Time t tokens accumulate WaWa

TCP Throughput: A simple deterministic model Time t W 2W W(t) Over-subscribed case: p 1 >0, p 2 =1 Red packet loss: Green packet loss: avg. number of green packets prior to first loss: 1/p 1 equate Sending rate is WaWa tokens accumulate marked green

Simulation/Experiments Ns-2 simulation testbed implementation –implemented various packet marking and multi-RED on Linux kernel model validation –round-trip time 100~400ms –wide range of loss rates Bernoulli loss model buffer overflow –large number of TCP flows Sprint ATL Testbed Configuration To validate analytical model

Sample Validation Results Under-subscription caseOver-subscription case A = 100kb/s, B=20, T=100msA=1000kb/s, B=64, T=100ms

Sample Experimental Results

Infeasible/Invariant Rates Separation Curve: determine which rates possible to achieve/regulate via token bucket parameters Under-subscribed CaseOver-subscribed Case Not possible to regulate/achieve any arbitrary rate by solely setting token-bucket parameters Invariant Region Infeasible Region

Ideal Differentiation Not Possible Profile-based marking favors flows with lower token- bucket rate A consider two identical TCP flows (f 1, f 2 ) best-effort service –same achieved rate for both flows assured forwarding –ideally want to have achieved rate, r, proportional to assured rate A, i.e, r 1 /r 2 = A 1 /A 2 not possible with token parameter setting Under-subscribed Case

Choice of Token-bucket Parameters Tradeoffs in choice of rate A and bucket size B –can choose larger B for lower choice of A (vice versa), but... –bucket size results in at most 33% improvement in achieved rate What B to choose –there exists B max such that for B > B max, no additional gain in increasing B 0

Choice of Token-bucket Parameters What A to choose –determine if feasible to achieve the target rate –A is a function of loss rate, bucket size Required assured rate A with B=20 pkt Under-subscribed Case

Conclusion not easy to regulate/differentiate rates among a set of TCP flows –not all rates are feasible –flows with lower assured rate get more benefit guidelines for setting token-bucket parameters for achievable rates –maximum possible benefit using bucket limited to 33% –determined conditions for choosing A and B parameters