Achievable Service Differentiation with Token Bucket Marking for TCP

1. 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.

2. 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?

3. Talk Overview • Diffserv architecture • TCP model • Model validation • Performance results • Conclusion

4. Diffserv Architecture: Background End-host: - negotiates a profile with edge-router 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

5. marking r b scheduling . . . 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

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

7. Assured Forwarding at Core • Active queue management • Maintains average queue length, x • Compute • p1: drop prob. of a green pkt • p2: drop prob. of a red pkt 1 Drop prob Avg. queue length, x

8. TCP over AF Service Profile:A,B marker bottleneck core • 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 Other flows

9. 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

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

11. marked green Wa Wa tokens accumulate TCP Throughput: A simple deterministic model W(t) • define assured window size, Wa: Wa = 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 2W W • Under-subscribed case: p1=0, p2<1 • avg. number of red packets prior • to first loss: 1/p2 • equate • achieved rate, r = 3 W/ 2 T Time t

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

13. Simulation/Experiments To validate analytical model • Ns-2 simulation • testbed implementation • implemented various packet marking and multi-RED on Linux 2.2.10 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

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

16. Sample Experimental Results

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

18. Ideal Differentiation Not Possible Under-subscribed Case • consider two identical TCP flows (f1, f2) • 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, r1/r2 = A1/A2 • not possible with token parameter setting Profile-based marking favors flows with lower token-bucket rate A

19. 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 Bmax such that for B > Bmax, no additional gain in increasing B 0

20. 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 Under-subscribed Case Required assured rate A with B=20 pkt

21. 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