120 likes | 226 Views
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. TCP performance over Differentiated Services What are “TCP-friendly” building blocks ?
E N D
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
TCP performance over Differentiated Services • What are “TCP-friendly” building blocks ? • TCP-friendly traffic conditioners • Sample performance results Overview
Diff-serv Model End system • Congestion = traffic jams of the Internet • Congestion control (CC) requires end-system support • Traffic management = providing bandwidth services • TM requires some support from all network components • Problem: providing better-than-best-effort services for TCP • Lies at the intersection of the TM and CC problems End system Interior Router Egress Edge Router Ingress Edge Router
TCP service performance Metrics: a) User metrics b) Provider Metrics Parameters: a) Workload b) Configuration components and protocols • User metrics: • Average per-flow goodput • Coefficient of variation (spread) of per-flow goodput • Timeouts • Provider metrics: • Bottleneck Utilization • Queue length (avg/max) • Packet loss rate System
TCP performance issues • User-perceived performance can be bad even if provider-perceived performance is good. • Key problem:second-order effects of packet-loss • Per-connection burst loss of packets is bad for TCP Reno • Even isolated loss of packets is bad for a TCP connection with a small window. Happens with: • high degrees of muxing or, • slower bottleneck rates or buffer sizes • Probability of burst loss highwhen a number of TCP connectionsin slow start phase (eg: WWW) • Hypothesis: problems can be alleviated by using “TCP-friendly” building blocks (possible violation of layering)
TCP-friendly building blocks • Goals: • Reduce probability of burst loss and TCP synchronization • Convert aggregate burst loss into per-connection isolated packet loss. Also minimize per-connection loss instances. • Protect small window connections from packet loss • Sample Methods: • Random early dropping: packet drop scheme like RED • Control TCP rate or dampen TCP rate increases: • Control left, right edges of TCP window (rcv_wnd and ack #) and/or rate of release of acks • Reduce TCP burstiness • Interleave packets of multiple flows • Protect small window flows from loss
TCP-friendly Marker • 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. • Method: • Estimate window sizes of flows W(i). • Assume: maximum token requirement for flow i = W(i) • First allocate and satisfy IN token requirements for all small-window flows, I.e., W(i) < 4. • Divide the remaining tokens in a max-min fair way among the rest of the flows. • Provide maximum equal spacing between packets marked OUT. • Carry over of tokens across intervals limited by policy
Sample Results • In all cases, the performance improvement is consistent, as measured by provider and user metrics. • Performance improvement is marked with higher speed links and larger number of flows. • Eg:With 100 flows, 150 Mbps bottleneck: • TCPFM: 1261 timeouts, 240 losses/s, 194kbps • TBM: 4254 timeouts, 311 losses/s, 134kbps • No marker:2954 timeouts, 322 losses/s, 151kbps • Validates Ibanez et al’s observations in the IETF (March 1999) about the unpredictability of TBM
Sample Results (contd) • Results also extend to TCP SACK. • But the total number of timeouts in all cases is smaller. • Better-than-best-effort service: • The token and capacity over-provisioning required to provide assured service also reduces with the TCP-friendly marker • But the second-order effects of loss on TCP are not totally compensated for. • Later experimental work (submitted to ICNP’2000) also protects retransmissions which leads to order-of-magnitude performance gains, validating the approach.
Summary • TCP-friendly refers tocomponents which promote better TCP performance, esp timeout and service-variance reduction. • A simple TCP-friendly marker which leverages the dimension of network-based packet marking in conjunction with the assured service. Effects: • Reduce user-perceived service variance (user benefit) • Reduce token provisioning requirements (provider benefit)