Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 A TCP Friendly Traffic Marker for IP Differentiated Services Feroz Azeem, Shiv Kalyanaraman,

Shivkumar KalyanaramanRensselaer Polytechnic Institute

1

A TCP Friendly Traffic Marker for IP Differentiated Services

Feroz Azeem, Shiv Kalyanaraman, Amit Rao

Rensselaer Polytechnic Institute

[email protected]

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

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

Ingress Edge

Router

Egress Edge Router

Interior Router

End system

End system


4

TCP service performance

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

Parameters: a) Workloadb) Configuration components and protocols

System

Metrics:a) User metricsb) Provider Metrics


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 high when a number of TCP connections in 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

O U T P acket

IN P acket

W ith Token B ucket M arker

W ith TC P -friend ly M arker

Illustration of the TC P-friendly M arking Schem e


9

Configuration1

5

2

.

.

.

Marker0

6

10

7

.

.

.

Marker1

R1 R2

1

5

2

.

.

.

6

10

7

.

.

.

S ourcesD estina tions

A ll L inks 1 .5 M bps, 1000 K m un less o therw isem entioned

10 M bps

10 M bps


10

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


11

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.


12

Summary

TCP-friendly refers to components 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)

Documents

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 A TCP Friendly Traffic Marker for IP Differentiated Services Feroz Azeem, Shiv Kalyanaraman,