One document matched: draft-floyd-tcpm-ackcc-01.ps
%!PS-Adobe-3.0
%%BoundingBox: 24 24 588 768
%%Title: Enscript Output
%%For: Sally Floyd
%%Creator: GNU enscript 1.6.1
%%CreationDate: Wed Jun 13 13:53:33 2007
%%Orientation: Portrait
%%Pages: (atend)
%%DocumentMedia: Letter 612 792 0 () ()
%%DocumentNeededResources: (atend)
%%EndComments
%%BeginProlog
%%BeginResource: procset Enscript-Prolog 1.6 1
%
% Procedures.
%
/_S { % save current state
/_s save def
} def
/_R { % restore from saved state
_s restore
} def
/S { % showpage protecting gstate
gsave
showpage
grestore
} bind def
/MF { % fontname newfontname -> - make a new encoded font
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
% insert only valid encoding vectors
encoding_vector length 256 eq {
newfont /Encoding encoding_vector put
} if
newfontname newfont definefont pop
} def
/SF { % fontname width height -> - set a new font
/height exch def
/width exch def
findfont
[width 0 0 height 0 0] makefont setfont
} def
/SUF { % fontname width height -> - set a new user font
/height exch def
/width exch def
/F-gs-user-font MF
/F-gs-user-font width height SF
} def
/M {moveto} bind def
/s {show} bind def
/Box { % x y w h -> - define box path
/d_h exch def /d_w exch def /d_y exch def /d_x exch def
d_x d_y moveto
d_w 0 rlineto
0 d_h rlineto
d_w neg 0 rlineto
closepath
} def
/bgs { % x y height blskip gray str -> - show string with bg color
/str exch def
/gray exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
gray setgray
fill
grestore
x y M str s
} def
% Highlight bars.
/highlight_bars { % nlines lineheight output_y_margin gray -> -
gsave
setgray
/ymarg exch def
/lineheight exch def
/nlines exch def
% This 2 is just a magic number to sync highlight lines to text.
0 d_header_y ymarg sub 2 sub translate
/cw d_output_w cols div def
/nrows d_output_h ymarg 2 mul sub lineheight div cvi def
% for each column
0 1 cols 1 sub {
cw mul /xp exch def
% for each rows
0 1 nrows 1 sub {
/rn exch def
rn lineheight mul neg /yp exch def
rn nlines idiv 2 mod 0 eq {
% Draw highlight bar. 4 is just a magic indentation.
xp 4 add yp cw 8 sub lineheight neg Box fill
} if
} for
} for
grestore
} def
% Line highlight bar.
/line_highlight { % x y width height gray -> -
gsave
/gray exch def
Box gray setgray fill
grestore
} def
% Column separator lines.
/column_lines {
gsave
.1 setlinewidth
0 d_footer_h translate
/cw d_output_w cols div def
1 1 cols 1 sub {
cw mul 0 moveto
0 d_output_h rlineto stroke
} for
grestore
} def
% Column borders.
/column_borders {
gsave
.1 setlinewidth
0 d_footer_h moveto
0 d_output_h rlineto
d_output_w 0 rlineto
0 d_output_h neg rlineto
closepath stroke
grestore
} def
% Do the actual underlay drawing
/draw_underlay {
ul_style 0 eq {
ul_str true charpath stroke
} {
ul_str show
} ifelse
} def
% Underlay
/underlay { % - -> -
gsave
0 d_page_h translate
d_page_h neg d_page_w atan rotate
ul_gray setgray
ul_font setfont
/dw d_page_h dup mul d_page_w dup mul add sqrt def
ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto
draw_underlay
grestore
} def
/user_underlay { % - -> -
gsave
ul_x ul_y translate
ul_angle rotate
ul_gray setgray
ul_font setfont
0 0 ul_h_ptsize 2 div sub moveto
draw_underlay
grestore
} def
% Page prefeed
/page_prefeed { % bool -> -
statusdict /prefeed known {
statusdict exch /prefeed exch put
} {
pop
} ifelse
} def
% Wrapped line markers
/wrapped_line_mark { % x y charwith charheight type -> -
/type exch def
/h exch def
/w exch def
/y exch def
/x exch def
type 2 eq {
% Black boxes (like TeX does)
gsave
0 setlinewidth
x w 4 div add y M
0 h rlineto w 2 div 0 rlineto 0 h neg rlineto
closepath fill
grestore
} {
type 3 eq {
% Small arrows
gsave
.2 setlinewidth
x w 2 div add y h 2 div add M
w 4 div 0 rlineto
x w 4 div add y lineto stroke
x w 4 div add w 8 div add y h 4 div add M
x w 4 div add y lineto
w 4 div h 8 div rlineto stroke
grestore
} {
% do nothing
} ifelse
} ifelse
} def
% EPSF import.
/BeginEPSF {
/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
/showpage { } def
0 setgray 0 setlinecap
1 setlinewidth 0 setlinejoin
10 setmiterlimit [ ] 0 setdash newpath
/languagelevel where {
pop languagelevel
1 ne {
false setstrokeadjust false setoverprint
} if
} if
} bind def
/EndEPSF {
count op_count sub { pos } repeat % Clean up stacks
countdictstack dict_count sub { end } repeat
b4_Inc_state restore
} bind def
% Check PostScript language level.
/languagelevel where {
pop /gs_languagelevel languagelevel def
} {
/gs_languagelevel 1 def
} ifelse
%%EndResource
%%BeginResource: procset Enscript-Encoding-88591 1.6 1
/encoding_vector [
/.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 /hyphen /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 /tilde /.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
%%EndProlog
%%BeginSetup
%%IncludeResource: font Courier-Bold
%%IncludeResource: font Courier
/HFpt_w 10 def
/HFpt_h 10 def
/Courier-Bold /HF-gs-font MF
/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def
/Courier /F-gs-font MF
/F-gs-font 10 10 SF
/#copies 1 def
% Pagedevice definitions:
gs_languagelevel 1 gt {
<<
/PageSize [612 792]
>> setpagedevice
} if
/d_page_w 564 def
/d_page_h 744 def
/d_header_x 0 def
/d_header_y 744 def
/d_header_w 564 def
/d_header_h 0 def
/d_footer_x 0 def
/d_footer_y 0 def
/d_footer_w 564 def
/d_footer_h 0 def
/d_output_w 564 def
/d_output_h 744 def
/cols 1 def
%%EndSetup
%%Page: (1) 1
%%BeginPageSetup
_S
24 24 translate
/pagenum 1 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 621 M
(Internet Engineering Task Force S. Floyd) s
5 610 M
(INTERNET-DRAFT ICIR) s
5 599 M
(Intended status: Experimental A. Arcia) s
5 588 M
(Expires: 13 December 2007 D. Ros) s
5 577 M
( ENST Bretagne) s
5 566 M
( J. Iyengar) s
5 555 M
( Connecticut College) s
5 544 M
( 13 June 2007) s
5 511 M
( Adding Acknowledgement Congestion Control to TCP) s
5 500 M
( draft-floyd-tcpm-ackcc-01.txt) s
5 467 M
(Status of this Memo) s
5 445 M
( By submitting this Internet-Draft, each author represents that any) s
5 434 M
( applicable patent or other IPR claims of which he or she is aware) s
5 423 M
( have been or will be disclosed, and any of which he or she becomes) s
5 412 M
( aware will be disclosed, in accordance with Section 6 of BCP 79.) s
5 390 M
( Internet-Drafts are working documents of the Internet Engineering) s
5 379 M
( Task Force \(IETF\), its areas, and its working groups. Note that) s
5 368 M
( other groups may also distribute working documents as Internet-) s
5 357 M
( Drafts.) s
5 335 M
( Internet-Drafts are draft documents valid for a maximum of six months) s
5 324 M
( and may be updated, replaced, or obsoleted by other documents at any) s
5 313 M
( time. It is inappropriate to use Internet-Drafts as reference) s
5 302 M
( material or to cite them other than as "work in progress.") s
5 280 M
( The list of current Internet-Drafts can be accessed at) s
5 269 M
( http://www.ietf.org/ietf/1id-abstracts.txt.) s
5 247 M
( The list of Internet-Draft Shadow Directories can be accessed at) s
5 236 M
( http://www.ietf.org/shadow.html.) s
5 214 M
( This Internet-Draft will expire on 13 December 2007.) s
5 192 M
(Copyright Notice) s
5 170 M
( Copyright \(C\) The IETF Trust \(2007\).) s
5 104 M
(Floyd [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
24 24 translate
/pagenum 2 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
(Abstract) s
5 665 M
( This document adds an optional congestion control mechanism for) s
5 654 M
( acknowledgement traffic \(ACKs\) to TCP. The document specifies an) s
5 643 M
( end-to-end acknowledgement congestion control mechanism for TCP that) s
5 632 M
( uses participation from both TCP hosts, the TCP data sender and the) s
5 621 M
( TCP data receiver. The TCP data sender detects lost and ECN-marked) s
5 610 M
( ACK packets, and tells the TCP data receiver the ACK Ratio R to use) s
5 599 M
( to respond to the congestion on the reverse path from the data) s
5 588 M
( receiver to the data sender. The TCP data receiver sends roughly one) s
5 577 M
( ACK packet for every R data packets received. This mechanism is) s
5 566 M
( based on the acknowledgement congestion control in DCCP's CCID 2.) s
5 555 M
( This acknowledgement congestion control mechanism is being proposed) s
5 544 M
( as an experimental mechanism for TCP for evaluation by the network) s
5 533 M
( community.) s
5 126 M
(Floyd [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
24 24 translate
/pagenum 3 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
(Table of Contents) s
5 665 M
( 1. Introduction ....................................................4) s
5 654 M
( 2. Conventions and Terminology .....................................5) s
5 643 M
( 3. Overview ........................................................6) s
5 632 M
( 4. Related Work ....................................................6) s
5 621 M
( 5. Acknowledgement Congestion Control ..............................8) s
5 610 M
( 5.1. Negotiating the Use of ACK Congestion Control ..............8) s
5 599 M
( 5.2. The TCP ACK Ratio Option ...................................9) s
5 588 M
( 5.3. The Receiver: Implementing the ACK Ratio ...................9) s
5 577 M
( 5.4. The Sender: Determining Lost or Marked ACK Packets ........10) s
5 566 M
( 5.5. The Sender: Adjusting the ACK Ratio .......................11) s
5 555 M
( 5.6. The Receiver: Sending ACKs for Out-of-Order Data Segments) s
5 544 M
( ................................................................12) s
5 533 M
( 5.7. The Sender: Response to ACK Packets .......................12) s
5 522 M
( 5.8. Possible Additions: Receiver Bounds on the Ack Ratio ......14) s
5 511 M
( 6. Possible Complications .........................................14) s
5 500 M
( 6.1. Possible Complications: Delayed Acknowledgements ..........14) s
5 489 M
( 6.2. Possible Complications: Duplicate Acknowledgements. .......14) s
5 478 M
( 6.3. Possible Complications: Two-Way Traffic. ..................15) s
5 467 M
( 6.4. Possible Complications: Reordering of ACK Packets. ........15) s
5 456 M
( 6.5. Possible Complications: Abrupt Changes in the ACK Path. ...15) s
5 445 M
( 6.6. Possible Complications: Corruption. .......................15) s
5 434 M
( 6.7. Possible Complications: ACKs That Don't Contribute to Con-) s
5 423 M
( gestion. .......................................................15) s
5 412 M
( 6.8. Other Issues ..............................................18) s
5 401 M
( 7. Evaluating ACK Congestion Control ..............................19) s
5 390 M
( 8. Measurements of ACK Traffic and Congestion .....................19) s
5 379 M
( 9. Acknowledgement Congestion Control in CCID 2 ...................19) s
5 368 M
( 10. Security Considerations .......................................20) s
5 357 M
( 11. IANA Considerations ...........................................21) s
5 346 M
( 12. Conclusions ...................................................21) s
5 335 M
( 13. Acknowledgements ..............................................21) s
5 324 M
( Normative References ..............................................21) s
5 313 M
( Informative References ............................................22) s
5 302 M
( Full Copyright Statement ..........................................23) s
5 291 M
( Intellectual Property .............................................24) s
5 126 M
(Floyd [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
24 24 translate
/pagenum 4 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:) s
5 665 M
( Changes from draft-floyd-tcpm-ackcc-00.txt:) s
5 643 M
( * Added a discussion of environments where the reverse path) s
5 632 M
( is congested, but the TCP ACK traffic does not significantly) s
5 621 M
( contribute to that congestion. In this case, the goal is) s
5 610 M
( to minimize the negative impack of AckCC on TCP performance.) s
5 599 M
( Feedback from Armando Caro.) s
5 577 M
( * In Section 5.7, added that when ABC is used with Aggregate) s
5 566 M
( Congestion Control, and rate-based pacing is also used, the sender) s
5 555 M
( MAY increase cwnd by more than 2 MSS.) s
5 544 M
( Feedback from Armando Caro.) s
5 522 M
( * Added a section about measurements of ACK traffic and congestion.) s
5 511 M
( Feedback from Armando Caro.) s
5 489 M
( * Added a section on the possibility of a TCP receiver-imposed) s
5 478 M
( lower bound on the ACK Ratio. Suggested by Mark Allman.) s
5 456 M
( * Added to the discussion of the mimumum ACK sending rate.) s
5 445 M
( Suggested by Mark Allman.) s
5 423 M
( * Added a note that if the TCP receiver doesn't sent an ACK for) s
5 412 M
( every duplicate data packet, the sender's Fast Recovery) s
5 401 M
( procedure will have to be modified to take this into) s
5 390 M
( account. Feedback from Mark Allman.) s
5 368 M
( * Added a discussion of evaluating ACK Congestion Control.) s
5 357 M
( From feedback from Mark Allman.) s
5 335 M
( * Some general editing in response to feedback from Mark Allman.) s
5 313 M
( END OF SECTION TO BE DELETED.) s
5 291 M
(1. Introduction) s
5 269 M
( This documents adds an optional congestion control mechanism to TCP) s
5 258 M
( for acknowledgements \(ACKs\). This mechanism is based on the) s
5 247 M
( acknowledgement congestion control in DCCP's CCID 2 [RFC4340],) s
5 236 M
( [RFC4341], which is a successor to the TCP acknowledgement congestion) s
5 225 M
( control mechanism proposed by Balakrishnan et at. in [BPK97].) s
5 203 M
( In this document we use the termininology of senders and receivers,) s
5 192 M
( with the sender sending data traffic, and the receiver sending) s
5 181 M
( acknowledgement traffic in response. In CCID 2's acknowledgement) s
5 170 M
( congestion control, specified in Section 6.1 of [RFC4341], the) s
5 126 M
(Floyd [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
24 24 translate
/pagenum 5 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( receiver uses an ACK Ratio R reported to it by the sender, sending) s
5 676 M
( roughly one ACK packet for every R data packets received. The CCID 2) s
5 665 M
( sender keeps the acknowledgement rate roughly TCP friendly by) s
5 654 M
( monitoring the acknowledgement stream for lost and marked ACK packets) s
5 643 M
( and modifying the ACK Ratio accordingly. For every RTT containing an) s
5 632 M
( ACK congestion event \(that is, a lost or marked ACK packet\), the) s
5 621 M
( sender halves the acknowledgement rate by doubling the ACK Ratio; for) s
5 610 M
( every RTT containing no ACK congestion event, the sender additively) s
5 599 M
( increases the acknowledgement rate through gradual decreases in the) s
5 588 M
( ACK Ratio.) s
5 566 M
( The goal of this document is to explore a similar congestion control) s
5 555 M
( mechanism for acknowledgement traffic for TCP. The goal is for the) s
5 544 M
( TCP sender to monitor the packet drop rate for ACK packets, and to) s
5 533 M
( respond to a high ACK packet drop rate by instructing the receiver to) s
5 522 M
( reduce the sending rate for ACK packets. The assumption is that in) s
5 511 M
( some environments with congestion on the reverse path, reducing the) s
5 500 M
( sending rate for ACK traffic traversing the congested path can help) s
5 489 M
( to reduce the congestion itself, in turn reducing the packet drop) s
5 478 M
( rates for the ACK traffic. For those environments where the reverse) s
5 467 M
( path is congested but where TCP ACK traffic does not appreciably) s
5 456 M
( contribute to that aggregate congestion, the goal is for TCP's ACK) s
5 445 M
( congestion control to have a minimal negative effect on the) s
5 434 M
( performance of the TCP connection.) s
5 412 M
( Adding acknowledgement congestion control as an option in TCP) s
5 401 M
( requires the following:) s
5 379 M
( * An agreement from the TCP hosts on the use of ACK congestion) s
5 368 M
( control. The TCP hosts use a new TCP option, the ACK-Congestion-) s
5 357 M
( Control-Permitted Option.) s
5 335 M
( * A mechanism for the TCP sender to detect lost and ECN-marked pure) s
5 324 M
( acknowledgement packets.) s
5 302 M
( * A mechanism for adjusting the ACK Ratio. The TCP sender adjusts) s
5 291 M
( the ACK Ratio as specified in Section 6.1.2 of [RFC4341].) s
5 269 M
( * A method for the TCP sender to inform the TCP receiver of a new) s
5 258 M
( value for the ACK Ratio. The TCP sender uses a new TCP option, the) s
5 247 M
( ACK Ratio Option.) s
5 225 M
(2. Conventions and Terminology) s
5 203 M
( The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",) s
5 192 M
( "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this) s
5 181 M
( document are to be interpreted as described in [RFC2119]. MSS) s
5 170 M
( refers to the Maximum Segment Size.) s
5 126 M
(Floyd [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
24 24 translate
/pagenum 6 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
(3. Overview) s
5 665 M
( This section gives a non-normative overview of acknowledgement) s
5 654 M
( congestion control for TCP.) s
5 632 M
( [Graphics will be added.]) s
5 610 M
( During connection initiation, TCP host B sends an ACK-Congestion-) s
5 599 M
( Control-Permitted option on its SYN or SYN/ACK packet. This allows) s
5 588 M
( TCP host A \(now called the sender\) to send instructions to TCP host B) s
5 577 M
( \(now called the receiver\) about the Ack Ratio to use in responding to) s
5 566 M
( data packets.) s
5 544 M
( Also during connection initiation, TCP host A sends an ACK-) s
5 533 M
( Congestion-Control-Permitted option on its SYN or SYN/ACK packet. In) s
5 522 M
( combination with TCP host B's sending of an ACK-Congestion-Control-) s
5 511 M
( Permitted option, this allows TCP host B to send its ACK packets as) s
5 500 M
( ECN-Capable.) s
5 478 M
( The TCP receiver starts with an ACK Ratio of two, generally sending) s
5 467 M
( one ACK packet for every two data packets received.) s
5 445 M
( The TCP sender detects lost or ECN-marked ACK packets from the TCP) s
5 434 M
( receiver, and at some point sends an ACK Ratio option of three to the) s
5 423 M
( receiver. The TCP receiver changes to an ACK Ratio of three,) s
5 412 M
( generally sending one ACK packet for every three data packets. The) s
5 401 M
( TCP sender uses Appropriate Byte Counting and rate-based pacing in) s
5 390 M
( responding to these ACK packets.) s
5 368 M
( The TCP sender detects fewer lost ACK packets, and at some point) s
5 357 M
( sends an ACK Ratio option of two to the TCP receiver. The TCP) s
5 346 M
( receiver changes back to an ACK Ratio of two, generally sending one) s
5 335 M
( ACK packet for every two data packets.) s
5 313 M
(4. Related Work) s
5 291 M
( The goal of the mechanism proposed in this document is to control) s
5 280 M
( pure ACK traffic on the path from the TCP data receiver to the TCP) s
5 269 M
( data sender. Note that the approach outlined here is an end-to-end) s
5 258 M
( one \(as is the approach followed by DCCP's CCID 2 [RFC4341]\), but it) s
5 247 M
( may also take advantage of explicit congestion information from the) s
5 236 M
( network conveyed by ECN [RFC3168], if available. The ECN) s
5 225 M
( specification [RFC3168, section 6.1.4] prohibits a TCP receiver from) s
5 214 M
( setting the ECT\(0\) or ECT\(1\) codepoints in IP packets carrying pure) s
5 203 M
( ACKs, but *only* as long as the receiver does *not* implement any) s
5 192 M
( form of ACK congestion control.) s
5 170 M
( There exist several papers dealing with controlling congestion in the) s
5 126 M
(Floyd [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
24 24 translate
/pagenum 7 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( reverse path of a TCP connection, especially in the context of) s
5 676 M
( networks with bandwidth asymmetry. Some of these proposals require) s
5 665 M
( explicit support from routers or middleboxes, whereas others are) s
5 654 M
( "pure" end-to-end schemes.) s
5 632 M
( Balakrishnan et al. \([BPK97]\) describe the use of ECN to detect) s
5 621 M
( congestion in the return path, in order to reduce the sending rate of) s
5 610 M
( ACKs. The use of a RED queue in the reverse path allows for marking) s
5 599 M
( of ACK packets. The sender echoes back ECN congestion marks to the) s
5 588 M
( receiver. The receiver keeps an ACK ratio d \(called the "delayed-ACK) s
5 577 M
( factor"\), specifying the number of data segments that have to be) s
5 566 M
( received before the receiver sends a new ACK. The ACK ratio d is) s
5 555 M
( managed using multiplicative-increase, additive-decrease; upon) s
5 544 M
( reception of a congestion mark, the receiver doubles the value of d) s
5 533 M
( \(hence dividing the ACK sending rate by two\). The ACK ratio) s
5 522 M
( decreases linearly for each RTT in which no ECN-marked ACKs are) s
5 511 M
( received. Multiple congestion marks received in an RTT are treated) s
5 500 M
( as a single congestion event, i.e., d can be doubled at most once per) s
5 489 M
( RTT. The TCP timestamp option is used to keep track of the RTT) s
5 478 M
( values.) s
5 456 M
( In [TJW00], Tam Ming-Chit et al. propose a receiver-based method for) s
5 445 M
( calculating an "appropriate" number of ACKs per congestion window) s
5 434 M
( \(cwnd\) of data, in order to alleviate congestion on the reverse path.) s
5 423 M
( The sender's cwnd is estimated at the receiver by counting the number) s
5 412 M
( of received packets per RTT \(which also has to be estimated by the) s
5 401 M
( receiver\). From this estimate, a simple algorithm is used to compute) s
5 390 M
( the number of ACKs to be sent per cwnd. The algorithm enforces a) s
5 379 M
( lower bound on the number of ACKs per cwnd, aiming at minimizing the) s
5 368 M
( probability of timeout at the sender due to ACK loss. Similarly, the) s
5 357 M
( ACK ratio is upper-bounded so as to avoid excessive ACK delay.) s
5 335 M
( ACK filtering \(AF\) [BPK97] from Balakrishnan et al. is a router-based) s
5 324 M
( technique that tries to reduce the number of ACKs sent over the) s
5 313 M
( congested return link. With AF, an arriving ACK may replace) s
5 302 M
( preceding, older ACKs at the bottleneck queue. An aggressive) s
5 291 M
( replacement policy might guarantee that at most one ACK per) s
5 280 M
( connection is waiting in the queue, alleviating congestion. However,) s
5 269 M
( as in other proposals, care must be taken to avoid sender timeouts in) s
5 258 M
( case the \(too few\) ACKs resulting from the filtering get lost. The) s
5 247 M
( idea of filtering ACKs has been extended in [YMH03] to deal with SACK) s
5 236 M
( information.) s
5 214 M
( Blandford et al. [BGG+07] propose an end-to-end, receiver-oriented) s
5 203 M
( scheme called "smartacking". The algorithm is based upon the) s
5 192 M
( receiver monitoring the inter-segment arrival time for data packets) s
5 181 M
( and adapting the ACK sending rate in response. When the bottleneck) s
5 170 M
( link is underutilized, ACKs are sent frequently \(up to one ACK per) s
5 126 M
(Floyd [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
24 24 translate
/pagenum 8 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( received segment\) to promote fast growth of the congestion window.) s
5 676 M
( On the other hand, when the bottleneck is close to full utilization,) s
5 665 M
( the algorithm tries to reduce control traffic overhead and slow) s
5 654 M
( congestion window growth by generating ACKs at the minimum rate) s
5 643 M
( needed to keep the data pipe full.) s
5 621 M
( Reducing the number of ACKs \(or, equivalently, increasing the amount) s
5 610 M
( of bytes acknowledged by each ACK\) can increase the burstiness of the) s
5 599 M
( TCP sender. Hence, any mechanism as those cited above should be) s
5 588 M
( coupled with a burst mitigation technique, Rate-Based Pacing, that) s
5 577 M
( paces the sending of data segments [AB05] [ASA00] [BPK97].) s
5 555 M
( Aweya et al. [AOM02] present a middlebox-based approach for) s
5 544 M
( mitigating data packet bursts and for controlling the uplink ACK) s
5 533 M
( congestion. The main idea is to perform pacing on ACK segments on an) s
5 522 M
( edge device close to the sender, so as to control the ACK arrival) s
5 511 M
( rate at the sender.) s
5 489 M
( Unlike some of the related work cited above, in this document we are) s
5 478 M
( proposing an end-to-end ACK congestion control mechanism that) s
5 467 M
( controls congestion on the reverse path \(the path followed by the ACK) s
5 456 M
( traffic\) by detecting and responding to marked or dropped ACK) s
5 445 M
( packets.) s
5 423 M
(5. Acknowledgement Congestion Control) s
5 401 M
(5.1. Negotiating the Use of ACK Congestion Control) s
5 379 M
( The TCP end-points negotiate the use of ACK Congestion Control) s
5 368 M
( \(ACKCC\) with a TCP option, the ACK-Congestion-Control-Permitted) s
5 357 M
( Option. The option number will be allocated by IANA.) s
5 335 M
( The ACK-Congestion-Control-Permitted option can only be sent on) s
5 324 M
( packets that have the SYN bit set. If TCP end-point A receives an) s
5 313 M
( ACK-Congestion-Control-Permitted option from TCP end-point B, then) s
5 302 M
( the TCP end-points MAY use ACK Congestion Control on the pure) s
5 291 M
( acknowledgements sent from B to A. This means that TCP end-point A) s
5 280 M
( MAY send ACK Ratio values to TCP end-point B, for TCP end-point B to) s
5 269 M
( use on pure acknowledgement packets.) s
5 247 M
( Similarly, if TCP end-point B receives an ACK-Congestion-Control-) s
5 236 M
( Permitted option from TCP end-point A, then the TCP end-points MAY) s
5 225 M
( use ACK Congestion Control on the pure acknowledgements sent from A) s
5 214 M
( to B.) s
5 192 M
( If TCP end-point B receives an ACK-Congestion-Control-Permitted) s
5 181 M
( option from TCP end-point A and also sent an ACK-Congestion-Control-) s
5 170 M
( Permitted option to TCP end-point A, then TCP end-point B can send) s
5 126 M
(Floyd [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
24 24 translate
/pagenum 9 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( its ACK packets as ECN-Capable.) s
5 654 M
( TCP ACK-Congestion-Control-Permitted Option:) s
5 632 M
( Kind: N) s
5 610 M
( +-----------+-----------+) s
5 599 M
( | Kind=N | Length=2 |) s
5 588 M
( +-----------+-----------+) s
5 566 M
( When ACK Congestion Control is used, the default initial ACK Ratio is) s
5 555 M
( two, with the receiver acknowledging at least every other data) s
5 544 M
( packet.) s
5 522 M
(5.2. The TCP ACK Ratio Option) s
5 500 M
( The sender uses a ACK Ratio TCP Option to communicate the ACK Ratio) s
5 489 M
( value from the sender to the receiver.) s
5 456 M
( TCP ACK Ratio Option:) s
5 434 M
( Kind: N+1) s
5 412 M
( +-----------+-----------+-----------+) s
5 401 M
( | Kind=N+1 | Length=3 | ACK Ratio |) s
5 390 M
( +-----------+-----------+-----------+) s
5 368 M
( The ACK Ratio Option is only sent on data packets. Because TCP uses) s
5 357 M
( reliable delivery for data packets, the TCP sender can tell if the) s
5 346 M
( TCP receiver has received an ACK Ratio Option.) s
5 324 M
(5.3. The Receiver: Implementing the ACK Ratio) s
5 302 M
( With an ACK Ratio of R, the receiver should send one pure ACK for) s
5 291 M
( every R newly received data packets unless the delayed ACK timer) s
5 280 M
( expires first. A receiver could simply maintain a counter that) s
5 269 M
( increments up to R for each new data packet received, and then reset) s
5 258 M
( the counter to zero when an ACK is sent, either pure or piggybacked.) s
5 236 M
( [RFC2581] recommends that the receiver SHOULD acknowledge out-of-) s
5 225 M
( order data packets immediately, sending an immediate duplicate ACK) s
5 214 M
( when it receives a data segment above a gap in the sequence space,) s
5 203 M
( and sending an immediate ACK when it receives a data segment that) s
5 192 M
( fills in all or part of a gap in the sequence space.) s
5 170 M
( When ACK Congestion Control is being used and the ACK Ratio is at) s
5 126 M
(Floyd [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
24 24 translate
/pagenum 10 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( most two, the TCP receiver MUST acknowledge each out-of-order data) s
5 676 M
( packet immediately. For an ACK Ratio greater than two, Section 5.6) s
5 665 M
( specifies in detail the receiver's behavior for sending ACKs for out-) s
5 654 M
( of-order data packets.) s
5 632 M
(5.4. The Sender: Determining Lost or Marked ACK Packets) s
5 610 M
( The TCP data sender uses its knowledge of the ACK Ratio in use by the) s
5 599 M
( receiver to infer when an ACK packet has been lost.) s
5 577 M
( Because the TCP sender knows the ACK Ratio R in use by the receiver,) s
5 566 M
( the TCP sender knows that in the absence of dropped or reordered) s
5 555 M
( acknowledgement packets, each new acknowledgement received will) s
5 544 M
( acknowledge at most R additional data packets. Thus, if the sender) s
5 533 M
( receives an acknowledgement acknowledging more than R data packets,) s
5 522 M
( and does not receive a subsequent acknowledgement acknowledging a) s
5 511 M
( strict subset \(with a smaller cumulative acknowledgement, or with the) s
5 500 M
( same cumulative acknowledgement but a strict subset of data) s
5 489 M
( acknowledged in SACK blocks\), then the sender can infer that an ACK) s
5 478 M
( packet has been dropped.) s
5 456 M
( Similarly, the TCP sender knows that in the absence of dropped or) s
5 445 M
( delayed data packets from the sender, and in the absence of delayed) s
5 434 M
( acknowledgements due to a timer expiring at the receiver, each new) s
5 423 M
( pure acknowledgement received will acknowledge at least R additional) s
5 412 M
( data packets. In terms of ACK congestion control, the TCP sender) s
5 401 M
( does not have to take any actions when it receives an acknowledgement) s
5 390 M
( acknowledging less than R additional packets.) s
5 368 M
( Out-of-order data packets: If the ACK Ratio is at most two, then the) s
5 357 M
( TCP receiver sends a dupACK for every out-of-order data packet. In) s
5 346 M
( this case, the TCP sender should be able to detect lost DupACK) s
5 335 M
( packets by counting the number of DupACKs that arrive between the) s
5 324 M
( beginning of the loss event and the arrival of the first full or) s
5 313 M
( partial ACK, and comparing this number with the number of DupACKs) s
5 302 M
( that should have arrived \(based on the number of packets being ACKed) s
5 291 M
( by the full or partial ACK\). Simulations and/or experiments will be) s
5 280 M
( needed to determine whether, in practice, it works for the TCP sender) s
5 269 M
( to assess lost ACK packets during loss events, for an ACK Ratio of at) s
5 258 M
( most two.) s
5 236 M
( If the ACK Ratio is greater than two, the TCP receiver does not send) s
5 225 M
( a dupACK for every out-of-order data packet, as specified in Section) s
5 214 M
( 5.6. For simplicity, if the ACK Ratio is greater than two, the TCP) s
5 203 M
( sender does not attempt to detect lost ACK packets during loss events) s
5 192 M
( involving forward-path data traffic. That is, as soon as the sender) s
5 181 M
( infers a packet loss for a forward-path data packet, it stops) s
5 170 M
( detection of ACK loss on the reverse path. The sender waits until a) s
5 126 M
(Floyd [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
24 24 translate
/pagenum 11 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( new cumulative acknowledgement is received that covers the) s
5 676 M
( retransmitted data, and then restarts detection of ACK loss for) s
5 665 M
( reverse-path traffic.) s
5 643 M
(5.5. The Sender: Adjusting the ACK Ratio) s
5 621 M
( The TCP sender will adjust the ACK Ratio as specified in Section) s
5 610 M
( 6.1.2 of [RFC4341], as follows.) s
5 588 M
( The ACK Ratio always meets the following three constraints.) s
5 566 M
( \(1\) The ACK Ratio is an integer.) s
5 544 M
( \(2\) The minimum ACK sending rate: The ACK Ratio does not exceed) s
5 533 M
( max\(2, cwnd/\(K*MSS\)\), rounded up, for K=2. This ensures that the TCP) s
5 522 M
( receiver sends at least two ACKs for a window of data \(for a window) s
5 511 M
( of at least four full-sized segments\).) s
5 489 M
( \(3\) If the congestion window is at least as large as four full-sized) s
5 478 M
( segments, then the ACK Ratio is at least two. In other words, an ACK) s
5 467 M
( Ratio of one is only allowed when the congestion window is at most) s
5 456 M
( three full-sized segments.) s
5 434 M
( The sender changes the ACK Ratio within those constraints as follows.) s
5 423 M
( For each congestion window of data with lost or marked ACK packets,) s
5 412 M
( the ACK Ratio R is doubled; and for each cwnd/\(MSS*\(R^2 - R\)\)) s
5 401 M
( consecutive congestion windows of data with no lost or marked ACK) s
5 390 M
( packets, the ACK Ratio is decreased by 1. \(See Appendix A of RFC) s
5 379 M
( 4341 for the derivation. Note that Appendix A of RFC 4341 assumes a) s
5 368 M
( congestion window W in packets, while we use cwnd in bytes.\) As) s
5 357 M
( stated in the previous section, when the ACK Ratio is greater than) s
5 346 M
( two the sender does not attempt to detect lost ACK packets during) s
5 335 M
( loss events for forward-path traffic.) s
5 313 M
( For a constant congestion window, these modifications to the ACK) s
5 302 M
( ratio give an ACK sending rate that is roughly TCP friendly. Of) s
5 291 M
( course, cwnd usually varies over time; the dynamics will be rather) s
5 280 M
( complex, but roughly TCP friendly. We recommend that the sender use) s
5 269 M
( the most recent value of cwnd when determining whether to decrease) s
5 258 M
( ACK Ratio by one.) s
5 236 M
( The frequency of ACK Ratio negotiations: The sender need not keep the) s
5 225 M
( ACK Ratio completely up to date. For instance, it MAY rate-limit ACK) s
5 214 M
( Ratio renegotiations to once every four or five round-trip times, or) s
5 203 M
( to once every second or two. The sender SHOULD NOT attempt to change) s
5 192 M
( the ACK Ratio more than once per round-trip time. Additionally, it) s
5 181 M
( MAY enforce a minimum ACK Ratio of two, or it MAY set ACK Ratio to) s
5 170 M
( one for half-connections with persistent congestion windows of 1 or 2) s
5 126 M
(Floyd [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
24 24 translate
/pagenum 12 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( packets.) s
5 665 M
( The minimum ACK sending rate: From rule \(2\) above, the TCP receiver) s
5 654 M
( always sends at least K=2 ACKs for a window of data, even in the face) s
5 643 M
( of very heavy congestion on the reverse path. We would note,) s
5 632 M
( however, that if congestion is sufficiently heavy, all the ack) s
5 621 M
( packets are dropped, and then the sender falls back on an) s
5 610 M
( exponentially backed-off timeout. Thus, if congestion is sufficiently) s
5 599 M
( heavy on the reverse path, then the sender reduces its sending rate) s
5 588 M
( on the forward path, which reduces the rate on the reverse path as) s
5 577 M
( well. One possibility would be to use a higher minimum ACK sending) s
5 566 M
( rate, adding a constant upper bound on the ACK Ratio. That is, if) s
5 555 M
( the ACK Ratio also had an upper bound of J, independent of cwnd, then) s
5 544 M
( the receiver would always send at least one ACK for every J data) s
5 533 M
( packets, regardless of the level of congestion on the reverse path.) s
5 500 M
(5.6. The Receiver: Sending ACKs for Out-of-Order Data Segments) s
5 478 M
( RFC 2581 says that "a TCP receiver SHOULD send an immediate duplicate) s
5 467 M
( ACK when an out-of-order segment arrives." After three duplicate) s
5 456 M
( ACKs are received, the TCP sender infers a packet loss and implements) s
5 445 M
( Fast Retransmit and Fast Recovery, retransmitting the missing packet.) s
5 434 M
( When the ACK Ratio is at most two, the TCP receiver SHOULD still send) s
5 423 M
( an immediate duplicate ACK when an out-of-order segment arrives.) s
5 401 M
( When the ACK Ratio is greater than two, the TCP receiver still SHOULD) s
5 390 M
( send an immediate duplicate ACK for each of the first three out-of-) s
5 379 M
( order segments that arrive in a reordering event. \(We define a) s
5 368 M
( reordering event at the receiver as beginning when an out-of-order) s
5 357 M
( segment arrives, and ending when the receiver holds no more out-of-) s
5 346 M
( order segments.\) However, when the ACK Ratio is greater than two,) s
5 335 M
( after the first three duplicate ACKs have been sent, the TCP receiver) s
5 324 M
( should perform ACK congestion control on the remaining ACKs to be) s
5 313 M
( sent during the current reordering event. That is, after the first) s
5 302 M
( three duplicate ACKs have been sent, the TCP receiver SHOULD send an) s
5 291 M
( ACK for every R out-of-order segments, instead of sending an ACK for) s
5 280 M
( every out-of-order segment. [We note that the Fast Recovery) s
5 269 M
( procedure of the TCP sender might have to be modified to take this) s
5 258 M
( change into account.] In addition, a receiver MUST NOT withhold an) s
5 247 M
( ACK for more than 500 ms.) s
5 225 M
(5.7. The Sender: Response to ACK Packets) s
5 203 M
( The use of a large ACK Ratio can generate line rate data bursts at a) s
5 192 M
( TCP sender. When the ACK Ratio is greater than two, the TCP sender) s
5 181 M
( SHOULD use some form of burst mitigation, or rate-based pacing for) s
5 170 M
( sending data packets in response to a single acknowledgement. The) s
5 126 M
(Floyd [Page 12]) s
_R
S
%%Page: (13) 13
%%BeginPageSetup
_S
24 24 translate
/pagenum 13 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( use of rate-based pacing will be limited by the timer granularity at) s
5 676 M
( the TCP sender.) s
5 654 M
( We note that the interaction of ACK congestion control and burst) s
5 643 M
( mitigation schemes needs further study.) s
5 621 M
( Byte counting at the sender: In addition to the impact of a large ACK) s
5 610 M
( Ratio on the burstiness of the TCP sender's sending rate, a large ACK) s
5 599 M
( Ratio can also affect the data sending rate by slowing down the) s
5 588 M
( increase of the congestion window cwnd. As specified in RFC 2581, in) s
5 577 M
( slow-start the TCP sender increases cwnd by one full-sized segment) s
5 566 M
( for each new ACK received \(in this context, a "new ACK" is an ACK) s
5 555 M
( that acknowledges new data\). RFC 2581 also specifies that in) s
5 544 M
( congestion avoidance, the TCP sender increases cwnd by roughly 1/cwnd) s
5 533 M
( full-sized segments for each ACK received, resulting in an increase) s
5 522 M
( in cwnd of roughly one full-sized segment per round-trip time. In) s
5 511 M
( this case, the use of a large ACK Ratio would slow down the increase) s
5 500 M
( of the sender's congestion window.) s
5 478 M
( RFC 2581 notes that during congestion avoidance it is also acceptable) s
5 467 M
( to count the number of bytes acknowledged by new ACKs, and to) s
5 456 M
( increase cwnd based on the number of bytes acknowledged, rather than) s
5 445 M
( on the number of new ACKs received. Thus, the sender SHOULD use this) s
5 434 M
( form of byte counting with Acknowledgement Congestion Control, so) s
5 423 M
( that the Acknowledgement Congestion Control doesn't slow down the) s
5 412 M
( window increases for the data traffic sent by the sender. Because) s
5 401 M
( rate-based pacing should be used with Acknowledgement Congestion) s
5 390 M
( Control, as recommended earlier in this section, the TCP sender MAY) s
5 379 M
( increase the congestion window by more than two MSS for each ACK.) s
5 357 M
( We note that for Appropriate Byte Counting \(ABC\) as specified in) s
5 346 M
( [RFC3465], during Slow-Start the sender is allowed to increase the) s
5 335 M
( congestion window by at most two MSS for each ACK. It has not yet) s
5 324 M
( been determined whether, with Acknowledgement Congestion Control, the) s
5 313 M
( TCP sender could use ABC during Slow-Start. If ABC is used with) s
5 302 M
( Acknowledgement Congestion Control, then when the TCP sender is in) s
5 291 M
( slow-start and the Ack Ratio is greater than two, the TCP sender MAY) s
5 280 M
( increase the congestion window by more that two MSS in response to a) s
5 269 M
( single ACK.) s
5 247 M
( Inferring lost data packets: As cited earlier, RFC 2581 infers that a) s
5 236 M
( packet has been lost after it receives three duplicate) s
5 225 M
( acknowledgements. Because ACK Congestion Control is only used when) s
5 214 M
( there is congestion on the reverse path, after a packet loss one or) s
5 203 M
( more of the three duplicate ACKs sent by the receiver could be lost) s
5 192 M
( on the reverse path, and the receiver might wait until it has) s
5 181 M
( received R more out-of-order segments before sending the next) s
5 170 M
( duplicate ACK. All this could slow down Fast Recovery and Fast) s
5 126 M
(Floyd [Page 13]) s
_R
S
%%Page: (14) 14
%%BeginPageSetup
_S
24 24 translate
/pagenum 14 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( Retransmit quite a bit. To reduce the potential delay in detecting a) s
5 676 M
( lost packet, we add that when SACK is used, a TCP sender SHOULD use) s
5 665 M
( the information in the SACK option to detect when the receiver has) s
5 654 M
( received at least three out-of-order data packets, and to initiate) s
5 643 M
( Fast Retransmit and Fast Recovery in this case, even if the TCP) s
5 632 M
( sender has not yet received three dup ACKs.) s
5 610 M
(5.8. Possible Additions: Receiver Bounds on the Ack Ratio) s
5 588 M
( It has been suggested that in some environments, the TCP receiver) s
5 577 M
( might want to set lower bounds on the ACK Ratio. For example, the) s
5 566 M
( TCP receiver might know from configuration or from past experience) s
5 555 M
( that the bandwidth on the return path is limited, and might want to) s
5 544 M
( set a lower bound \(greater than two\) on the ACK Ratio R. If this is) s
5 533 M
( included, this would require a TCP Option from the TCP receiver to) s
5 522 M
( the TCP sender reporting the lower bound on the ACK Ratio. Care) s
5 511 M
( would also be needed so that the lower bound on the ACK Ratio was) s
5 500 M
( only in effect when the TCP sender's congestion window was) s
5 489 M
( sufficiently high.) s
5 456 M
(6. Possible Complications) s
5 434 M
(6.1. Possible Complications: Delayed Acknowledgements) s
5 412 M
( The receiver could send a delayed acknowledgement acknowledging a) s
5 401 M
( single packet, even when the ACK Ratio is two or more.) s
5 379 M
( This should not cause false positives \(when the TCP sender infers a) s
5 368 M
( loss when no loss happened\). The TCP sender only infers that a pure) s
5 357 M
( ACK packet has been lost when no data packet has been lost, and an) s
5 346 M
( ACK packet arrives acknowledging more than R new packets.) s
5 324 M
( Delayed acknowledgements could, however, cause false negatives, with) s
5 313 M
( the TCP sender unable to detect the loss of an ack packet sent as a) s
5 302 M
( delayed acknowedgement. False negatives seem acceptable; this would) s
5 291 M
( result in approximate ACK congestion control, which would be better) s
5 280 M
( than no ACK congestion control at all. In particular, when this form) s
5 269 M
( of false negative occurs, it is because the receiver is sending) s
5 258 M
( acknowledgements at such a low rate that it is sending delayed) s
5 247 M
( acknowledgements, rather than acknowledging at least R data packets) s
5 236 M
( with each acknowledgement.) s
5 214 M
(6.2. Possible Complications: Duplicate Acknowledgements.) s
5 192 M
( As discussed in Section 5.3, RFC 2581 states that "a TCP receiver) s
5 181 M
( SHOULD send an immediate duplicate ACK when an out-of-order segment) s
5 170 M
( arrives," and that "a TCP receiver SHOULD send an immediate ACK when) s
5 126 M
(Floyd [Page 14]) s
_R
S
%%Page: (15) 15
%%BeginPageSetup
_S
24 24 translate
/pagenum 15 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( the incoming segment fills in all or part of a gap in the sequence) s
5 676 M
( space" [RFC2581]. When ACK Congestion Control is used, the TCP) s
5 665 M
( receiver instead uses the guidelines from Section 5.6 to govern the) s
5 654 M
( sending of duplicate ACKs. More work would be useful to evaluate the) s
5 643 M
( advantages and disadvantages of this approach in terms of the) s
5 632 M
( potential delay in triggering Fast Retransmit, and to explore) s
5 621 M
( alternate possibilities.) s
5 599 M
(6.3. Possible Complications: Two-Way Traffic.) s
5 577 M
( In a TCP connection with two-way traffic, the receiver could send) s
5 566 M
( some pure ACK packets, and some acknowledgements piggy-backed on data) s
5 555 M
( packets. In this case, how well can the TCP sender infer when pure) s
5 544 M
( ACK packets have been lost? The receiver would still follow the rule) s
5 533 M
( of only sending a pure ACK packet when there is a need for a delayed) s
5 522 M
( ack, or there are R new data packets to acknowledge.) s
5 500 M
(6.4. Possible Complications: Reordering of ACK Packets.) s
5 478 M
( It is possible for ACK packets to be reordered on the reverse path.) s
5 467 M
( The TCP sender could either use a parallel mechanism to the dupACK) s
5 456 M
( threshold to infer when an ACK packet has been lost, as with TCP, or,) s
5 445 M
( more robustly, the TCP sender could wait an entire round-trip time) s
5 434 M
( before inferring that an ACK packet has been lost [RFC4653].) s
5 412 M
(6.5. Possible Complications: Abrupt Changes in the ACK Path.) s
5 390 M
( What happens when there are abrupt changes in the reverse path, such) s
5 379 M
( as from vertical handovers? Can there be any problems that would be) s
5 368 M
( worse than those experienced by a TCP connection that is not using) s
5 357 M
( ACK congestion control?) s
5 335 M
(6.6. Possible Complications: Corruption.) s
5 313 M
( As with data packets, it is possible for ACK packets to be dropped in) s
5 302 M
( the network due to corruption rather than congestion. The current) s
5 291 M
( assumption of ACK congestion control is that all losses should be) s
5 280 M
( taken as indications of congestion. When there is some better answer) s
5 269 M
( for corrupted TCP data packets, the same solution hopefully would) s
5 258 M
( apply to corrupted ACK packets as well.) s
5 236 M
(6.7. Possible Complications: ACKs That Don't Contribute to Congestion.) s
5 214 M
( It is posssible for the ACK packets in a TCP connection to traverse a) s
5 203 M
( congested path where ACK packets are dropped, but where the ACK) s
5 192 M
( packets themselves don't significantly contribute to the congestion) s
5 181 M
( on the path. In scenarios where ACK packets are dropped but where) s
5 170 M
( ACK traffic doesn't make a significant contribution of the congestion) s
5 126 M
(Floyd [Page 15]) s
_R
S
%%Page: (16) 16
%%BeginPageSetup
_S
24 24 translate
/pagenum 16 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( on the path, the use of ACK Congestion Control would not contribute) s
5 676 M
( to reducing the aggregate congestion on the path. In this case, one) s
5 665 M
( goal is to minimize the negative impact of ACK Congestion Control on) s
5 654 M
( the overall performance of the TCP connection.) s
5 610 M
( J TCP conns. link L -> J TCP conns.) s
5 599 M
( data -> |---| |---| <- acks) s
5 588 M
( <-------------> | | | | <------------->) s
5 577 M
( | | <-------------> | |) s
5 566 M
( <-------------> | | | | <------------->) s
5 555 M
( K TCP conns. |---| |---| K TCP conns.) s
5 544 M
( acks -> <- link L1 <- data) s
5 522 M
( A scenario with J forward and K reverse TCP connections.) s
5 500 M
( To explore the relative contribution of ACK traffic on congestion, it) s
5 489 M
( is useful to consider a simple scenario with a congested) s
5 478 M
( unidirectional link L carrying data traffic from J TCP connections) s
5 467 M
( \(the forward TCP connections\) and ACK traffic from K TCP connections) s
5 456 M
( \(the reverse TCP connections. We assume that all TCP connections) s
5 445 M
( have the same round-trip time R and the same data packet size S of) s
5 434 M
( 1500 bytes. We further assume that all of the forward TCP) s
5 423 M
( connections have the same data packet drop rate p and the same) s
5 412 M
( congestion window W, and that all of the reverse TCP connections have) s
5 401 M
( the same congestion window W1 and the same ACK packet drop rate p1.) s
5 390 M
( The J TCP connections each use a bandwidth on link L of 1500*W/R) s
5 379 M
( bytes per second, and the K TCP connections, without ACK Congestion) s
5 368 M
( Control, each use an bandwidth on link L of 40*\(W1/2\)/R bytes per) s
5 357 M
( second. This gives a ratio of 75*\(J/K\)*\(W/W1\) for TCP data bandwidth) s
5 346 M
( to TCP ACK bandwidth on link L. The ratio J/K is the ratio between) s
5 335 M
( the number of forward and reverse TCP connections on link L, and) s
5 324 M
( could have a wide range of values \(e.g., large for an access link) s
5 313 M
( from a web server, and small for an access link to a web server\).) s
5 302 M
( For this scenario, the ratio W/W1 is largely a function of the) s
5 291 M
( different levels of congestion on the forward and reverse paths.) s
5 269 M
( To explore the possibilities, we will consider some of the range of) s
5 258 M
( congestion control mechanisms for the congested link. First, we) s
5 247 M
( consider scenarios where the limitation on the congested path is in) s
5 236 M
( the link bandwidth in bytes per second.) s
5 214 M
( Cases \(1\), \(2\), \(3\), \(5\), and \(7\) below represent the best scenarios) s
5 203 M
( for ACK Congestion Control, where the fraction of packet drops for) s
5 192 M
( TCP ACK packets roughly matchs the TCP ACK packets' contribution to) s
5 181 M
( congestion. [In several of these cases this is at best a rough match) s
5 170 M
( because the data packets are a factor in the bandwidth and in the) s
5 126 M
(Floyd [Page 16]) s
_R
S
%%Page: (17) 17
%%BeginPageSetup
_S
24 24 translate
/pagenum 17 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( queue limitations, while the TCP ACK packets are only a factor in the) s
5 676 M
( queue limitations.] Cases \(4\) and \(8\) below represent problematic) s
5 665 M
( scenarios where the fraction of packet drops for TCP ACK packets is) s
5 654 M
( much higher than the TCP ACK packets' contribution to congestion.) s
5 643 M
( Case \(6\) below represents scenarios where ACK Congestion Control) s
5 632 M
( would not be effective because it would not be invoked. In the) s
5 621 M
( scenarios in case \(6\), the fraction of packet drops for TCP ACK) s
5 610 M
( packets would be much smaller than the TCP ACK packets' contribution) s
5 599 M
( to congestion.) s
5 577 M
( \(1\) The Drop-Tail queue for link L is measured in packets. In this) s
5 566 M
( case, the congested queue can accomodate N packets, regardless of) s
5 555 M
( packet size, there is a limitation of both bandwidth in bytes per) s
5 544 M
( second and also in queue space in packets, and large data packets and) s
5 533 M
( small TCP ACK packets should see similar packet drop rates. Although) s
5 522 M
( TCP ACK packets most likely aren't a major factor in the bandwidth) s
5 511 M
( limitation, they can be a significant contribution to the limitation) s
5 500 M
( of queue space. So, while the drop rate for ACK packets could be) s
5 489 M
( high in times of congestion, the ACK packets are contributing to that) s
5 478 M
( congestion somewhat by using scarce buffer space.) s
5 456 M
( \(2\) The Drop-Tail queue is measured in bytes. In this case, the) s
5 445 M
( congested queue can accomodate M bytes of packets, and TCP ACK) s
5 434 M
( packets don't make a significant contribution to either the bandwidth) s
5 423 M
( limitation or to the limitation in queue space. It is also the case) s
5 412 M
( that in this scenario, even if there is heavy congestion, the drop) s
5 401 M
( rate for TCP ACK packets should be small \(because small ACK packets) s
5 390 M
( can often find space on the congested queue when large data packets) s
5 379 M
( can't find space\). In this case, ACK Congestion Control should not) s
5 368 M
( present any problems; the TCP ACK packets aren't contributing) s
5 357 M
( significantly to congestion, and aren't experiencing significant) s
5 346 M
( packet drop rates.) s
5 324 M
( \(3\) The RED queue is in packet mode, and is measured in packets.) s
5 313 M
( This is similar to case \(1\) above. Because the queue is measured in) s
5 302 M
( packets, small TCP ACK packets contribute to the limitation in queue) s
5 291 M
( space, but not to the limitation in link bandwidth. Because the) s
5 280 M
( queue is in packet mode, large data packets and small TCP ACK packets) s
5 269 M
( should see similar packet drop rates.) s
5 247 M
( \(4\) The RED queue is in packet mode, but is measured in bytes.) s
5 236 M
( Because the queue is measured in bytes, small TCP ACK packets don't) s
5 225 M
( contribute significantly to either the limitation in queue space or) s
5 214 M
( to the limitation in link bandwidth. Because the queue is in packet) s
5 203 M
( mode, large data packets and small TCP ACK packets should see similar) s
5 192 M
( packet drop rates. If it existed, this case would be problematic,) s
5 181 M
( because the TCP ACK packets would not be contributing significantly) s
5 170 M
( to the congestion, but they would see a similar drop rate as the) s
5 126 M
(Floyd [Page 17]) s
_R
S
%%Page: (18) 18
%%BeginPageSetup
_S
24 24 translate
/pagenum 18 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( large data packets that are contributing to congestion.) s
5 665 M
( \(5\) The RED queue is in byte mode, and is measured in bytes. This is) s
5 654 M
( similar to case \(2\) above. Because the queue is measured in bytes,) s
5 643 M
( small TCP ACK packets don't contribute significantly to either the) s
5 632 M
( limitation in queue space or to the limitation in link bandwidth. At) s
5 621 M
( the same time, because the queue is in byte mode, small TCP ACK) s
5 610 M
( packets see much smaller packet drop rates that those of large data) s
5 599 M
( packets.) s
5 577 M
( \(6\) The RED queue is in byte mode, but is measured in packets.) s
5 566 M
( Because the queue is measured in packets, small TCP ACK packets) s
5 555 M
( contribute to the limitation in queue space, but not to the) s
5 544 M
( limitation in link bandwidth. Because the queue is in byte mode,) s
5 533 M
( small TCP ACK packets see much smaller packet drop rates that those) s
5 522 M
( of large data packets. If this case existed, TCP ACK packets would) s
5 511 M
( contribute somewhat to congestion, but would see a much smaller) s
5 500 M
( packet drop rate than that of large data packets.) s
5 478 M
( Next, we consider scenarios where the limitation on the congested) s
5 467 M
( link is in CPU cycles at the router in packets per second, not in) s
5 456 M
( bandwidth in bytes per second.) s
5 434 M
( \(7\) The CPU load imposed by TCP ACK packets is similar to the load) s
5 423 M
( imposed by other packets \(e.g., TCP data packets\). ACK Congestion) s
5 412 M
( Control would be useful in this scenario, particularly if TCP ACK) s
5 401 M
( packets saw the same packet drop rates as TCP data packets.) s
5 379 M
( \(8\) The CPU load imposed by TCP ACK packets is much less than the) s
5 368 M
( load imposed by other packets \(e.g., TCP data packets\). If TCP ACK) s
5 357 M
( packets saw a smaller packet drop rate than TCP data packets, then) s
5 346 M
( the TCP ACK packet drop rate would roughly match the TCP ACK packets') s
5 335 M
( contribution to congestion, and this would be good. If TCP ACK) s
5 324 M
( packets saw the same packet drop rate as TCP data packets, this this) s
5 313 M
( case would be problematic, because the TCP ACK packets would not be) s
5 302 M
( contributing significantly to the congestion, but they would see a) s
5 291 M
( similar drop rate as the large data packets that are contributing to) s
5 280 M
( congestion.) s
5 258 M
(6.8. Other Issues) s
5 236 M
( Are there any problems caused by the combination of two-way traffic) s
5 225 M
( and reordering?) s
5 203 M
( How well would ACK congestion control work without SACK information?) s
5 192 M
( Or shwould SACK be required with ACK congestion control?) s
5 126 M
(Floyd [Page 18]) s
_R
S
%%Page: (19) 19
%%BeginPageSetup
_S
24 24 translate
/pagenum 19 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
(7. Evaluating ACK Congestion Control) s
5 665 M
( Evaluating ACK Congestion Control will have two components: \(1\)) s
5 654 M
( evaluating the effects of ACK Congestion Control on an individual TCP) s
5 643 M
( connection; and \(2\) evaluating the effects of ACK Congestion Control) s
5 632 M
( on aggregate traffic \(including the effects of ACK Congestion Control) s
5 621 M
( on the aggregate congestion of the path\).) s
5 599 M
( The first part, evaluating ACK Congestion Control on the performance) s
5 588 M
( of an individual TCP connection, will have to examine those scenarios) s
5 577 M
( where ACK Congestion Control might help the performance of a TCP) s
5 566 M
( connection, and those scenarios where the use of ACK Congestion) s
5 555 M
( Control might cause problems.) s
5 533 M
( The second part, evaluating the effects of ACK Congestion Control on) s
5 522 M
( aggregate traffic, should consider scenarios where the use of ACK) s
5 511 M
( Congestion Control helps all of the connections sharing a path by) s
5 500 M
( reducing the aggregate congestion on the path. This part should also) s
5 489 M
( see if there are scenarios where ACK Congestion Control causes) s
5 478 M
( problems by increasing the burstiness of aggregate traffic, or by) s
5 467 M
( otherwise changing traffic dynamics.) s
5 445 M
(8. Measurements of ACK Traffic and Congestion) s
5 423 M
( There are a number of studies about the traffic composition on) s
5 412 M
( various links in the Internet, reporting the fraction of bandwidth) s
5 401 M
( used by TCP data and by TCP ACK traffic. [Pointers to be added.]) s
5 379 M
( Are there any studies that show the relative drop rates for TCP data) s
5 368 M
( and ACK traffic, for particular links or for particular TCP) s
5 357 M
( connections?) s
5 335 M
( Are there any studies of congested links that show the fraction of) s
5 324 M
( traffic on the congested link, or in the congested queue, that) s
5 313 M
( consist of TCP ACK packets?) s
5 291 M
(9. Acknowledgement Congestion Control in CCID 2) s
5 269 M
( Rate-based pacing: For CCID 2, RFC 4341 says that "senders MAY use a) s
5 258 M
( form of rate-based pacing when sending multiple data packets) s
5 247 M
( liberated by a single ACK packet, rather than sending all liberated) s
5 236 M
( data packets in a single burst." However, rate-based pacing is not) s
5 225 M
( required in CCID 2.) s
5 203 M
( Increasing the congestion window: For CCID 2, RFC 4341 says that) s
5 192 M
( "when cwnd < ssthresh, meaning that the sender is in slow-start, the) s
5 181 M
( congestion window is increased by one packet for every two newly) s
5 170 M
( acknowledged data packets with ACK Vector State 0 \(not ECN-marked\),) s
5 126 M
(Floyd [Page 19]) s
_R
S
%%Page: (20) 20
%%BeginPageSetup
_S
24 24 translate
/pagenum 20 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( up to a maximum of ACK Ratio/2 packets per acknowledgement. This is) s
5 676 M
( a modified form of Appropriate Byte Counting [RFC3465] that is) s
5 665 M
( consistent with TCP's current standard \(which does not include byte) s
5 654 M
( counting\), but allows CCID 2 to increase as aggressively as TCP when) s
5 643 M
( CCID 2's ACK Ratio is greater than the default value of two. When) s
5 632 M
( cwnd >= ssthresh, the congestion window is increased by one packet) s
5 621 M
( for every window of data acknowledged without lost or marked) s
5 610 M
( packets.") s
5 577 M
(10. Security Considerations) s
5 555 M
( What are the sender's incentives to cheat on ACK congestion control?) s
5 544 M
( What are the receiver's incentives to cheat? What are the avenues) s
5 533 M
( open for cheating?) s
5 511 M
( As long as ACK congestion control is optional, neither host can be) s
5 500 M
( forced to use ACK congestion control if it doesn't want to. So ACK) s
5 489 M
( congestion control will only be used if the sender or receiver have) s
5 478 M
( some chance of receiving some benefit.) s
5 456 M
( As long as ACK congestion control is optional for TCP, there is) s
5 445 M
( little incentive for the TCP end nodes to cheat on non-ECN-based ACK) s
5 434 M
( congestion control. There is nothing now that requires TCP hosts to) s
5 423 M
( use congestion control in response to dropped ACK packets.) s
5 401 M
( What avenues for cheating are opened by the use of ECN-Capable ACK) s
5 390 M
( packets? If the end nodes can use ECN to have ACK packets marked) s
5 379 M
( rather than dropped, and if the end nodes can then avoid the use of) s
5 368 M
( ACK congestion control that goes along with the use of ECN on ACK) s
5 357 M
( packets, then the end nodes could have an incentive to cheat.) s
5 346 M
( Senders could cheat by not instructing the receiver to use a higher) s
5 335 M
( ACK Ratio; the receiver would have a hard time detecting this) s
5 324 M
( cheating. Receivers could cheat by not using the ACK Ratio they were) s
5 313 M
( instructed to use, but senders could easily detect this cheating.) s
5 302 M
( However, receivers could also cheat by not using ACK congestion) s
5 291 M
( control and still sending ACK packets as ECN-capable, so ACK) s
5 280 M
( congestion control is not a necessary component for receivers to) s
5 269 M
( cheat about sending ECN-capable ACK packets. One question would be) s
5 258 M
( whether there is any way for receivers to cheat about sending ECN-) s
5 247 M
( Capable ACK packets and not using appropriate ACK congestion control) s
5 236 M
( without this cheating being easily detected by the sender.) s
5 214 M
( What about the ability of routers or middleboxes to detect TCP) s
5 203 M
( receivers that cheat by inappropriately sending ACK packets as ECN-) s
5 192 M
( capable? The router will only know if the receiver is authorized to) s
5 181 M
( send ACK packets as ECN-Capable if it monitored both the SYN and) s
5 170 M
( SYN/ACK packets \(and was able to read the TCP options in the packet) s
5 126 M
(Floyd [Page 20]) s
_R
S
%%Page: (21) 21
%%BeginPageSetup
_S
24 24 translate
/pagenum 21 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( headers\). If ACK congestion control has been negotiated, the router) s
5 676 M
( will only know if ACK congestion control is being used correctly by) s
5 665 M
( the receiver if it can monitor the ACK Ratio options sent from the) s
5 654 M
( sender to the receiver. If ACK congestion control is being used, the) s
5 643 M
( router will not necessarily be able to tell if ACK congestion control) s
5 632 M
( is being used correctly by the sender, because drops of ACK packets) s
5 621 M
( might be occurring after the ACK packets have left the router.) s
5 610 M
( However, if the router sees the ACK Ratio options sent from the) s
5 599 M
( sender, the router will be able to tell if the sender is correctly) s
5 588 M
( accounting for those ACK packets that are dropped or ECN-marked on) s
5 577 M
( the path from the receiver to the router.) s
5 544 M
(11. IANA Considerations) s
5 522 M
( IANA will allocate the option numbers for the two TCP options, the) s
5 511 M
( ACK-Congestion-Control-Permitted Option, and the ACK Ratio Option.) s
5 489 M
(12. Conclusions) s
5 467 M
(13. Acknowledgements) s
5 445 M
( Many thanks for feedback from Mark Allman, Armando Caro, and Michael) s
5 434 M
( Welzl, and for contributed text from Michael Welzl.) s
5 412 M
(Normative References) s
5 390 M
( [RFC2119] S. Bradner, Key Words For Use in RFCs to Indicate) s
5 379 M
( Requirement Levels, RFC 2119.) s
5 357 M
( [RFC2581] Allman, M., V. Paxson, and W. Stevens, "TCP Congestion) s
5 346 M
( Control", RFC 2581, April 1999.) s
5 324 M
( [RFC3465] Allman, M., TCP Congestion Control with Appropriate) s
5 313 M
( Byte Counting \(ABC\), RFC 3465, Experimental, February) s
5 302 M
( 2003.) s
5 280 M
( [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram) s
5 269 M
( Congestion Control Protocol \(DCCP\)", RFC 4340, March) s
5 258 M
( 2006.) s
5 236 M
( [RFC4341] Floyd, S., and E. Kohler, Profile for Datagram) s
5 225 M
( Congestion Control Protocol \(DCCP\) Congestion Control) s
5 214 M
( ID 2: TCP-like Congestion Control, RFC 4341, March) s
5 203 M
( 2006.) s
5 126 M
(Floyd [Page 21]) s
_R
S
%%Page: (22) 22
%%BeginPageSetup
_S
24 24 translate
/pagenum 22 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
(Informative References) s
5 665 M
( [RFC3168] K. Ramakrishnan, S. Floyd and D. Black. The Addition) s
5 654 M
( of Explicit Congestion Notification \(ECN\) to IP. RFC) s
5 643 M
( 3168, September 2001.) s
5 621 M
( [RFC4653] S. Bhandarkar, A. L. N. Reddy, M. Allman and E.) s
5 610 M
( Blanton, Improving the Robustness of TCP to Non-) s
5 599 M
( Congestion Events, RFC 4653, August 2006.) s
5 577 M
( [ASA00] A. Aggarwal, S. Savage, and T. Anderson. Understanding) s
5 566 M
( the Performance of TCP Pacing. In INFOCOM \(3\), pages) s
5 555 M
( 11571165, 2000.) s
5 533 M
( [AB05] M. Allman and E. Blanton. Notes on Burst Mitigation) s
5 522 M
( for Transport Protocols. SIGCOMM Comput. Commun. Rev.,) s
5 511 M
( 35\(2\):5360, 2005.) s
5 489 M
( [AOM02] J. Aweya, M. Ouellette, and D. Y. Montuno. A Self-) s
5 478 M
( regulating TCP Acknowledgement \(ack\) Pacing Scheme.) s
5 467 M
( Int. J. Netw. Manag., 12\(3\):145163, 2002.) s
5 445 M
( [BPK97] Balakrishnan, H., V. Padmanabhan, and Katz, R., The) s
5 434 M
( Effects of Asymmetry on TCP Performance, Third) s
5 423 M
( ACM/IEEE Mobicom Conference, September 1997.) s
5 401 M
( [BGG+07] D.K. Blandford, S.A. Goldman, S. Gorinsky, Y. Zhou,) s
5 390 M
( and D.R. Dooly. Smartacking: Improving TCP) s
5 379 M
( Performance from the Receiving End. Journal of) s
5 368 M
( Internet Engineering, 1\(1\), 2007.) s
5 346 M
( [TJW00] I. Tam Ming-Chit, D. Jinsong and W. Wang. Improving) s
5 335 M
( TCP Performance Over Asymmetric Networks. ACM SIGCOMM) s
5 324 M
( Computer Communication Review, 30\(3\), July 2000.) s
5 302 M
( [YMH03] L. Yu, Y. Minhua, and Z. Huimin. The Improvement of) s
5 291 M
( TCP Performance in Bandwidth Asymmetric Network. IEEE) s
5 280 M
( PIMRC, 1:482-486, September 2003.) s
5 247 M
(Authors' Addresses) s
5 126 M
(Floyd [Page 22]) s
_R
S
%%Page: (23) 23
%%BeginPageSetup
_S
24 24 translate
/pagenum 23 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( Sally Floyd) s
5 676 M
( ICSI Center for Internet Research) s
5 665 M
( 1947 Center Street, Suite 600) s
5 654 M
( Berkeley, CA 94704) s
5 643 M
( USA) s
5 621 M
( EMail: floyd <at> icir <dot> org) s
5 599 M
( Andres Arcia) s
5 588 M
( Networking, Security & Multimedia \(RSM\) Dpt.) s
5 577 M
( GET / ENST Bretagne) s
5 566 M
( Rue de la Chataigneraie, CS 17607) s
5 555 M
( 35576 Cesson Sevigne Cedex) s
5 544 M
( France) s
5 522 M
( Email: AE <dot> ARCIA <at> enst-bretagne <dot> fr) s
5 500 M
( Janardhan R. Iyengar) s
5 489 M
( Connecticut College) s
5 478 M
( 270 Mohegan Avenue) s
5 467 M
( New London, CT 06320) s
5 456 M
( USA) s
5 434 M
( Email: iyengar <at> conncoll <dot> edu) s
5 401 M
( David Ros) s
5 390 M
( Networking, Security & Multimedia \(RSM\) Dpt.) s
5 379 M
( GET / ENST Bretagne) s
5 368 M
( Rue de la Chataigneraie, CS 17607) s
5 357 M
( 35576 Cesson Sevigne Cedex) s
5 346 M
( France) s
5 324 M
( Email: David <dot> Ros <at> enst-bretagne <dot> fr) s
5 291 M
(Full Copyright Statement) s
5 269 M
( Copyright \(C\) The IETF Trust \(2007\).) s
5 247 M
( This document is subject to the rights, licenses and restrictions) s
5 236 M
( contained in BCP 78, and except as set forth therein, the authors) s
5 225 M
( retain all their rights.) s
5 203 M
( This document and the information contained herein are provided on an) s
5 192 M
( "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS) s
5 181 M
( OR IS SPONSORED BY \(IF ANY\), THE INTERNET SOCIETY, THE IETF TRUST AND) s
5 170 M
( THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS) s
5 126 M
(Floyd [Page 23]) s
_R
S
%%Page: (24) 24
%%BeginPageSetup
_S
24 24 translate
/pagenum 24 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
5 720 M
(INTERNET-DRAFT TCPM - ACK CONGESTION CONTROL June 2007) s
5 687 M
( OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF) s
5 676 M
( THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED) s
5 665 M
( WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.) s
5 643 M
(Intellectual Property) s
5 621 M
( The IETF takes no position regarding the validity or scope of any) s
5 610 M
( Intellectual Property Rights or other rights that might be claimed to) s
5 599 M
( pertain to the implementation or use of the technology described in) s
5 588 M
( this document or the extent to which any license under such rights) s
5 577 M
( might or might not be available; nor does it represent that it has) s
5 566 M
( made any independent effort to identify any such rights. Information) s
5 555 M
( on the procedures with respect to rights in RFC documents can be) s
5 544 M
( found in BCP 78 and BCP 79.) s
5 522 M
( Copies of IPR disclosures made to the IETF Secretariat and any) s
5 511 M
( assurances of licenses to be made available, or the result of an) s
5 500 M
( attempt made to obtain a general license or permission for the use of) s
5 489 M
( such proprietary rights by implementers or users of this) s
5 478 M
( specification can be obtained from the IETF on-line IPR repository at) s
5 467 M
( http://www.ietf.org/ipr.) s
5 445 M
( The IETF invites any interested party to bring to its attention any) s
5 434 M
( copyrights, patents or patent applications, or other proprietary) s
5 423 M
( rights that may cover technology that may be required to implement) s
5 412 M
( this standard. Please address the information to the IETF at ietf-) s
5 401 M
( ipr@ietf.org.) s
5 126 M
(Floyd [Page 24]) s
_R
S
%%Page: (25) 25
%%BeginPageSetup
_S
24 24 translate
/pagenum 25 def
/fname (draft-floyd-tcpm-ackcc-01.txt) def
/fdir () def
/ftail (draft-floyd-tcpm-ackcc-01.txt) def
/user_header_p false def
%%EndPageSetup
_R
S
%%Trailer
%%Pages: 25
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-22 21:59:51 |