Understanding TCP Dynamics in an Integrated Services Internet

Understanding TCP Dynamics in an Integrated Services Internet Wu-chang Feng, Dilip Kandlur, Debanjan Saha, and Kang Shin NOSSDAV '97

Motivation • Many TCP-based applications can take advantage of guarantees in the network • Majority of these applications don’t require strict delay bound guarantees • Examples – Non-interactive audio and video – Data streaming applications – Elastic applications (ftp, http) NOSSDAV '97

Controlled-load Service • IETF defined service which provides more flexible guarantees to applications than Guaranteed Service • Application provides TSpec • Compliant traffic receives service similar to that in an “unloaded” network • Non-compliant traffic is treated as besteffort NOSSDAV '97

Question Can TCP-based applications take advantage of a network which provides controlled-load service? NOSSDAV '97

System Model • Source – Compliance check done at the source using a token bucket filter derived from TSpec – Compliant packets sent marked – Non-compliant packets sent unmarked • Network – Enhanced Random Early Detection (ERED) NOSSDAV '97

Source Model Sending source TCP Send Compliance Check Network NOSSDAV '97

Network support • RED queues – Random early packet dropping for congestion avoidance – Keep queue lengths small – Avoid synchronization – Remove biases against bursty traffic NOSSDAV '97

Enhanced RED queues (ERED) • Same as RED, but marked packets have a much lower drop probability than unmarked packets – Single queue implementation – Retains FIFO ordering – Does not require per-flow information in the data forwarding path NOSSDAV '97

Example scenario S D • Reserved connections should get reserved rate and a share of the excess bandwidth • 3 sources with 1 Mbs, 2 Mbs and 4 Mbs policed with token buckets of depth 50 ms • 3 best-effort sources • 80 KB ERED queues at each router • Simulated using ns-1. 1 NOSSDAV '97

TCP with reservations NOSSDAV '97

Problem • TCP uses acknowledgement based triggers to send data • Well-known problem of ACK compression which can cause gaps in ACK stream • Transmission credits build up in token bucket as TCP waits for an ACK • Credits overflow and are lost NOSSDAV '97

TCP losing tokens S D NOSSDAV '97

TCP timer modification After every acknowledgement if (room under cwnd awnd) if (tokens available > packet size) send packet marked else send packet unmarked After every timer expiry reset timer if (room under awnd) if (tokens available > packet size) send packet marked NOSSDAV '97

TCP timer modification NOSSDAV '97

TCP timer modification NOSSDAV '97

Rate-adaptive windowing Normal Windowing Window Size Time Rate Adaptive Windowing Window Size Time NOSSDAV '97

TCP windowing modification After every new acknowledgement if (cwnd < ssthresh) cwnd = cwnd + (cwnd-rwnd)/cwnd else cwnd = cwnd + 1/cwnd Upon detection of loss from DUPACKs cwnd = rwnd + (cwnd-rwnd)/2 + ndup ssthresh = rwnd + (cwnd-rwnd)/2 Upon RTO cwnd = rwnd + 1 ssthresh = rwnd + (cwnd-rwnd)/2 NOSSDAV '97

TCP w/ timer and window mods NOSSDAV '97

Additional Experiments • Performance when a subset or when no network routers support service differentiation • Integration into a more elaborate packet scheduling and/or link scheduling experiments • Influence on pricing • Reservations vs. adaptation NOSSDAV '97

Summary • TCP’s ack-clocking and windowing algorithm limit its performance in an integrated services environment • Fine-grained timer and rate-adaptive windowing can solve this problem • Extended version and simulation results at http: //www. eecs. umich. edu/~wuchang/ered/ • TCP Brooklyn? (We don’t play chess all day) NOSSDAV '97