1 / 12

A TCP Friendly Traffic Marker for IP Differentiated Services

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 ?

Download Presentation

A TCP Friendly Traffic Marker for IP Differentiated Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. TCP performance over Differentiated Services • What are “TCP-friendly” building blocks ? • TCP-friendly traffic conditioners • Sample performance results Overview

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

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

  5. 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)

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

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

  8. Configuration

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

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

  11. 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)

More Related