Upload
beatrice-fowler
View
218
Download
0
Embed Size (px)
DESCRIPTION
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
Citation preview
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
S D
NOSSDAV '97
TCP with reservations
00.5
11.5
22.5
33.5
44.5
Bandwidth (Mbs)
1 Mbs 2 Mbs 4 Mbs BEReservation Level
Total Bandwidth
IdealObserved
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 acknowledgementif (room under cwnd and awnd)
if (tokens available > packet size)send packet marked
else send packet unmarkedAfter every timer expiry
reset timerif (room under awnd)
if (tokens available > packet size)send packet marked
NOSSDAV '97
TCP timer modification
00.5
11.5
22.5
33.5
44.5
Bandwidth (Mbs)
1Mbs 2Mbs 4Mbs BEReservation Level
Total Bandwidth
IdealObserved
NOSSDAV '97
TCP timer modification
00.10.20.30.40.50.60.70.8
Bandwidth (Mbs)
1 Mbs 2 Mbs 4 Mbs BEReservation Level
Share of Residual Bandwidth
+TIdeal
NOSSDAV '97
Rate-adaptive windowingNormal Windowing
Rate Adaptive Windowing
WindowSize
Time
Time
WindowSize
NOSSDAV '97
TCP windowing modification
After every new acknowledgementif (cwnd < ssthresh)
cwnd = cwnd + (cwnd-rwnd)/cwndelse cwnd = cwnd + 1/cwnd
Upon detection of loss from DUPACKscwnd = rwnd + (cwnd-rwnd)/2 + ndupssthresh = rwnd + (cwnd-rwnd)/2
Upon RTOcwnd = rwnd + 1ssthresh = rwnd + (cwnd-rwnd)/2
NOSSDAV '97
TCP w/ timer and window mods
00.10.20.30.40.50.60.70.8
Bandwidth (Mbs)
1 Mbs 2 Mbs 4 Mbs BEReservation Level
Share of Residual Bandwidth
+T+T+WIdeal
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)