One document matched: draft-ietf-tcpm-tcp-dcr-01.ps
%!PS-Adobe-3.0
%%Title: draft-ietf-tcpm-tcp-dcr-01.txt
%%For: Sumitha Bhandarkar
%%Creator: a2ps version 4.13
%%CreationDate: Wed Jul 14 12:23:33 2004
%%BoundingBox: 24 24 571 818
%%DocumentData: Clean7Bit
%%Orientation: Portrait
%%Pages: 16
%%PageOrder: Ascend
%%DocumentMedia: A4 595 842 0 () ()
%%DocumentNeededResources: font Courier
%%+ font Courier-Bold
%%+ font Courier-BoldOblique
%%+ font Courier-Oblique
%%+ font Helvetica
%%+ font Helvetica-Bold
%%+ font Symbol
%%+ font Times-Bold
%%+ font Times-Roman
%%DocumentProcessColors: Black
%%DocumentSuppliedResources: procset a2ps-a2ps-hdr
%%+ procset a2ps-black+white-Prolog
%%+ encoding ISO-8859-1Encoding
%%EndComments
/a2psdict 200 dict def
a2psdict begin
%%BeginProlog
%%Copyright: (c) 1988, 89, 90, 91, 92, 93 Miguel Santana
%%Copyright: (c) 1995, 96, 97, 98 Akim Demaille, Miguel Santana
% Check PostScript language level.
/languagelevel where {
pop /gs_languagelevel languagelevel def
} {
/gs_languagelevel 1 def
} ifelse
% EPSF import as in the Red Book
/BeginInclude {
/b4_Inc_state save def % Save state for cleanup
/dict_count countdictstack def % Count objects on dict stack
/op_count count 1 sub def % Count objects on operand stack
userdict begin
0 setgray 0 setlinecap
1 setlinewidth 0 setlinejoin
10 setmiterlimit [ ] 0 setdash newpath
gs_languagelevel 1 ne {
false setstrokeadjust false setoverprint
} if
} bind def
/EndInclude {
count op_count sub { pos } repeat % Clean up stacks
countdictstack dict_count sub { end } repeat
b4_Inc_state restore
} bind def
/BeginEPSF {
BeginInclude
/showpage { } def
} bind def
/EndEPSF {
EndInclude
} bind def
% Page prefeed
/page_prefeed { % bool -> -
statusdict /prefeed known {
statusdict exch /prefeed exch put
} {
pop
} ifelse
} bind def
/deffont {
findfont exch scalefont def
} bind def
/reencode_font {
findfont reencode 2 copy definefont pop def
} bind def
% Function c-show (str => -)
% centers text only according to x axis.
/c-show {
dup stringwidth pop
2 div neg 0 rmoveto
show
} bind def
% Function l-show (str => -)
% prints texts so that it ends at currentpoint
/l-show {
dup stringwidth pop neg
0
rmoveto show
} bind def
% center-fit show (str w => -)
% show centered, and scale currentfont so that the width is less than w
/cfshow {
exch dup stringwidth pop
% If the title is too big, try to make it smaller
3 2 roll 2 copy
gt
{ % if, i.e. too big
exch div
currentfont exch scalefont setfont
} { % ifelse
pop pop
}
ifelse
c-show % center title
} bind def
% Return the y size of the current font
% - => fontsize
/currentfontsize {
currentfont /FontMatrix get 3 get 1000 mul
} bind def
% reencode the font
% <encoding-vector> <fontdict> -> <newfontdict>
/reencode { %def
dup length 5 add dict begin
{ %forall
1 index /FID ne
{ def }{ pop pop } ifelse
} forall
/Encoding exch def
% Use the font's bounding box to determine the ascent, descent,
% and overall height; don't forget that these values have to be
% transformed using the font's matrix.
% We use `load' because sometimes BBox is executable, sometimes not.
% Since we need 4 numbers an not an array avoid BBox from being executed
/FontBBox load aload pop
FontMatrix transform /Ascent exch def pop
FontMatrix transform /Descent exch def pop
/FontHeight Ascent Descent sub def
% Define these in case they're not in the FontInfo (also, here
% they're easier to get to.
/UnderlinePosition 1 def
/UnderlineThickness 1 def
% Get the underline position and thickness if they're defined.
currentdict /FontInfo known {
FontInfo
dup /UnderlinePosition known {
dup /UnderlinePosition get
0 exch FontMatrix transform exch pop
/UnderlinePosition exch def
} if
dup /UnderlineThickness known {
/UnderlineThickness get
0 exch FontMatrix transform exch pop
/UnderlineThickness exch def
} if
} if
currentdict
end
} bind def
% Function print line number (<string> # -)
/# {
gsave
sx cw mul neg 2 div 0 rmoveto
f# setfont
c-show
grestore
} bind def
% -------- Some routines to enlight plain b/w printings ---------
% Underline
% width --
/dounderline {
currentpoint
gsave
moveto
0 currentfont /Descent get currentfontsize mul rmoveto
0 rlineto
stroke
grestore
} bind def
% Underline a string
% string --
/dounderlinestring {
stringwidth pop
dounderline
} bind def
/UL {
/ul exch store
} bind def
% Draw a box of WIDTH wrt current font
% width --
/dobox {
currentpoint
gsave
newpath
moveto
0 currentfont /Descent get currentfontsize mul rmoveto
dup 0 rlineto
0 currentfont /FontHeight get currentfontsize mul rlineto
neg 0 rlineto
closepath
stroke
grestore
} bind def
/BX {
/bx exch store
} bind def
% Box a string
% string --
/doboxstring {
stringwidth pop
dobox
} bind def
%
% ------------- Color routines ---------------
%
/FG /setrgbcolor load def
% Draw the background
% width --
/dobackground {
currentpoint
gsave
newpath
moveto
0 currentfont /Descent get currentfontsize mul rmoveto
dup 0 rlineto
0 currentfont /FontHeight get currentfontsize mul rlineto
neg 0 rlineto
closepath
bgcolor aload pop setrgbcolor
fill
grestore
} bind def
% Draw bg for a string
% string --
/dobackgroundstring {
stringwidth pop
dobackground
} bind def
/BG {
dup /bg exch store
{ mark 4 1 roll ] /bgcolor exch store } if
} bind def
/Show {
bg { dup dobackgroundstring } if
ul { dup dounderlinestring } if
bx { dup doboxstring } if
show
} bind def
% Function T(ab), jumps to the n-th tabulation in the current line
/T {
cw mul x0 add
bg { dup currentpoint pop sub dobackground } if
ul { dup currentpoint pop sub dounderline } if
bx { dup currentpoint pop sub dobox } if
y0 moveto
} bind def
% Function n: move to the next line
/n {
/y0 y0 bfs sub store
x0 y0 moveto
} bind def
% Function N: show and move to the next line
/N {
Show
/y0 y0 bfs sub store
x0 y0 moveto
} bind def
/S {
Show
} bind def
%%BeginResource: procset a2ps-a2ps-hdr 2.0 2
%%Copyright: (c) 1988, 89, 90, 91, 92, 93 Miguel Santana
%%Copyright: (c) 1995, 96, 97, 98 Akim Demaille, Miguel Santana
% Function title: prints page header.
% <ct> <rt> <lt> are passed as argument
/title {
% 1. Draw the background
x v get y v get moveto
gsave
0 th 2 div neg rmoveto
th setlinewidth
0.95 setgray
pw 0 rlineto stroke
grestore
% 2. Border it
gsave
0.7 setlinewidth
pw 0 rlineto
0 th neg rlineto
pw neg 0 rlineto
closepath stroke
grestore
% stk: ct rt lt
x v get y v get th sub 1 add moveto
%%IncludeResource: font Helvetica
fHelvetica fnfs 0.8 mul scalefont setfont
% 3. The left title
gsave
dup stringwidth pop fnfs 0.8 mul add exch % leave space took on stack
fnfs 0.8 mul hm rmoveto
show % left title
grestore
exch
% stk: ct ltw rt
% 4. the right title
gsave
dup stringwidth pop fnfs 0.8 mul add exch % leave space took on stack
dup
pw exch stringwidth pop fnfs 0.8 mul add sub
hm
rmoveto
show % right title
grestore
% stk: ct ltw rtw
% 5. the center title
gsave
pw 3 1 roll
% stk: ct pw ltw rtw
3 copy
% Move to the center of the left room
sub add 2 div hm rmoveto
% What is the available space in here?
add sub fnfs 0.8 mul sub fnfs 0.8 mul sub
% stk: ct space_left
%%IncludeResource: font Helvetica-Bold
fHelvetica-Bold fnfs scalefont setfont
cfshow
grestore
} bind def
% Function border: prints virtual page border
/border { %def
gsave % print four sides
0 setgray
x v get y v get moveto
0.7 setlinewidth % of the square
pw 0 rlineto
0 ph neg rlineto
pw neg 0 rlineto
closepath stroke
grestore
} bind def
% Function water: prints a water mark in background
/water { %def
gsave
scx scy moveto rotate
%%IncludeResource: font Times-Bold
fTimes-Bold 100 scalefont setfont
.97 setgray
dup stringwidth pop 2 div neg -50 rmoveto
show
grestore
} bind def
% Function rhead: prints the right header
/rhead { %def
lx ly moveto
fHelvetica fnfs 0.8 mul scalefont setfont
l-show
} bind def
% Function footer (cf rf lf -> -)
/footer {
fHelvetica fnfs 0.8 mul scalefont setfont
dx dy moveto
show
snx sny moveto
l-show
fnx fny moveto
c-show
} bind def
%%EndResource
%%BeginResource: procset a2ps-black+white-Prolog 2.0 1
% Function T(ab), jumps to the n-th tabulation in the current line
/T {
cw mul x0 add y0 moveto
} bind def
% Function n: move to the next line
/n { %def
/y0 y0 bfs sub store
x0 y0 moveto
} bind def
% Function N: show and move to the next line
/N {
Show
/y0 y0 bfs sub store
x0 y0 moveto
} bind def
/S {
Show
} bind def
/p {
false UL
false BX
fCourier bfs scalefont setfont
Show
} bind def
/sy {
false UL
false BX
fSymbol bfs scalefont setfont
Show
} bind def
/k {
false UL
false BX
fCourier-Oblique bfs scalefont setfont
Show
} bind def
/K {
false UL
false BX
fCourier-Bold bfs scalefont setfont
Show
} bind def
/c {
false UL
false BX
fCourier-Oblique bfs scalefont setfont
Show
} bind def
/C {
false UL
false BX
fCourier-BoldOblique bfs scalefont setfont
Show
} bind def
/l {
false UL
false BX
fHelvetica bfs scalefont setfont
Show
} bind def
/L {
false UL
false BX
fHelvetica-Bold bfs scalefont setfont
Show
} bind def
/str{
false UL
false BX
fTimes-Roman bfs scalefont setfont
Show
} bind def
/e{
false UL
true BX
fHelvetica-Bold bfs scalefont setfont
Show
} bind def
%%EndResource
%%EndProlog
%%BeginSetup
%%IncludeResource: font Courier
%%IncludeResource: font Courier-Oblique
%%IncludeResource: font Courier-Bold
%%IncludeResource: font Times-Roman
%%IncludeResource: font Symbol
%%IncludeResource: font Courier-BoldOblique
%%BeginResource: encoding ISO-8859-1Encoding
/ISO-8859-1Encoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quoteright
/parenleft /parenright /asterisk /plus /comma /minus /period /slash
/zero /one /two /three /four /five /six /seven
/eight /nine /colon /semicolon /less /equal /greater /question
/at /A /B /C /D /E /F /G
/H /I /J /K /L /M /N /O
/P /Q /R /S /T /U /V /W
/X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore
/quoteleft /a /b /c /d /e /f /g
/h /i /j /k /l /m /n /o
/p /q /r /s /t /u /v /w
/x /y /z /braceleft /bar /braceright /asciitilde /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen /registered /macron
/degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /bullet
/cedilla /onesuperior /ordmasculine /guillemotright /onequarter /onehalf /threequarters /questiondown
/Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla
/Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis
/Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply
/Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls
/agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla
/egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis
/eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide
/oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
] def
%%EndResource
% Initialize page description variables.
/sh 842 def
/sw 595 def
/llx 24 def
/urx 571 def
/ury 818 def
/lly 24 def
/#copies 1 def
/th 0.000000 def
/fnfs 11 def
/bfs 12.420527 def
/cw 7.452316 def
% Dictionary for ISO-8859-1 support
/iso1dict 8 dict begin
/fCourier ISO-8859-1Encoding /Courier reencode_font
/fCourier-Bold ISO-8859-1Encoding /Courier-Bold reencode_font
/fCourier-BoldOblique ISO-8859-1Encoding /Courier-BoldOblique reencode_font
/fCourier-Oblique ISO-8859-1Encoding /Courier-Oblique reencode_font
/fHelvetica ISO-8859-1Encoding /Helvetica reencode_font
/fHelvetica-Bold ISO-8859-1Encoding /Helvetica-Bold reencode_font
/fTimes-Bold ISO-8859-1Encoding /Times-Bold reencode_font
/fTimes-Roman ISO-8859-1Encoding /Times-Roman reencode_font
currentdict end def
/bgcolor [ 0 0 0 ] def
/bg false def
/ul false def
/bx false def
% The font for line numbering
/f# /Helvetica findfont bfs .6 mul scalefont def
/fSymbol /Symbol findfont def
/hm fnfs 0.25 mul def
/pw
cw 73.400000 mul
def
/ph
791.187538 th add
def
/pmw 0 def
/pmh 0 def
/v 0 def
/x [
0
] def
/y [
pmh ph add 0 mul ph add
] def
/scx sw 2 div def
/scy sh 2 div def
/snx urx def
/sny lly 2 add def
/dx llx def
/dy sny def
/fnx scx def
/fny dy def
/lx snx def
/ly ury fnfs 0.8 mul sub def
/sx 0 def
/tab 8 def
/x0 0 def
/y0 0 def
%%EndSetup
%%Page: (1) 1
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
() p n
() N
() N
() N
() N
() N
(Internet Engineering Task Force Sumitha Bhandarkar) N
(INTERNET DRAFT A. L. Narasimha Reddy) N
(draft-ietf-tcpm-tcp-dcr-01.txt Texas A&M University) N
(Expires : February 2005 August 2004) N
() N
() N
( Improving the robustness of TCP to Non-Congestion Events.) N
() N
(Status of this Memo) N
() N
( This document is an Internet-Draft and is subject to all provisions) N
( of Section 10 of RFC2026.) N
() N
( Internet-Drafts are working documents of the Internet Engineering) N
( Task Force \(IETF\), its areas, and its working groups. Note that) N
( other groups may also distribute working documents as Internet-) N
( Drafts.) N
() N
( Internet-Drafts are draft documents valid for a maximum of six months) N
( and may be updated, replaced, or obsoleted by other documents at any) N
( time. It is inappropriate to use Internet- Drafts as reference) N
( material or to cite them other than as "work in progress.") N
() N
( The list of current Internet-Drafts can be accessed at) N
( http://www.ietf.org/ietf/1id-abstracts.txt) N
() N
( The list of Internet-Draft Shadow Directories can be accessed at) N
( http://www.ietf.org/shadow.html.) N
() N
(Abstract:) N
() N
( This document proposes TCP-DCR, a simple modification to the TCP) N
( congestion control algorithm to make it more robust to non-congestion) N
( events. In the absence of explicit notification from the network, the) N
( TCP congestion control algorithm treats the receipt of three) N
( duplicate acknowledgements as an indication of congestion in the) N
( network. This is not always correct, notably so in wireless networks) N
( with channel errors or networks prone to excessive packet reordering,) N
( resulting in degraded performance. TCP-DCR aims to remedy this by) N
( delaying the congestion response of TCP for a short interval of time) N
( tau, thereby creating room to handle any non-congestion events that) N
( may have occurred. If at the end of the delay tau, the event is not) N
( handled, then it is treated as a congestion loss. The modifications) N
( themselves do not handle the non-congestion event, but rather rely on) N
( some underlying mechanism to do this. This document discusses the) N
( implications of delaying congestion response on the fairness, TCP-) N
( compatibility and network dynamics, and the benefits to be gained by) N
( applying the TCP-DCR modifications to TCP.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 1]) N
() N
() N
() N
() N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (2) 2
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
(draft-ietf-tcpm-tcp-dcr-01 August 2004) p n
() N
() N
(1. Introduction) N
() N
( In the absence of explicit notification from the network, the TCP) N
( sender treats the receipt of three duplicate acknowledgements) N
( \(dupacks, for short\) as an indication of congestion in the network.) N
( It responds by triggering the fast retransmit/fast recovery) N
( algorithm, where the packet perceived to be lost is retransmitted and) N
( the congestion window is reduced by half to relieve the congestion in) N
( the network. When the reason for the generation of dupacks is not) N
( congestion related, this reduction of the congestion window results) N
( in sub-optimal performance.) N
() N
( The two chief non-congestion events that might cause the generation) N
( of dupacks considered in this document are channel errors in wireless) N
( networks and excessive packet reordering. Several different solutions) N
( have been proposed in literature to improve the performance of TCP in) N
( the presence of channel errors) N
( [BB95,BPSK97,BS97,BSAK95,CLM99,MCGSW01,SVSB99,VMPM02,WT98,YB94] or) N
( packet reordering[BA02,ZKFP02]. This document proposes TCP-DCR which) N
( is a simple and unified solution to improve the robustness of TCP to) N
( any non-congestion event. Even though the discussion here is focussed) N
( on the two chief causes mentioned above, the solution is general) N
( enough to be extended to other non-congestion events resulting in the) N
( generation of dupacks.) N
() N
( Throughout the rest of this document, the term "TCP-DCR" is used to) N
( refer to the modifications that need to be made to TCP to make it) N
( robust to non-congestion events as well as to refer to the TCP flavor) N
( to which the modifications have been applied.) N
() N
(2. Problem Description) N
() N
( The strength of TCP lies in its ability to adjust its sending rate) N
( according to the perceived congestion in the network. In the absence) N
( of explicit notification of congestion from the network, the) N
( traditional TCP flavors use the loss of a packet as an indication of) N
( congestion. In order to help the sender identify a lost packet the) N
( receiver sends acknowledgements for every packet received in-order) N
( and duplicate acknowledgements \(dupacks\) for every packet received) N
( out-of-order. The acks were specified originally in order to clock) N
( out new packets. The use of three dupacks as an indication of) N
( congestion was added later. When the sender receives three) N
( consecutive dupacks, it concludes that the packet is lost due to) N
( congestion.) N
() N
( The TCP sender does not respond to the very first dupack, but waits) N
( for three dupacks to allow for a mildly reordered packet to reach the) N
( receiver, and possibly result in a cumulative acknowledgement.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 2]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (3) 3
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( Limited Transmit, which is now Proposed Standard, allows the sender) p n
( to send new packets in response to the first and second dupacks. The) N
( choice of waiting for three dupacks is purely heuristic. When the) N
( network is responsible for non-negligible amounts of non-congestion) N
( events, this trigger of three dupacks tends to be short and drastic.) N
( The persistent occurance of non-congestion events causes the TCP) N
( sender window to oscillate around a smaller value than what is) N
( actually allowed by the congestion in the network, resulting in) N
( degraded performance.) N
() N
( It is interesting at this point to review the prevalence of non-) N
( congestion events on the Internet. The two chief causes that are) N
( identified and targeted in this document are - wireless channel) N
( errors, and packet reordering within the network. While the existence) N
( of channel errors in the wireless networks is a well accepted fact,) N
( there is a general perception that packet reordering within the) N
( Internet is a rare phenomenon. Several recent measurement studies) N
( [BPS99,JIDKT03] though have shown results contrary to this popular) N
( sentiment. Even if we were to suppose that the amount of packet) N
( reordering in the current Internet is negligibly small, the need for) N
( almost in-order packet delivery places a severe constraint on the) N
( design of novel routing algorithms, network components and) N
( applications. For instance, high speed packet switches could cause) N
( resequencing of packets and there has been work proposed in the) N
( literature to ensure that packet ordering is maintained in such) N
( switches [KM02]. Other examples are multi-path routing, high-delay) N
( satellite links and some of the schemes proposed for differentiated) N
( services architecture. By making TCP more robust to non-congestion) N
( events, we aim to ease this restriction of always in-order delivery) N
( on the design of the future Internet components.) N
() N
(3. Design Guidelines) N
() N
( The proposal for TCP-DCR in this document is motivated by the) N
( following requirements -) N
() N
( * Improve the robustness of TCP to non-congestion events in general,) N
( rather than on a case-by-case basis.) N
() N
( * Maintain the end-to-end TCP semantics.) N
() N
( * Require a minimal amount of modification to the network) N
( infrastructure.) N
() N
( * The solution should lend itself to incremental deployment.) N
() N
( * After the modifications, the protocol should remain compatible with) N
( existing flavors of TCP.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 3]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
(4. Modifications to TCP) N
() N
( The TCP-DCR modifications involve simple changes regarding when the) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (4) 4
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( fast retransmit/recovery algorithms should be triggered. The current) p n
( TCP flavors wait for three dupacks before responding as if a packet) N
( is lost due to congestion. This document extends the concept further) N
( by allowing the TCP-DCR sender to wait for an interval of tau after) N
( receiving the first dupack before responding to it as if it were a) N
( packet lost due to congestion. During the period tau, the TCP sender) N
( sends one new packet for every incoming dupack, if the congestion) N
( window allows it, similar to what is proposed by the Limited Transmit) N
( algorithm [ABF01]. The sender also continues to increase the) N
( congestion window during this period. However, since only one packet) N
( is allowed to be sent in response to each dupack, the number of) N
( packets on the link at any point remains the same as \(or less than\)) N
( the number of packets on the link when the first dupack was received.) N
() N
( The following figure illustrates the behavior of TCP in the presence) N
( of packet reordering, when the TCP-DCR modifications are applied.) N
() N
( |<-------- tau -------->|) N
( Cong Response Delay Timer) N
( Limited Transmit/Additive Increase) N
() N
( No Retransmission/Window Reduction ----+) N
( |) N
( Set Cong Response ------+ | Cong Resp Delay) N
( Delay Timer | | Timer Cancelled) N
( | | |) N
( | <-- Round Trip Time --> | v v |) N
( |) N
( 1 2 3 4 5 6 7 8 9 10 11 v) N
(Sender ---,--,--,--,--,--,----------,-----,--,--,--,----------,-------) N
( \\ * \\ \\ \\ \\ / \\ / \\/ \\/ \\/ \\ /) N
( \\ *\\ \\ \\ \\ / / / / / /) N
( \\ \\* \\ \\ \\ / / /) N
( \\ \\ * \\ \\ / / / / / /) N
( \\ \\ \\ *\\ \\/ / / / / /) N
( \\ \\ \\ \\*/\\ / / / / /) N
( \\ \\ \\ \\ * / / / / /) N
( \\ \\ \\/ \\ \\/* / / / /) N
( \\ \\ /\\ \\ /\\ / */ / /) N
( \\ \\ \\ \\ \\ / * /) N
( \\ / \\ \\/ \\/ \\/ / * /) N
( \\ / \\ /\\ /\\ /\\ / * /) N
(Rcvr ----------------`-----`--`--`--`----------*--------------------) N
( 2 2 2 2 2 8) N
( Figure 1: Behavior of TCP-DCR in the presence of packet reordering.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 4]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( As it can be seen from the figure, when the first dupack is received,) N
( the congestion response delay timer is set. When three dupacks are) N
( received, if the congestion response delay timer has not expired, the) N
( fast retransmit/recovery algorithm is not triggered. If the) N
( acknowledgement for the reordered packet reaches the sender before) N
( the delay timer expires, then the timer is cancelled and the sender) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (5) 5
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( does not suffer unnecessary reduction in the sending rate.) p n
() N
( The following figure illustrates the behavior of TCP in the presence) N
( of packet loss due to congestion, when the TCP-DCR modifications are) N
( applied.) N
() N
() N
( | <-------- tau ---------> |) N
( Cong Response Delay Timer) N
( Limited Transmit) N
( Additive Window Increase) N
() N
( No Retransmission ------------+) N
( No Window Reduction |) N
( |) N
( Set Cong Response ------+ |) N
( Delay Timer | | Retransmission -+) N
( | | Window Reduction |) N
( | | |) N
( | <-- Round Trip Time --> | v v v) N
() N
( 1 2 3 4 5 6 7 8 9 10 11 12 2) N
( ---,--,--,--,--,--,----------,-----,--,--,--,----------,-----,--,--,--) N
( \\ \\ \\ \\ \\ \\ / \\ / \\/ \\/ \\/ \\ / \\ / \\/ /) N
( \\ \\ \\ \\ \\ \\ / \\ / /\\ /\\ /\\ \\ / / / /) N
( \\ \\ \\ \\ \\ \\ / \\ / \\ \\ \\ \\ / / / / /) N
( \\ \\ \\ \\ \\ \\ / / \\/ / \\/ \\ \\ \\ / / / / /) N
( \\ \\ \\ \\ \\ \\/ / /\\ / /\\ \\ \\ \\/ / / / /) N
( \\ \\ \\ \\ \\ /\\ / / / / \\ \\ \\ /\\ / / / /) N
(Cong Drop --> X \\ \\ \\ \\ / / / \\/ \\ \\ \\ \\ / / / /) N
( \\ \\ \\/ \\ \\/ / / /\\ \\ \\/ \\ \\/ / / /) N
( \\ \\ /\\ \\ /\\ / / / \\ \\ /\\ \\ /\\ / / /) N
( \\ \\ \\ \\ \\ / / \\ \\ \\ \\ \\ / /) N
( \\ / \\ \\/ \\/ \\/ / \\ / \\ \\/ \\/ \\/ /) N
( \\ / \\ /\\ /\\ /\\ / \\ / \\ /\\ /\\ /\\ /) N
( ----------------`-----`--`--`--`----------`-----`--`--`--`-----------) N
( 2 2 2 2 2 2 2 2 2 2) N
() N
( Figure 2: Behavior of TCP-DCR in presence of packet loss due to conge) N
(stion.) N
() N
( The figure above shows the behavior of a TCP flow with the TCP-DCR) N
( modifications when a packet has been dropped due to congestion in the) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 5]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( network. In this case a cumulative acknowledgement is not received) N
( before the congestion delay timer expires. As a result, as soon as) N
( the congestion delay timer expires, the fast retransmit/recovery) N
( algorithm is triggered. The next section discusses the upper) N
( threshold on the delay tau so that this delay in congestion response) N
( does not adversely affect the throughput obtained by the flow using) N
( TCP-DCR modifications or the non TCP-DCR flows competing with it.) N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (6) 6
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
(4.1. Choice of the delay duration \(tau\)) p n
() N
( The current implementations of TCP wait for three dupacks before) N
( treating them as an indication of packet loss due to congestion. The) N
( choice of waiting for three dupacks is heuristic. This document) N
( proposes that the delay before responding to congestion should be) N
( longer, so that underlying schemes have time to recover from non-) N
( congestion events. There is no optimal value for this delay such that) N
( all possible non-congestion events can be recovered. It is) N
( essentially a tradeoff between unnecessarily inferring congestion,) N
( and unnecessarily waiting for a long time before retransmitting a) N
( lost packet. Therefore, the choice of the delay is really choosing a) N
( place on the spectrum for the tradeoffs between these two concerns.) N
( This document aims to provide guidelines for reasonable bounds on the) N
( delay to make it useful, without adversely modifying the TCP) N
( behavior.) N
() N
( Consider the case of wireless channel errors. The figure below shows) N
( a general scenario where the TCP sender is connected to the base) N
( station by a wired link and the TCP receiver is connected to a base) N
( station over a wireless link. The wired path between the base station) N
( and the sender TCP could consist of several hops, but would not) N
( affect the discussion here and so is shown as a single hop. The round) N
( trip time between the base station and wireless link is indicated by) N
( 'rtt' and the end-to-end round trip time between the TCP sender and) N
( the TCP receiver is indicated by 'RTT'.) N
() N
( +---------------+) N
( | rtt |) N
( | |) N
( wired | wireless |) N
( TCP link V link | TCP) N
( Sender 0-----------------0---------------0 Receiver) N
( ^ Base |) N
( | Station |) N
( | |) N
( | RTT |) N
( +---------------------------------+) N
() N
( Figure 3: General scenario for a wireless network.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 6]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( In the above scenario, if we ignore ambient delays \(e.g., inter-) N
( packet delay, queuing delay, etc.\), a packet sent by the TCP sender) N
( at some time 't0' reaches the base station at 't0 + \(RTT/2 - rtt/2\)') N
( and the receiver at time 't0 + RTT/2'. Suppose, a packet 'k' sent at) N
( time 't0' is lost on the wireless link due to channel errors. Then at) N
( 't0 + RTT/2 + rtt/2' the base station receives an indication that the) N
( packet 'k' is lost. If it immediately retransmits the packet, then) N
( the packet 'k' is recovered at the receiver at time 't0 + RTT/2 +) N
( rtt'. The sender receives an acknowledgement for the packet 'k' at) N
( 't0 + RTT/2 + rtt + RTT/2'. Hence the sender would have to delay the) N
( congestion response by at least 'rtt' time units, to allow the link) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (7) 7
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( layer to recover the packet. In practice, the inter-packet delays are) p n
( non-zero and the TCP sender does not know the value of 'rtt'. Hence,) N
( a simple solution would be to set the lower bound on the delay in) N
( congestion response to one 'RTT'.) N
() N
( The upper bound on the delay is imposed by the retransmission timer) N
( of TCP. The delay should be chosen such that the RTO timeout is) N
( avoided, because a timeout would be detrimental to the performance of) N
( protocol. The RTO is usually set to \(RTT + 4 * RTTVAR\). The standard) N
( recommends a minimum of 1 second, but many TCP implementations have a) N
( much smaller minimum, e.g., 100 ms. This forms the upper bound on the) N
( value for the congestion response delay tau.) N
() N
( Based on the above discussion, this document recommends the value of) N
( tau to be set as one RTT. In the case of packet reordering, the) N
( amount by which the packet is reordered could be highly variable. The) N
( time to recover the lost packet is the time that the reordered packet) N
( takes to reach the receiver. Hence there is no preset lower bound for) N
( the delay tau, that will facilitate the recovery of a packet) N
( reordered by any amount. However, the upper bound is still decided by) N
( the discussion above. So, a value of one RTT for tau is still a) N
( reasonable choice. We conducted the analysis of the steady state) N
( bandwidth realized by TCP-DCR [BR03]. The results of the analysis) N
( show that the TCP-DCR modifications do not affect the steady state) N
( bandwidth.) N
() N
( TCP-DCR does not increase the per-packet delivery time when there is) N
( no congestion in the network. However, when a packet is dropped, the) N
( choice of tau = one RTT may add upto one additional RTT of delay in) N
( recovering the lost packet. An important fact to remember here is) N
( that, the choice of tau does not cause the TCP-DCR sender to) N
( dramatically over-send packets because the protocol is still ACK-) N
( clocked. That is, a new packet is sent only upon the receipt of a) N
( dupack. If there is suddenly very high congestion in the network) N
( resulting in the drop of several packets, the TCP sender will have) N
( reduced its sending rate simply because not many dupacks are coming) N
( back.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 7]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
(4.2. Implementation Details) N
() N
( The TCP-DCR modifications need to be applied only to the sender and) N
( the receiver remains unmodified. The sender can implement the delay) N
( in congestion response \(tau\) by using either a timer or by modifying) N
( the threshold on the number of duplicate acknowledgements to be) N
( received before triggering fast retransmit/recovery. The timer-based) N
( implementation is quite straight forward, but is influenced by the) N
( coarseness in the clock granularity. In the ack-based delay) N
( implementation, the sender could delay responding to congestion for) N
( the number of duplicate acknowledgements corresponding to the delay) N
( required. Thus, if 'tau' is chosen to be one RTT, the sender would) N
( wait for the receipt of 'W' duplicate acknowledgements before) N
( responding to congestion, where 'W' is the size of the congestion) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (8) 8
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( window when the packet loss is detected.) p n
() N
( The TCP-DCR modifications work with most flavors of the TCP protocol.) N
( However, this document advocates the use of TCP-DCR with TCP-SACK to) N
( ensure that the performance can be maintained high even under the) N
( conditions of multiple losses per round trip time. When used with) N
( TCP-SACK, the only thing modified by TCP-DCR is the time at which the) N
( fast retransmit/recovery algorithm is triggered in response to) N
( dupacks generated by the first loss within a window of packets. All) N
( subsequent losses within the same window \(irrespective of whether) N
( they are congestion related or non-congestion events\) are handled in) N
( exactly the same way as TCP-SACK would in the absence of TCP-DCR) N
( modifications. If the receiver is not SACK-capable, however, then the) N
( sender will have to use TCP-DCR with NewReno.) N
() N
(4.3. Receiver Buffer Requirement when TCP-DCR is used) N
() N
( When TCP-DCR is used, the receiver will need to have additional) N
( buffer space to accommodate the extra packets corresponding to the) N
( delay 'tau', when a packet is lost due to congestion. Having these) N
( extra buffers allows TCP-DCR to achieve the best performance.) N
( However, if the buffers are not available, it does not degrade the) N
( performance, but the maximum performance improvement is not achieved.) N
( This is because, apart from congestion control, TCP also provides) N
( flow control such that a faster sender does not flood a slow) N
( receiver. The flow control is achieved by using a receiver advertised) N
( window, such that at any point the TCP sender may not send more) N
( packets than that allowed by 'min\(cwnd,rwnd\)' where 'cwnd' is the) N
( congestion window and 'rwnd' is the receiver advertised window. When) N
( the buffer space is not available, the receiver advertised window is) N
( small. As a result, during the delay 'tau' even though the limited) N
( transmit and congestion window allow a packet to be transmitted it) N
( will not be sent if the 'rwnd' \(and hence the receiver buffer\) does) N
( not allow it. However, the TCP sender can still delay the congestion) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 8]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( response by 'tau' allowing the local recovery mechanism to recover) N
( from non-congestion event.) N
() N
(4.4. Underlying mechanisms for recovering from non-congestion events) N
() N
( The performance benefits to be gained from using the TCP-DCR) N
( modifications depends heavily on the existence of an underlying) N
( scheme for recovering from the non-congestion events. In the case of) N
( packet reordering, no explicit scheme is required to recover the) N
( reordered packet; the reordered packet reaches the receiver after the) N
( delay that caused it to appear out-of-order. In the case of wireless) N
( networks, a packet corrupted due to channel errors might be recovered) N
( through link-level mechanisms such as link-level retransmissions or) N
( FEC \(Forward Error Correction\). If the corrupted packet is not) N
( recovered through link-level mechanisms, it will be interpreted by) N
( TCP as a packet lost due to congestion, and retransmitted by TCP.) N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (9) 9
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
(5. Performance Evaluation) p n
() N
( This section of the document provides a glimpse of the performance) N
( improvements to be gained by the use of TCP-DCR modifications. The) N
( results presented here are only a small subset of the results) N
( presented in [BR03]. The results are based on simulations on the ns-2) N
( simulator [NS-2].) N
() N
(5.1. Network with packet reordering) N
() N
( The table below shows the effect of delayed packets on the) N
( performance of TCP-SACK and the corresponding improvement in the) N
( performance in case of TCP-DCR. The experiment is conducted with a) N
( dumbell topology with the bottleneck link bandwidth set to 8Mbps.) N
( The end-to-end RTT is set to 104ms. The receiver advertises a very) N
( large window such that the sending rate is not clamped by the) N
( receiver dynamics. There is no congestion in the network. The) N
( topology consists of a single flow. The packet delay is picked from a) N
( normal distribution with a mean of 25ms and a standard deviation of) N
( 8ms. Thus, most packets chosen for delaying are delayed in the range) N
( 0 to 50ms, simulating mild but persistent reordering. The throughput) N
( of TCP-SACK without the TCP-DCR modifications degrades drastically.) N
( However, when the TCP-DCR modifications are applied the performance) N
( is very good even when a large percentage of the packets are delayed.) N
() N
( Percentage Throughput of Throughput of) N
( of Packets TCP-SACK without TCP-SACK with) N
( Delayed TCP-DCR modifications TCP-DCR modifications) N
( \(%\) \(Mbps\) \(Mbps\)) N
( ---------- --------------------- ---------------------) N
( 0.0 7.325 7.352) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 9]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( 1.0 1.043 7.339) N
( 2.0 0.795 7.309) N
( 5.0 0.571 7.185) N
( 8.0 0.498 7.095) N
( 10.0 0.476 7.061) N
( 15.0 0.440 7.000) N
( 20.0 0.410 7.008) N
( 25.0 0.409 7.014) N
( 30.0 0.404 7.006) N
() N
() N
(5.2. Wireless Networks with Channel Errors) N
() N
( The table below shows the effect of channel errors on the performance) N
( of TCP-SACK with and without the TCP-DCR modifications. The topology) N
( for the experiment consists of a sender connected via a wired link to) N
( a router which in turn is connected to the base station by a wired) N
( link. The bandwidth of the wired links is 100Mbps and the delay is) N
( 5ms. The receiver is connected to the base station by a link) N
( simulating a satellite connection with a lower bandwidth and a larger) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (10) 10
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( delay. The bandwidth of this link is 1Mbps and the delay is 250ms.) p n
( Packets are randomly chosen to be corrupted by channel errors. Link) N
( level retransmission is simulated by retransmitting the corrupted) N
( packet after a delay corresponding to the round trip time of the) N
( wireless link.) N
() N
( Channel Throughput of Throughput of) N
( Error TCP-SACK without TCP-SACK with) N
( Rate TCP-DCR modifications TCP-DCR modifications) N
( \(%\) \(Mbps\) \(Mbps\)) N
( ---------- --------------------- --------------------) N
( 0.0 0.962 0.962) N
( 0.5 0.261 0.957) N
( 1.0 0.186 0.952) N
( 2.0 0.131 0.943) N
( 3.0 0.107 0.934) N
( 4.0 0.094 0.925) N
( 5.0 0.086 0.917) N
( 6.0 0.081 0.908) N
( 7.0 0.078 0.900) N
( 8.0 0.073 0.892) N
() N
(5.3. Fairness Implications) N
() N
( This section of the document addresses the fairness issues raised by) N
( delaying congestion response. The steady state analysis of TCP-DCR) N
( [BR03] shows that the throughput of the TCP-DCR protocol is similar) N
( to that of TCP [PFTK98]. Thus, the congestion control dynamics of) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 10]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( TCP-DCR are TCP-friendly. Essentially, TCP-DCR can be seen as a) N
( slowly-responsive TCP-friendly flow as explained in [BBFS01]. It has) N
( been shown in that paper that such flows are TCP-compatible.) N
() N
( Simulation results agree with the discussion above. The following) N
( table shows the average throughput achieved by flows using TCP-SACK) N
( without the TCP-DCR modifications compared to flows using TCP-SACK) N
( with the TCP-DCR modifications in a congested network. The dumbell) N
( topology is used for this experiment with the bottleneck link) N
( capacity of 10Mbps being shared by 12 flows, half of which are TCP-) N
( SACK without TCP-DCR modifications and the other half are TCP-SACK) N
( with the TCP-DCR modifications. There are no non-congestion losses in) N
( the network and congestion is induced by modifying the buffers) N
( available at the bottleneck router. The throughput of each individual) N
( flow varies only slightly from the average throughput.) N
() N
( Congestion Avg. Throughput Avg. Throughput) N
( Droprate of TCP-SACK without of TCP-SACK with) N
( \(%\) TCP-DCR Modifications TCP-DCR Modifications) N
( \(Mbps\) \(Mbps\)) N
( ----------- ---------------------- ---------------------) N
( 0.06 0.808 0.795) N
( 0.36 0.820 0.782) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (11) 11
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( 1.51 0.837 0.765) p n
( 1.86 0.828 0.774) N
( 2.44 0.836 0.767) N
( 3.43 0.767 0.835) N
( 4.57 0.724 0.874) N
( 5.76 0.719 0.788) N
() N
() N
(5.4. Effect on Network Dynamics) N
() N
( When the loss of a packet is indeed due to congestion, delaying the) N
( congestion response could make the protocol sluggish at relieving) N
( congestion in the network. However, when the delay is bounded by one) N
( RTT, the behavior of TCP-DCR is not significantly different from a) N
( TCP flow with high variance in RTT measurements. During the) N
( congestion response delay, the TCP-DCR flow appears like a flow whose) N
( RTT is twice the value when there is no congestion in the network.) N
( Performance evaluation through simulations has validated this view) N
( [BR03].) N
() N
(6. Implementation Issues) N
() N
( The TCP-DCR modifications presented by this document are quite simple) N
( and do not require complicated changes. When the delay "tau" is) N
( implemented based on a timer, the timer value can be set to the) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 11]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( smoothed value of RTT \(SRTT\). However, when the delay "tau" is) N
( implemented by modifying the threshold on the number of dupacks to be) N
( received before responding, the RTT value being used is essentially) N
( the instantaneous value. The upper bound on the congestion response) N
( delay is established by the RTO estimate which is computed based on) N
( the smoothed RTT. This could potentially lead to a situation where) N
( the value of the congestion response delay is larger than the value) N
( of the RTO. Though such a situation could be fairly rare, even few) N
( unnecessary timeouts can degrade the performance drastically. So,) N
( this document recommends that the new threshold on the number of) N
( dupacks to wait before responding be scaled by the factor) N
( \(SRTT\)/\(Current RTT Estimate\).) N
() N
( We have implemented the TCP-DCR modifications in the Linux 2.4.20) N
( kernel. The modifications require changes of only a few lines of) N
( code. Currently, we are in the process of evaluating the reordering) N
( robustness provided by native Linux implementations against that of) N
( TCP-DCR.) N
() N
(7. Incremental Deployment) N
() N
( The TCP-DCR modifications proposed in this document lend themselves) N
( to incremental deployment. Only the TCP protocol on the sender side) N
( needs to be modified. The modifications themselves are minor and can) N
( be distributed easily as kernel patches. The use of TCP-DCR does not) N
( require the sender and receiver to negotiate any conditions during) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (12) 12
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( connection setup. Neither the receivers nor the routers need to be) p n
( aware that the sender has been enhanced with the TCP-DCR) N
( modifications. Availability of additional buffers at the receiver) N
( will help maximize the benefits of using TCP-DCR but are not) N
( necessary.) N
() N
(8. Relationship to other work) N
() N
( Over the past few years, several solutions have been proposed to) N
( improve the performance of TCP over wireless networks. These) N
( solutions fall in one of the following broad categories: split) N
( connection approaches [BB95,BS97,WT98,YB94], TCP-aware link layer) N
( protocols [BSAK95,CLM99], explicit loss notification approaches) N
( [BK98,KAPS02,RF99] and receiver-based approaches [SVSB99,VMPM02]. All) N
( the above mentioned schemes are proposed explicitly for improving the) N
( performance of TCP in wireless networks. While some of them could) N
( possibly be used in situations with other types of non-congestion) N
( events, the simplicity of TCP-DCR in our opinion, makes it a far more) N
( compelling solution for the problem.) N
() N
( It has been shown that the performance of TCP over wireless networks) N
( can be improved by using other flavors of TCP. For example, by using) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 12]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( TCP-SACK [MMFR96] or TCP-westwood [MCGSW01] instead of standard) N
( implementations of TCP Reno, performance can be improved. The) N
( performance improvement by using TCP-SACK protocol however, is due to) N
( its ability to recover from multiple losses in one RTT and does not) N
( necessarily indicate robustness to non-congestion events. This) N
( document advocates the use of TCP-DCR modifications with the TCP-SACK) N
( flavor.) N
() N
( Different solutions have been proposed in the literature to improve) N
( the performance of TCP when the network reorders packets) N
( persistently. In [BA02] the authors present several schemes which use) N
( DSACKs [FMMP00] \(or could alternatively use timestamps [LM03] or) N
( other methods\) to identify a false fast retransmit. In response, the) N
( sending rate is restored back to the level it was before the false) N
( fast retransmit. The reordering length for the packet is measured) N
( using the information available from DSACKs and the threshold on the) N
( number of dupacks to be received before responding \(dupthresh\) is) N
( increased to avoid future false fast retransmits. If a RTO timeout) N
( occurs, then it is presumed that the dupthresh has grown too large) N
( and it is reset to 3. In [ZKFP02] this process is further refined at) N
( the cost of maintaining significantly more state at the sender and) N
( using complicated algorithms for finding the optimal value for) N
( dupthresh such that costly RTO timeouts are avoided, while the) N
( performance is optimized to provide maximum reordering robustness.) N
() N
( These solutions rely on some additional scheme for identifying) N
( reordering in the network \(such as DSACKs or timestamps\) and the) N
( perceived reordering information is collected from the network to set) N
( an optimal value for dupthresh. The Linux TCP provides an option of) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (13) 13
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( using either of these additional schemes or just the information from) p n
( SACK to estimate the reordering length. The intent is to estimate the) N
( optimal amount of time to delay the triggering of fast) N
( retransmit/recovery algorithms to provide maximum reordering) N
( robustness, without resorting to RTO timeouts too often. By using) N
( TCP-DCR, this goal can be met without having to use complex state or) N
( algorithms for tuning the value of dupthresh. While TCP-DCR does not) N
( tune the dupthresh based on the perceived reordering in the network,) N
( when it is set to one RTT, it provides a simple and effective) N
( mechanism for providing reordering robustness without causing RTO) N
( timeouts. If the actual reordering within the network is less than) N
( one RTT, then no harm is done since no action is necessary when the) N
( packet is recovered. When the packet is reordered by more than one) N
( RTT, TCP-DCR does not wait for it it to be recovered, but in doing so) N
( avoids costly retransmission timeouts.) N
() N
(9. Security Considerations) N
() N
( This proposal makes no changes to the underlying security of TCP.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 13]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
(10. Conclusions) N
() N
( This document has proposed TCP-DCR modifications to TCP's congestion) N
( control mechanism to make it more robust to non-congestion events. We) N
( have explored this proposal though analysis and simulations, and are) N
( currently in the process of evaluating it through experiments on the) N
( Linux platform. We believe that TCP-DCR provides a simple, unified) N
( solution to improve the the robustness of TCP to non-congestion) N
( events, and that the solution is safe to deploy on the Internet. We) N
( would welcome additional analysis, simulations, and experimentation.) N
() N
( We are bringing this proposal to the IETF to be considered as an) N
( Experimental RFC.) N
() N
(11. Acknowledgements) N
() N
( We would like to thank Dr. Nitin Vaidya and Nauzad Sadry for their) N
( invaluable help with the wireless simulations. Comments from Sally) N
( Floyd have helped immensely in improving the quality of this) N
( document.) N
() N
(12. References) N
() N
( [ABF01] M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's) N
( Loss Recovery Using Limited Transmit," RFC 3042, Proposed Standard,) N
( January 2001.) N
() N
( [BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet) N
( Reordering," ACM Computer Communication Review, January 2002.) N
() N
( [BB95] A. Bakre and B. R. Badrinath, "I-TCP: indirect TCP for mobile) N
( hosts," Proceedings of the 15th. International Conference on) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (14) 14
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( Distributed Computing Systems \(ICDCS\), May 1995.) p n
() N
( [BBFS01] D. Bansal, H. Balakrishnan, S. Floyd and Scott Shenker,) N
( "Dynamic Behavior of Slowly Responsive Congestion Control) N
( Algorithms," Proceedings of ACM SIGCOMM, Sep. 2001.) N
() N
( [BK98] H. Balakrishnan and R. H. Katz, "Explicit Loss Notification) N
( and Wireless Web Performance," Proc. of IEEE GLOBECOM, Nov. 1998.) N
() N
( [BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering) N
( is not pat hological network behavior," IEEE/ACM Transactions on) N
( Networking, December 1999.) N
() N
( [BPSK97] H. Balakrishnan, V. Padmanabhan, S. Seshan, and R. H. Katz,) N
( "A Comparison of Mechanisms for Improving TCP Performance over) N
( Wireless Links," IEEE/ACM Transactions on Networking, 1997.) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 14]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( [BR03] Sumitha Bhandarkar, and A. L. N. Reddy, "TCP-DCR: Making TCP) N
( Robust to Non-Congestion Losses," Technical Report TAMU-ECE-2003-04,) N
( July 2003.) N
() N
( [BS97] K. Brown and S. Singh, "M-TCP: TCP for mobile cellular) N
( networks," ACM Computer Communications Review, vol. 27, no. 5,) N
( 1997.) N
() N
( [BSAK95] H. Balakrishnan, S. Seshan, E. Amir and R. Katz, "Improving) N
( TCP/IP performance over wireless networks," Proc. of ACM MOBICOM,) N
( Nov. 1995.) N
() N
( [CLM99] H. M. Chaskar, T. V. Lakshman, and U. Madhow, "TCP Over) N
( Wireless with Link Level Error Control: Analysis and Design) N
( Methodology", IEEE Trans. on Networking, vol. 7, no. 5, Oct. 1999.) N
() N
( [FMMP00] Sally Floyd, Jamshid Mahdavi, Matt Mathis and Matt Podolsky,) N
( "An Extension to the Selective Acknowledgement \(SACK\) Option for) N
( TCP," RFC 2883, July 2000.) N
() N
( [JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D.) N
( Towsley, "Measur ement and Classification of Out-of-Sequence Packets) N
( in a Tier-1 IP Backbone," Pr oceedings of IEEE INFOCOM, 2003.) N
() N
( [KAPS02] R. Krishnan, M. Allman, C. Partridge and J. P.G. Sterbenz,) N
( "Explicit Transport Error Notification for Error-Prone Wireless and) N
( Satellite Networks," BBN Technical Report No. 8333, BBN Technologies,) N
( February, 2002) N
() N
( [KM02] I. Keslassy and N. McKeown, "Maintaining packet order in) N
( twostage switche s," Proceedings of the IEEE Infocom, June 2002) N
() N
( [LM03] R. Ludwig and M. Meyer, "The Eifel Detection Algorithm for) N
( TCP," RFC 3522, April 2003.) N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (15) 15
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( [MCGSW01] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi and R. Wang,) p n
( "TCP Westwood: Bandwidth Estimation for Enhanced Transport over) N
( Wireless Links," Proceedings of ACM MOBICOM, 2001.) N
() N
( [MMFR] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP selective) N
( acknowledgment options," Internet RFC 2018.) N
() N
( [NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/) N
() N
( [RF99] K. Ramakrishnan and S. Floyd, "A Proposal to add Explicit) N
( Congestion Notification \(ECN\) to IP," RFC 2481, January 1999.) N
() N
( [SVSB99] P. Sinha, N. Venkitaraman, R. Sivakumar and V. Bhargavan,) N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 15]) N
() N
() N
() N
() N
() N
(draft-ietf-tcpm-tcp-dcr-01 August 2004) N
() N
() N
( "WTCP: A Reliable Transport Protocol for Wireless Wide-Area) N
( Networks," Proceedings of ACM MOBICOM, August 1999.) N
() N
( [VMPM02] N. H. Vaidya, M. Mehta, C. Perkins and G. Montenegro,) N
( "Delayed Duplicate Acknowledgement: a TCP-unaware Approach to Improve) N
( Performance of TCP over Wireless," Journal of Wireless Communications) N
( and Mobile Computing, special issue on Reliable Transport Protocols) N
( for Mobile Computing, February 2002.) N
() N
( [WT98] K.-Y. Wang and S. K. Tripathi, "Mobile-end transport protocol:) N
( An alternative to TCP/IP over wireless links," IEEE INFOCOM'98,) N
( vol. 3, p. 1046, 1998.) N
() N
( [YB94] R. Yavatkar and N. Bhagawat, "Improving End-to-End Performance) N
( of TCP over Mobile Internetworks," Workshop on Mobile Computing) N
( Systems and Applications, December 1994.) N
() N
( [ZKFP02] M. Zhang, B. Karp, S. Floyd, and L. Peterson, "RR-TCP: A) N
( Reordering-Robust TCP with DSACK," ICSI Technical Report TR-02-006,) N
( Berkeley, CA, July 2002.) N
() N
(13. Author's Addresses) N
() N
( Sumitha Bhandarkar) N
( Dept. of Elec. Engg.) N
( 214 ZACH) N
( College Station, TX 77843-3128) N
( Phone: \(512\) 468-8078) N
( Email: sumitha@tamu.edu) N
( URL : http://students.cs.tamu.edu/sumitha/) N
() N
( A. L. Narasimha Reddy) N
( Associate Professor) N
( Dept. of Elec. Engg.) N
( 315C WERC) N
( College Station, TX 77843-3128) N
( Phone : \(979\) 845-7598) N
( Email : reddy@ee.tamu.edu) N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Page: (16) 16
%%BeginPageSetup
/pagesave save def
%%EndPageSetup
iso1dict begin
gsave
llx lly 0 add translate
/v 0 store
/x0 x v get 5.216621 add sx cw mul add store
/y0 y v get bfs sub store
x0 y0 moveto
( URL : http://ee.tamu.edu/~reddy/) p n
() N
() N
() N
() N
() N
() N
() N
() N
() N
() N
() N
() N
(Bhandarkar/Reddy Expires February 2005 [Page 16]) N
() N
() N
border
grestore
end % of iso1dict
pagesave restore
showpage
%%Trailer
end
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-21 10:41:04 |