1. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 A TCP Friendly Traffic Marker for IP Differentiated Services Feroz Azeem, Shiv Kalyanaraman, Amit Rao Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu http://www.ecse.rpi.edu/Homepages/shivkuma

2. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 q TCP performance over Differentiated Services q What are “TCP-friendly” building blocks ? q TCP-friendly traffic conditioners q Sample performance results Overview

3. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 Diff-serv Model q Congestion = traffic jams of the Internet q Congestion control (CC) requires end-system support q Traffic management = providing bandwidth services q TM requires some support from all network components q Problem: providing better-than-best-effort services for TCP q Lies at the intersection of the TM and CC problems Ingress Edge Router Egress Edge Router Interior Router End system End system

4. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4 TCP service performance q User metrics: q Average per-flow goodput q Coefficient of variation (spread) of per-flow goodput q Timeouts q Provider metrics: q Bottleneck Utilization q Queue length (avg/max) q Packet loss rate Parameters: a) Workload b) Configuration components and protocols System Metrics: a) User metrics b) Provider Metrics

5. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 TCP performance issues q User-perceived performance can be bad even if provider- perceived performance is good. q Key problem: second-order effects of packet-loss q Per-connection burst loss of packets is bad for TCP Reno q Even isolated loss of packets is bad for a TCP connection with a small window. Happens with: q high degrees of muxing or, q slower bottleneck rates or buffer sizes q Probability of burst loss high when a number of TCP connections in slow start phase (eg: WWW) q Hypothesis: problems can be alleviated by using “TCP- friendly” building blocks (possible violation of layering)

6. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 TCP-friendly building blocks q Goals: q Reduce probability of burst loss and TCP synchronization q Convert aggregate burst loss into per-connection isolated packet loss. Also minimize per-connection loss instances. q Protect small window connections from packet loss q Sample Methods: q Random early dropping: packet drop scheme like RED q Control TCP rate or dampen TCP rate increases: q Control left, right edges of TCP window (rcv_wnd and ack #) and/or rate of release of acks q Reduce TCP burstiness q Interleave packets of multiple flows q Protect small window flows from loss

7. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 TCP-friendly Marker q Problem: Allocate a limited aggregate pool of tokens among the active TCP flows to maximize performance as measured by user and provider best-effort metrics. q Method: q Estimate window sizes of flows W(i). q Assume: maximum token requirement for flow i = W(i) q First allocate and satisfy IN token requirements for all small-window flows, I.e., W(i) < 4. q Divide the remaining tokens in a max-min fair way among the rest of the flows. q Provide maximum equal spacing between packets marked OUT. q Carry over of tokens across intervals limited by policy

8. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8

9. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9 Configuration

10. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Sample Results q In all cases, the performance improvement is consistent, as measured by provider and user metrics. q Performance improvement is marked with higher speed links and larger number of flows. q Eg:With 100 flows, 150 Mbps bottleneck: q TCPFM: 1261 timeouts, 240 losses/s, 194kbps q TBM: 4254 timeouts, 311 losses/s, 134kbps q No marker:2954 timeouts, 322 losses/s, 151kbps q Validates Ibanez et al’s observations in the IETF (March 1999) about the unpredictability of TBM

11. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11 Sample Results (contd) q Results also extend to TCP SACK. q But the total number of timeouts in all cases is smaller. q Better-than-best-effort service: q The token and capacity over-provisioning required to provide assured service also reduces with the TCP-friendly marker q But the second-order effects of loss on TCP are not totally compensated for. q Later experimental work (submitted to ICNP’2000) also protects retransmissions which leads to order-of-magnitude performance gains, validating the approach.

12. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 Summary q TCP-friendly refers to components which promote better TCP performance, esp timeout and service-variance reduction. q A simple TCP-friendly marker which leverages the dimension of network-based packet marking in conjunction with the assured service. Effects: q Reduce user-perceived service variance (user benefit) q Reduce token provisioning requirements (provider benefit)