NOSSDAV '97 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 best- effort

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 Reserved connections should get reserved rate and a share of the excess bandwidth 3 sources with 1Mbs, 2Mbs and 4Mbs policed with token buckets of depth 50ms 3 best-effort sources 80KB ERED queues at each router Simulated using ns-1.1 SD

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 DS

NOSSDAV '97 TCP timer modification After every acknowledgement if (room under cwnd and awnd ) if (tokens available > packet size) send packet marked elsesend 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 Rate Adaptive Windowing Window Size Time Window Size

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 TCP w/ timer and window mods

NOSSDAV '97 Timer overheads

NOSSDAV '97 Timer intervals

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 TCP Brooklyn? (We don’t play chess all day)