1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
|
<pre>Network Working Group G. Fairhurst
Request for Comments: 5634 A. Sathiaseelan
Category: Experimental University of Aberdeen
August 2009
<span class="h1">Quick-Start for the Datagram Congestion Control Protocol (DCCP)</span>
Abstract
This document specifies the use of the Quick-Start mechanism by the
Datagram Congestion Control Protocol (DCCP). DCCP is a transport
protocol that allows the transmission of congestion-controlled,
unreliable datagrams. DCCP is intended for applications such as
streaming media, Internet telephony, and online games. In DCCP, an
application has a choice of congestion control mechanisms, each
specified by a Congestion Control Identifier (CCID). This document
specifies general procedures applicable to all DCCP CCIDs and
specific procedures for the use of Quick-Start with DCCP CCID 2, CCID
3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with
Quick-Start routers along the end-to-end path to determine an allowed
sending rate at the start of a connection and, at times, in the
middle of a DCCP connection (e.g., after an idle or application-
limited period). The present specification is provided for use in
controlled environments, and not as a mechanism that would be
intended or appropriate for ubiquitous deployment in the global
Internet.
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Quick-Start for DCCP ............................................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Sending a Quick-Start Request for a DCCP Flow ..............<a href="#page-5">5</a>
<a href="#section-2.1.1">2.1.1</a>. The Quick-Start Interval ............................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Receiving a Quick-Start Request for a DCCP Flow ............<a href="#page-6">6</a>
<a href="#section-2.2.1">2.2.1</a>. The Quick-Start Response Option .....................<a href="#page-7">7</a>
<a href="#section-2.3">2.3</a>. Receiving a Quick-Start Response ...........................<a href="#page-8">8</a>
<a href="#section-2.3.1">2.3.1</a>. The Quick-Start Mode ................................<a href="#page-8">8</a>
<a href="#section-2.3.2">2.3.2</a>. The Quick-Start Validation Phase ....................<a href="#page-9">9</a>
<a href="#section-2.4">2.4</a>. Procedure When No Response to a Quick-Start Request .......<a href="#page-10">10</a>
2.5. Procedure When a Packet Is Dropped While Using
Quick-Start ...............................................<a href="#page-11">11</a>
<a href="#section-2.6">2.6</a>. Interactions with Mobility and Signaled Path Changes ......<a href="#page-11">11</a>
<a href="#section-2.7">2.7</a>. Interactions with Path MTU Discovery ......................<a href="#page-12">12</a>
<a href="#section-2.8">2.8</a>. Interactions with Middleboxes .............................<a href="#page-12">12</a>
<a href="#section-3">3</a>. Mechanisms for Specific CCIDs ..................................<a href="#page-13">13</a>
<a href="#section-3.1">3.1</a>. Quick-Start for CCID 2 ....................................<a href="#page-13">13</a>
<a href="#section-3.1.1">3.1.1</a>. The Quick-Start Request for CCID 2 .................<a href="#page-13">13</a>
<a href="#section-3.1.2">3.1.2</a>. Sending a Quick-Start Response with CCID 2 .........<a href="#page-13">13</a>
<a href="#section-3.1.3">3.1.3</a>. Using the Quick-Start Response with CCID 2 .........<a href="#page-13">13</a>
<a href="#section-3.1.4">3.1.4</a>. Quick-Start Validation Phase for CCID 2 ............<a href="#page-14">14</a>
3.1.5. Reported Loss or Congestion While Using
Quick-Start ........................................<a href="#page-14">14</a>
<a href="#section-3.1.6">3.1.6</a>. CCID 2 Feedback Traffic on the Reverse Path ........<a href="#page-15">15</a>
<a href="#section-3.2">3.2</a>. Quick-Start for CCID 3 ....................................<a href="#page-15">15</a>
<a href="#section-3.2.1">3.2.1</a>. The Quick-Start Request for CCID 3 .................<a href="#page-15">15</a>
<a href="#section-3.2.2">3.2.2</a>. Sending a Quick-Start Response with CCID 3 .........<a href="#page-15">15</a>
<a href="#section-3.2.3">3.2.3</a>. Using the Quick-Start Response with CCID 3 .........<a href="#page-16">16</a>
<a href="#section-3.2.4">3.2.4</a>. Quick-Start Validation Phase for CCID 3 ............<a href="#page-17">17</a>
3.2.5. Reported Loss or Congestion during the
Quick-Start Mode or Validation Phase ...............<a href="#page-17">17</a>
<a href="#section-3.2.6">3.2.6</a>. CCID 3 Feedback Traffic on the Reverse Path ........<a href="#page-18">18</a>
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<a href="#section-3.3">3.3</a>. Quick-Start for CCID 4 ....................................<a href="#page-18">18</a>
<a href="#section-3.3.1">3.3.1</a>. The Quick-Start Request for CCID 4 .................<a href="#page-18">18</a>
<a href="#section-3.3.2">3.3.2</a>. Sending a Quick-Start Response with CCID 4 .........<a href="#page-18">18</a>
<a href="#section-3.3.3">3.3.3</a>. Using the Quick-Start Response with CCID 4 .........<a href="#page-18">18</a>
3.3.4. Reported Loss or Congestion While Using
Quick-Start ........................................<a href="#page-19">19</a>
<a href="#section-3.3.5">3.3.5</a>. CCID 4 Feedback Traffic on the Reverse Path ........<a href="#page-19">19</a>
<a href="#section-4">4</a>. Discussion of Issues ...........................................<a href="#page-19">19</a>
<a href="#section-4.1">4.1</a>. Overrun and the Quick-Start Validation Phase ..............<a href="#page-19">19</a>
<a href="#section-4.2">4.2</a>. Experimental Status .......................................<a href="#page-19">19</a>
<a href="#section-5">5</a>. IANA Considerations ............................................<a href="#page-20">20</a>
<a href="#section-6">6</a>. Acknowledgments ................................................<a href="#page-20">20</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-21">21</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-21">21</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-21">21</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Datagram Congestion Control Protocol (DCCP) [<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>] is a
transport protocol for congestion-controlled, unreliable datagrams,
intended for applications such as streaming media, Internet
telephony, and online games.
In DCCP, an application has a choice of congestion control
mechanisms, each specified by a Congestion Control Identifier (CCID)
[<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>]. There are general procedures applicable to all DCCP CCIDs
that are described in <a href="#section-2">Section 2</a>, and details that relate to how
individual CCIDs should operate, which are described in <a href="#section-3">Section 3</a>.
This separation of CCID-specific and DCCP general functions is in the
spirit of the modular approach adopted by DCCP.
Quick-Start [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>] is an experimental mechanism for transport
protocols specified for use in controlled environments. The current
specification of this mechanism is not intended or appropriate for
ubiquitous deployment in the global Internet.
Quick-Start is designed for use between end hosts within the same
network or on Internet paths that include IP routers. It works in
cooperation with routers, allowing a sender to determine an allowed
sending rate at the start and at times in the middle of a data
transfer (e.g., after an idle or application-limited period).
This document assumes the reader is familiar with <a href="./rfc4782">RFC 4782</a> [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>],
which specifies the use of Quick-Start with IP and with TCP. <a href="./rfc4782#section-7">Section</a>
<a href="./rfc4782#section-7">7 of RFC 4782</a> also provides guidelines for the use of Quick-Start
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
with other transport protocols, including DCCP. This document
provides answers to some of the issues that were raised by <a href="./rfc4782">RFC 4782</a>
and provides a definition of how Quick-Start must be used with DCCP.
In using Quick-Start, the sending DCCP end host indicates the desired
sending rate in bytes per second, using a Quick-Start option in the
IP header of a DCCP packet. Each Quick-Start-capable router along
the path could, in turn, either approve the requested rate, reduce
the requested rate, or indicate that the Quick-Start Request is not
approved.
If the Quick-Start Request is approved (possibly with a reduced rate)
by all the routers along the path, then the DCCP receiver returns an
appropriate Quick-Start Response. On receipt of this, the sending
end host can send at up to the approved rate for a period determined
by the method specified for each DCCP CCID, and not exceeding three
round-trip times. Subsequent transmissions will be governed by the
default CCID congestion control mechanisms for the connection. If
the Quick-Start Request is not approved, then the sender must use the
default congestion control mechanisms.
DCCP receivers are not required to acknowledge individual packets (or
pairs of segments) as in TCP. CCID 2 [<a href="./rfc4341" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control"">RFC4341</a>] allows much less
frequent feedback. Rate-based protocols (e.g., TCP-Friendly Rate
Control (TFRC) [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>], CCID 3 [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>]) have a different feedback
mechanism than that of TCP. With rate-based protocols, feedback may
be sent less frequently (e.g., once per Round-Trip Time (RTT)). In
such cases, a sender using Quick-Start needs to implement a different
mechanism to determine whether the Quick-Start sending rate has been
sustained by the network. This introduces a new mechanism called the
Quick-Start Validation Phase (<a href="#section-2.3">Section 2.3</a>).
In addition, this document defines two more general enhancements that
refine the use of Quick-Start after a flow has started (expected to
be more common in applications using DCCP). These are the Quick-
Start Interval (<a href="#section-2.1.2">Section 2.1.2</a>), and the reaction to mobility triggers
(<a href="#section-2.6">Section 2.6</a>).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Quick-Start for DCCP</span>
Unless otherwise specified, DCCP end hosts follow the procedures
specified in <a href="./rfc4782#section-4">Section 4 of [RFC4782]</a>, following the use specified for
Quick-Start with TCP.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Sending a Quick-Start Request for a DCCP Flow</span>
A DCCP sender MAY use a Quick-Start Request during the start of a
connection, when the sender would prefer to have a larger initial
rate than allowed by standard mechanisms (e.g., [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>] or
[<a href="./rfc3390" title=""Increasing TCP's Initial Window"">RFC3390</a>]).
A Quick-Start Request MAY also be used once a DCCP flow is connected
(i.e., in the middle of a DCCP flow). In standard operation, DCCP
CCIDs can constrain the sending rate (or window) to less than that
desired (e.g., when an application increases the rate at which it
wishes to send). A DCCP sender that has data to send after an idle
period or application-limited period (i.e., where the sender has
transmitted at less than the allowed sending rate) can send a Quick-
Start Request using the procedures defined in <a href="#section-3">Section 3</a>.
Quick-Start Requests will be more effective if the Quick-Start Rate
is not larger than necessary. Each requested Quick-Start Rate that
has been approved, but was not fully utilized, takes away from the
bandwidth pool maintained by Quick-Start routers that would be
otherwise available for granting successive requests [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
In contrast to most TCP applications, many DCCP applications have the
notion of a natural media rate that they wish to achieve. For
example, during the initial connection, a host may request a Quick-
Start Rate equal to the media rate of the application, appropriately
increased to account for the size of packet headers. (Note that
Quick-Start only provides a course-grain indication of the desired
rate that is expected to be sent in the next RTT.)
When sending a Quick-Start Request, the DCCP sender SHOULD send the
Quick-Start Request using a packet that requires an acknowledgement,
such as a DCCP-Request, DCCP-Response, or DCCP-Data.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. The Quick-Start Interval</span>
Excessive use of the Quick-Start mechanism is undesirable. This
document defines an enhancement to <a href="./rfc4782">RFC 4782</a> to update the use of
Quick-Start after a DCCP flow has started, by introducing the concept
of the Quick-Start Interval. The Quick-Start Interval specifies a
period of time during which a Quick-Start Request SHOULD NOT be sent.
The Quick-Start Interval is measured from the time of transmission of
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
the previous Quick-Start Request (<a href="#section-2.1">Section 2.1</a>). The Quick-Start
Interval MAY be overridden as a result of a network path change
(<a href="#section-2.6">Section 2.6</a>).
When a connection is established, the Quick-Start Interval is
initialized to the Initial_QSI. The Initial_QSI MUST be at least 6
seconds (larger values are permitted). This value was chosen so that
it is sufficiently large to prevent excessive router processing over
typical Internet paths. Quick-Start routers that track per-flow
state MAY penalize senders by suspending Quick-Start processing of
flows that make Quick-Start Requests for the same flow with an
interval less than 6 seconds.
When the first Quick-Start Request is sent, the Quick-Start Interval
is set to:
Quick-Start Interval = Initial_QSI;
After sending each subsequent Quick-Start Request, the Quick-Start
Interval is then recalculated as:
Quick-Start Interval = max(Quick-Start Interval * 2, 4 * RTT);
Each unsuccessful Quick-Start Request therefore results in the
Quick-Start Interval being doubled (resulting in an exponential
back-off). The maximum time the sender can back off is 64 seconds.
When the back-off calculation results in a larger value, the sender
MUST NOT send any further Quick-Start Requests for the remainder of
the DCCP connection (i.e., the sender ceases to use Quick-Start).
Whenever a Quick-Start Request is approved (at any rate), the Quick-
Start Interval is reset to the Initial_QSI.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Receiving a Quick-Start Request for a DCCP Flow</span>
The procedure for processing a received Quick-Start Request is
normatively defined in [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>] and summarized in this paragraph.
An end host that receives an IP packet containing a Quick-Start
Request passes the Quick-Start Request, along with the value in the
IP Time to Live (TTL) field, to the receiving DCCP layer. If the
receiving host is willing to permit the Quick-Start Request, it
SHOULD respond immediately by sending a packet that carries the
Quick-Start Response option in the DCCP header of the corresponding
feedback packet (e.g., using a DCCP-Ack packet or in a DCCP-DataAck
packet).
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
The Rate Request field in the Quick-Start Response option is set to
the received value of the Rate Request in the Quick-Start option or
to a lower value if the DCCP receiver is only willing to allow a
lower Rate Request. Where information is available (e.g., knowledge
of the local Layer 2 interface speed), a Quick-Start receiver SHOULD
verify that the received rate does not exceed its expected receive
link capacity. The TTL Diff field in the Quick-Start Response is set
to the difference between the received IP TTL value (Hop Limit field
in IPv6) and the Quick-Start TTL value. The Quick-Start Nonce in the
Response is set to the received value of the Quick-Start Nonce in the
Quick-Start option (or IPv6 Header Extension).
The Quick-Start Response MUST NOT be resent if it is lost in the
network [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. Packet loss could be an indication of congestion
on the return path; in which case, it is better not to approve the
Quick-Start Request.
If an end host receives an IP packet with a Quick-Start Request with
a requested rate of zero, then this host SHOULD NOT send a Quick-
Start Response [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. The Quick-Start Response Option</span>
The Quick-Start Response message must be carried by the transport
protocol using Quick-Start. This section defines a DCCP Header
option used to carry the Quick-Start Response. This header option is
REQUIRED for end hosts to utilize the Quick-Start mechanism with DCCP
flows. The format resembles that defined for TCP [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=45 | Length=8 | Resv. | Rate | TTL Diff |
| | | |Request| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quick-Start Nonce | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The Quick-Start Response Option
The first byte of the Quick-Start Response option contains the option
kind, identifying the DCCP option (45).
The second byte of the Quick-Start Response option contains the
option length in bytes. The length field MUST be set to 8 bytes.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
The third byte of the Quick-Start Response option contains a four-
bit Reserved field, and the four-bit allowed Rate Request, formatted
as in the IP Quick-Start Rate Request option [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
The fourth byte of the DCCP Quick-Start Response option contains the
TTL Diff. The TTL Diff contains the difference between the IP TTL
and Quick-Start TTL fields in the received Quick-Start Request
packet, as calculated in [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
Bytes 5-8 of the DCCP option contain the 30-bit Quick-Start Nonce and
a 2-bit Reserved field [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>].
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Receiving a Quick-Start Response</span>
On reception of a Quick-Start Response packet, the sender MUST report
the approved rate, by sending a Quick-Start Report of Approved Rate
[<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. This report includes the Rate Report field set to the
Approved Rate, and the QS Nonce set to the QS Nonce value sent in the
Quick-Start Request.
The Quick-Start Report of Approved Rate is sent as an IPv4 option or
IPv6 header extension using the first Quick-Start Packet or sent as
an option using a DCCP control packet if there are no DCCP-Data
packets pending transmission.
The Quick-Start Interval is also reset (as described in <a href="#section-2.1.1">Section</a>
<a href="#section-2.1.1">2.1.1</a>).
Reception of a Quick-Start Response packet that approves a rate
higher than the current rate results in the sender entering the
Quick-Start Mode.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. The Quick-Start Mode</span>
While a sender is in the Quick-Start Mode, all sent packets are known
as Quick-Start Packets [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. The Quick-Start Packets MUST be
sent at a rate not greater than the rate specified in the Quick-
Start Response. The Quick-Start Mode continues for a period up to
one RTT (shorter, if a feedback message arrives acknowledging the
receipt of one or more Quick-Start Packets).
The procedure following exit of the Quick-Start Mode is specified in
the following paragraphs. Note that this behavior is CCID-specific
and the details for each current CCID are described in <a href="#section-3">Section 3</a>.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. The Quick-Start Validation Phase</span>
After transmitting a set of Quick-Start Packets in the Quick-Start
Mode (and providing that no loss or congestion is reported), the
sender enters the Quick-Start Validation Phase. This phase persists
for a period during which the sender seeks to affirm that the
capacity used by the Quick-Start Packets did not introduce
congestion. This phase is introduced, because unlike TCP, DCCP
senders do not necessarily receive frequent feedback that would
indicate the congestion state of the forward path.
While in the Quick-Start Validation Phase, the sender is tentatively
permitted to continue sending using the Quick-Start rate. This phase
normally concludes when the sender receives feedback that includes an
acknowledgment that all Quick-Start Packets were received.
However, the duration of the Quick-Start Validation Phase MUST NOT
exceed the Quick-Start Validation Time (a maximum of 2 RTTs).
Implementations may set a timer (initialized to the Quick-Start
Validation Time) to detect the end of this phase. There may be scope
for optimization of timer resources in an implementation, since the
Quick-Start Validation period temporarily enforces more strict
monitoring of acknowledgements than normally used in a CCID (e.g., an
implementation may consider using a common timer resource for Quick-
Start Validation and a nofeedback timer).
An example sequence of packet exchanges showing Quick-Start with DCCP
is shown in Figure 2.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
DCCP Sender DCCP Receiver
Quick-Start +----------------------------------------------+
Request/Response | Quick-Start Request --> |
| <-- Quick-Start Response |
| Quick-Start Approve --> |
+----------------------------------------------+
+----------------------------------------------+
Quick-Start | Quick-Start Packets --> |
Mode | Quick-Start Packets --> |
| <-- Feedback A from Receiver|
| (acknowledging first QS Packet)|
+----------------------------------------------+
+----------------------------------------------
Quick-Start | Packets --> |
Validation Phase | <-- Feedback B from Receiver|
| (acknowledging all QS Packets)|
+----------------------------------------------
+----------------------------------------------+
DCCP | Packets --> |
Congestion | <-- Feedback C from Receiver|
Control | |
Figure 2. The Quick-Start Mode and Validation Phase
On conclusion of the Validation Phase (Feedback B in the above
figure), the sender expects to receive assurance that it may safely
use the current rate. A sender that completes the Quick-Start
Validation Phase with no reported packet loss or congestion stops
using the Quick-Start rate and continues to adjust its rate using the
standard congestion control mechanisms. For example, if the DCCP
sender was in slow-start prior to the Quick-Start Request, and no
packets were lost or ECN-marked (Explicit Congestion Notification)
since that time, then the sender continues in slow-start after
exiting Quick-Start Mode until the sender sees a packet loss, or
congestion is reported.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Procedure When No Response to a Quick-Start Request</span>
As in TCP, if a Quick-Start Request is dropped (i.e., the Request or
Response is not delivered by the network) the DCCP sender MUST revert
to the congestion control mechanisms it would have used if the
Quick-Start Request had not been approved. The connection is not
permitted to send a subsequent Quick-Start Request before expiry of
the current Quick-Start Interval (<a href="#section-2.1.1">Section 2.1.1</a>).
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Procedure When a Packet Is Dropped While Using Quick-Start</span>
A lost or ECN-marked packet is an indication of potential network
congestion. The behavior of a DCCP sender following a lost or ECN-
marked Quick-Start Packet or a lost feedback packet is specific to a
particular CCID (see <a href="#section-3">Section 3</a>).
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Interactions with Mobility and Signaled Path Changes</span>
The use of Quick-Start may assist end hosts in determining when it is
appropriate to increase their rate following an explicitly signaled
change of the network path.
When an end host receives a signal from an upstream link/network
notifying it of a path change, the change could simultaneously impact
more than one flow, and may affect flows between multiple endpoints.
Senders should avoid responding immediately, since this could result
in unwanted synchronization of signaling messages, and control loops
(e.g., a synchronized attempt to probe for a larger congestion
window), which may negatively impact the performance of the network
and transport sessions. In Quick-Start, this could increase the rate
of Quick-Start Requests, possibly incurring additional router load,
and may result in some requests not being granted. A sender must
ensure this does not generate an excessive rate of Quick-Start
Requests by using the method below:
A sender that has explicit information that the network path has
changed (e.g., a mobile IP binding update [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>], [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>])
SHOULD reset the Quick-Start Interval to its initial value (specified
in <a href="#section-2.1.1">Section 2.1.1</a>).
The sender MAY also send a Quick-Start Request to determine a new
safe transmission rate, but must observe the following rules:
- It MUST NOT send a Quick-Start Request within a period less than
the initial Quick-Start Interval (Initial_QSI) since it previously
sent a Quick-Start Request. That is, it must wait for at least a
period of Initial_QSI after the previous request, before sending a
new Quick-Start Request.
- If it has not sent a Quick-Start Request within the previous
Initial_QSI period, it SHOULD defer sending a Quick-Start Request
for a randomly chosen period between 0 and the Initial_QSI value in
seconds. The random period should be statistically independent
between different hosts and between different connections on the
same host. This delay is to mitigate the effect on router load of
synchronized responses by multiple connections in response to a
path change that affects multiple connections.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
Hosts do not generally have sufficient information to choose an
appropriate randomization interval. This value was selected to
ensure randomization of requests over the Quick-Start Interval. In
networks where a large number of senders may potentially be impacted
by the same signal, a larger value may be desirable (or methods may
be used to control this effect in the path change signaling).
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Interactions with Path MTU Discovery</span>
DCCP implementations are encouraged to support Path MTU Discovery
(PMTUD) when applications are able to use a DCCP packet size that
exceeds the default Path MTU [<a href="./rfc4340" title=""Datagram Congestion Control Protocol (DCCP)"">RFC4340</a>], [<a href="./rfc4821" title=""Packetization Layer Path MTU Discovery"">RFC4821</a>]. Quick-Start
Requests SHOULD NOT be sent with packets that are used as a PMTUD
Probe Packet, since these packets could be lost in the network
increasing the probability of loss of the request. It may therefore
be preferable to separately negotiate the PMTU and the use of Quick-
Start.
The DCCP protocol is datagram-based and therefore the size of the
segments that are sent is a function of application behavior as well
as being constrained by the largest supported Path MTU.
<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>. Interactions with Middleboxes</span>
A Quick-Start Request is carried in an IPv4 packet option or IPv6
extension header [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. Interactions with network devices
(middleboxes) that inspect or modify IP options could therefore lead
to discard, ICMP error, or DCCP-Reset when attempting to forward
packets carrying a Quick-Start Request.
If a DCCP sender sends a DCCP-Request that also carries a Quick-
Start Request, and does not receive a DCCP-Response to the packet,
the DCCP sender SHOULD resend the DCCP-Request packet without
including a Quick-Start Request.
Similarly, if a DCCP sender receives a DCCP-Reset in response to a
DCCP-Request packet that also carries a Quick-Start Request, then the
DCCP sender SHOULD resend the DCCP-Request packet without the Quick-
Start Request. The DCCP sender then ceases to use the Quick-Start
Mechanism for the remainder of the connection.
A DCCP sender that uses a Quick-Start Request within an established
connection and does not receive a response will treat this as non-
approval of the request. Successive unsuccessful attempts will
result in an exponential increase in the Quick-Start Interval
(<a href="#section-2.1.1">Section 2.1.1</a>). If this grows to a value exceeding 64 seconds, the
DCCP sender ceases to use the Quick-Start Mechanism for the remainder
of the connection.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mechanisms for Specific CCIDs</span>
The following sections specify the use of Quick-Start with DCCP CCID
2, CCID 3, and for DCCP with TFRC-SP as specified in CCID 4.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Quick-Start for CCID 2</span>
This section describes the Quick-Start mechanism to be used with DCCP
CCID 2 [<a href="./rfc4341" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control"">RFC4341</a>]. CCID 2 uses a TCP-like congestion control
mechanism.
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. The Quick-Start Request for CCID 2</span>
A Quick-Start Request MAY be sent to allow the sender to determine if
it is safe to use a larger initial cwnd. This permits a faster
start-up of a new CCID 2 flow.
A Quick-Start Request MAY also be sent for an established connection
to request a higher sending rate after an idle period or
application-limited period (described in <a href="#section-2.1">Section 2.1</a>). This allows a
receiver to use a larger cwnd than allowed with standard operation.
A Quick-Start Request that follows a reported loss or congestion
event MUST NOT request a Quick-Start rate that exceeds the largest
congestion window achieved by the CCID 2 connection since the last
packet drop (translated to a sending rate).
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Sending a Quick-Start Response with CCID 2</span>
A receiver processing a Quick-Start Request uses the method described
in <a href="#section-2.3">Section 2.3</a>. On receipt of a Quick-Start Request, the receiver
MUST send a Quick-Start Response (even if a receiver is constrained
by the ACK Ratio).
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. Using the Quick-Start Response with CCID 2</span>
On receipt of a valid Quick-Start Response option, the sender MUST
send a Quick-Start Approved option [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>] (see <a href="#section-2.3">Section 2.3</a>).
If the approved Quick-Start rate is less than current sending rate,
the sender does not enter the Quick-Start Mode, and continues using
the procedure defined in CCID 2.
If the approved Quick-Start rate at the sender exceeds the current
sending rate, the sender enters the Quick-Start Mode and continues in
the Quick-Start Mode for a maximum period of one RTT.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
The sender sets its Quick-Start cwnd (QS_cwnd) as follows:
QS_cwnd = (R * T) / (s + H) (1)
where R is the Rate Request in bytes per second, T is the measured
round-trip path delay (RTT), s is the packet size, and H is the
estimated DCCP/IP header size in bytes (e.g., 32 bytes for DCCP
layered directly over IPv4, but larger when using IPsec or IPv6).
A CCID 2 sender MAY then increase its cwnd to the QS_cwnd. The cwnd
should not be reduced (i.e., a QS_cwnd lower than cwnd should be
ignored, since the CCID 2 congestion control method already permits
this rate). CCID 2 is not a rate-paced protocol. Therefore, if the
QS_cwnd is used, the sending host MUST implement a suitable method to
pace the rate at which the Quick-Start Packets are sent until it
receives a DCCP-ACK for a packet sent during the Quick-Start Mode
[<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. The sending host SHOULD also record the previous cwnd and
note that the new cwnd has been determined by Quick-Start, rather by
other means (e.g., by setting a flag to indicate that it is in Quick-
Start Mode).
When the sender receives the first DCCP-ACK to a packet sent in the
Quick-Start Mode, it leaves the Quick-Start Mode and enters the
Validation Phase.
<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>. Quick-Start Validation Phase for CCID 2</span>
A CCID 2 sender MAY continue to send at the paced Quick-Start Rate
while in the Validation Phase. It leaves the Validation Phase on
receipt of an ACK that acknowledges the last Quick-Start Packet, or
if the validation phase persists for a period that exceeds the
Quick-Start Validation Time of 1 RTT. It MUST then reduce the cwnd
to the actual flight size (the current amount of unacknowledged data
sent) [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>] and uses the congestion control methods specified for
CCID 2.
<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>. Reported Loss or Congestion While Using Quick-Start</span>
A sender in the Quick-Start Mode (or Validation Phase) that detects
congestion (e.g., receives a feedback packet that reports new packet
loss or a packet with a congestion marking), MUST immediately leave
the Quick-Start Mode (or Validation Phase). It then resets the cwnd
to half the recorded previous cwnd and enters the congestion
avoidance phase described in [<a href="./rfc4341" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control"">RFC4341</a>].
In the absence of any feedback at the end of the Validation period,
the sender resets the cwnd to half the recorded previous cwnd and
enters the congestion avoidance phase.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>. CCID 2 Feedback Traffic on the Reverse Path</span>
A CCID 2 receiver sends feedback for groups of received packets
[<a href="./rfc4341" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control"">RFC4341</a>]. Approval of a higher transmission rate using Quick-Start
will increase control traffic on the reverse path. A return path
that becomes congested could have a transient negative impact on
other traffic flows sharing the return link. The lower rate of
feedback will then limit the achievable rate in the forward
direction.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Quick-Start for CCID 3</span>
This section describes the Quick-Start mechanism to be used with DCCP
CCID 3 [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>]. The rate-based congestion control mechanism used
by CCID 3 leads to specific issues that are addressed by Quick-Start
in this section.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. The Quick-Start Request for CCID 3</span>
A Quick-Start Request MAY be sent to allow the sender to determine if
it is safe to use a larger initial sending rate. This permits a
faster start-up of a new CCID 3 flow.
A Quick-Start Request MAY also be sent to request a higher sending
rate after an idle period (in which the nofeedback timer expires
[<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>]) or an application-limited period (described in <a href="#section-2.1">Section</a>
<a href="#section-2.1">2.1</a>). This allows a receiver to increase the sending rate faster
than allowed with standard operation (i.e., faster than twice the
rate reported by a CCID 3 receiver in the most recent feedback
message).
The requested rate specified in a Quick-Start Request MUST NOT exceed
the TFRC-controlled sending rate [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>] when this is bounded by
the current loss event rate (if any), either from calculation at the
sender or from feedback received from the receiver. CCID 3 considers
this rate is a safe response in the presence of expected congestion.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Sending a Quick-Start Response with CCID 3</span>
When processing a received Quick-Start Request, the receiver uses the
method described in <a href="#section-2.3">Section 2.3</a>. In addition, if a CCID 3 receiver
uses the window counter to send periodic feedback messages, then the
receiver sets its local variable last_counter to the value of the
window counter reported by the segment containing the Quick-Start
Request. The next feedback message would then be sent when the
window_counter is greater or equal to last_counter + 4. If the CCID
3 receiver uses a feedback timer to send period feedback messages,
then the receiver MUST reset the CCID 3 feedback timer, causing the
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
feedback to be sent as soon as possible. This helps to align the
timing of feedback to the start and end of the period in which
Quick-Start Packets are sent, and will normally result in feedback at
a time that is approximately the end of the period when Quick-Start
Packets are received.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Using the Quick-Start Response with CCID 3</span>
On receipt of a valid Quick-Start Response option, the sender MUST
send a Quick-Start Approved option [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>] (see <a href="#section-2.3">Section 2.3</a>). The
sender then uses one of three procedures:
* If the approved Quick-Start rate is less than the current sending
rate, the sender does not enter the Quick-Start Mode and continues
using the procedure defined in CCID 3.
* If loss or congestion is reported after sending the Quick-Start
Request, the sender also does not enter the Quick-Start Mode and
continues using the procedure defined in CCID 3.
* If the approved Quick-Start rate exceeds the current sending rate,
the sender enters the Quick-Start Mode and continues in the Quick-
Start Mode for a maximum period of 1 RTT. The sender sets its
Quick-Start sending rate (QS_sendrate) as follows:
QS_sendrate = R * s/(s + H); (2)
where R the Rate Request in bytes per second, s is the packet size
[<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>], and H the estimated DCCP/IP header size in bytes (e.g.,
32 bytes for IPv4). A CCID 3 host MAY then increase its sending
rate to the QS_sendrate. The rate should not be reduced.
CCID 3 is a rate-paced protocol. Therefore, if the QS_sendrate is
used, the sending host MUST pace the rate at which the Quick-Start
Packets are sent over the next RTT. The sending host SHOULD also
record the previous congestion-controlled rate and note that the
new rate has been determined by Quick-Start rather by other means
(e.g., by setting a flag to indicate that it is in the Quick-Start
Mode).
The sender exits the Quick-Start Mode after either:
* Receipt of a feedback packet acknowledging one or more Quick-Start
Packets,
* A period of 1 RTT after receipt of a Quick-Start Response, or
* Detection of a loss or congestion event (see <a href="#section-3.2.5">Section 3.2.5</a>).
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>. Quick-Start Validation Phase for CCID 3</span>
After transmitting a set of Quick-Start Packets in the Quick Start
Mode (and providing that no loss or congestion marking is reported),
the sender enters the Quick-Start Validation Phase. A sender that
receives feedback that reports a loss or congestion event MUST follow
the procedures described in <a href="#section-3.2.5">Section 3.2.5</a>.
The sender MUST exit the Quick-Start Validation Phase on receipt of
feedback that acknowledges all packets sent in the Quick-Start Mode
(i.e., all Quick-Start Packets) or if the Validation Phase persists
for a period that exceeds the Quick-Start Validation Time of two
RTTs.
A sender that completes the Quick-Start Validation Phase with no
reported packet loss or congestion stops using the QS_sendrate and
MUST recalculate a suitable sending rate using the standard
congestion control mechanisms [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>].
If no feedback is received within the Quick-Start Validation Phase,
the sender MUST return to the minimum of the recorded original rate
(at the start of the Quick-Start Mode) and one half of the
QS_sendrate. The nofeedback timer is also reset.
<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>. Reported Loss or Congestion during the Quick-Start Mode or</span>
<span class="h4"> Validation Phase</span>
A sender in the Quick-Start Mode or Validation Phase that detects
congestion (e.g., receives a feedback packet that reports new packet
loss or a packet with a congestion marking) MUST immediately leave
the Quick-Start Mode or Validation Phase and enter the congestion
avoidance phase [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>]. This implies re-calculating the sending
rate, X, as required by <a href="./rfc4342">RFC 4342</a>:
X = max(min(X_calc, 2*X_recv), s/t_mbi);
where X_calc is the transmit rate calculated by the throughput
equation, X_recv is the reported receiver rate, s is the packet size
and t_mbi is the maximum back-off interval of 64 seconds.
The current specification of TFRC [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>], which obsoletes <a href="./rfc3448">RFC</a>
<a href="./rfc3448">3448</a>, uses a set of X_recv values and uses the maximum of the set
during application-limited intervals. This calculates the sending
rate, X as:
X = max(min(X_calc, recv_limit),s/t_mbi);
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
where recv_limit could be max(X_recv_set) or 2*max(X_recv_set)
depending on whether there was a new loss event during a data-
limited interval, or no loss event during an application-limited
interval respectively. When the sender is not application-limited,
the recv_limit is set to 2*max(X_recv_set).
A sender using <a href="./rfc4342">RFC 4342</a> updated by [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>], calculates the sending
rate, X, using the above formula normatively defined in [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>].
<span class="h4"><a class="selflink" id="section-3.2.6" href="#section-3.2.6">3.2.6</a>. CCID 3 Feedback Traffic on the Reverse Path</span>
A CCID 3 receiver sends feedback at least once each RTT [<a href="./rfc4342" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)"">RFC4342</a>].
Use of Quick-Start is therefore not expected to significantly
increase control traffic on the reverse path.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Quick-Start for CCID 4</span>
This section describes the Quick-Start mechanism to be used when DCCP
uses TFRC-SP [<a href="./rfc4828" title=""TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"">RFC4828</a>] in place of TFRC [<a href="./rfc5348" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">RFC5348</a>], as specified in
CCID 4 [<a href="./rfc5622" title=""Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)"">RFC5622</a>]. CCID 4 is similar to CCID 3 except that a sender
using CCID 4 is limited to a maximum of 100 packets/second.
The Quick-Start procedure defined below therefore resembles that for
CCID 3.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. The Quick-Start Request for CCID 4</span>
The procedure for sending a Quick-Start Request using CCID 4 is the
same as for CCID 3, defined in <a href="#section-3.2.1">Section 3.2.1</a>. In addition, the
requested rate MUST be less than or equal to the equivalent of a
sending rate of 100 packets per second [<a href="./rfc4828" title=""TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"">RFC4828</a>]. CCID 4 [<a href="./rfc4828" title=""TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"">RFC4828</a>]
specifies that the allowed sending rate derived from the TCP
throughput equation is reduced by a factor that accounts for packet
header size.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Sending a Quick-Start Response with CCID 4</span>
This procedure is the same as for CCID 3, defined in <a href="#section-3.2.2">Section 3.2.2</a>.
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Using the Quick-Start Response with CCID 4</span>
This procedure is the same as for CCID 3, defined in Sections <a href="#section-3.2.3">3.2.3</a>,
3.2.4, and 3.2.5, except that the congestion control procedures is
updated to use TFRC-SP [<a href="./rfc4828" title=""TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"">RFC4828</a>].
A CCID 4 sender does not need to account for headers a second time
when translating the approved Quick-Start rate into an allowed
sending rate (as described in <a href="./rfc5622#section-5">Section 5 of [RFC5622]</a>.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h4"><a class="selflink" id="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Reported Loss or Congestion While Using Quick-Start</span>
This procedure is the same as for CCID 3, defined in <a href="#section-3.2.5">Section 3.2.5</a>,
except that the congestion control procedures is updated to use
TFRC-SP [<a href="./rfc4828" title=""TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant"">RFC4828</a>].
<span class="h4"><a class="selflink" id="section-3.3.5" href="#section-3.3.5">3.3.5</a>. CCID 4 Feedback Traffic on the Reverse Path</span>
A CCID 4 receiver sends feedback at least once each RTT. Use of
Quick-Start is therefore not expected to significantly increase
control traffic on the reverse path.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Discussion of Issues</span>
The considerations for using Quick-Start with DCCP are not
significantly different to those for Quick-Start with TCP. The
document does not modify the router behavior specified for Quick-
Start.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Overrun and the Quick-Start Validation Phase</span>
The less frequent feedback of DCCP raises an issue in that a sender
using Quick-Start may continue to use the rate specified by a Quick-
Start Response for a period that exceeds one path round trip time
(i.e., that which TCP would have used). This overrun is a result of
the less frequent feedback interval used by DCCP (i.e., CCID 2 may
delay feedback by at most one half cwnd and CCID 3 and CCID 4 provide
feedback at least once per RTT). In the method specified by this
document, the Quick-Start Validation Phase bounds this overrun to be
not more than an additional two RTTs.
The selected method was chosen as a compromise that reflects the need
to terminate quickly following the loss of a feedback packet, and the
need to allow sufficient time for end host and router processing, as
well as the different perceptions of the path RTT held at the sender
and receiver. Any reported loss or congestion results in immediate
action without waiting for completion of the Quick-Start Validation
period.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Experimental Status</span>
There are many cases in which Quick-Start Requests would not be
approved [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. These include communication over paths
containing routers, IP tunnels, MPLS paths, and the like, that do not
support Quick-Start. These cases also include paths with routers or
middleboxes that drop packets containing IP options (or IPv6
extensions). Quick-Start Requests could be difficult to approve over
paths that include multi-access Layer-2 networks.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
Transient effects could arise when the transport protocol packets
associated with a connection are multiplexed over multiple parallel
(sometimes known as alternative) links or network-layer paths, and
Quick-Start is used, since it will be effective on only one of the
paths, but could lead to increased traffic on all paths.
A CCID 2 sender using Quick-Start can increase the control traffic on
the reverse path, which could have a transient negative impact on
other traffic flows sharing the return link (<a href="#section-3.1.6">Section 3.1.6</a>). The
lower rate of feedback will then limit the achievable rate in the
forward direction.
[<a id="ref-RFC4782">RFC4782</a>] also describes environments where the Quick-Start mechanism
could fail with false positives, with the sender incorrectly assuming
that the Quick-Start Request had been approved by all of the routers
along the path. As a result of these concerns, and as a result of
the difficulties and the seeming absence of motivation for routers,
such as core routers, to deploy Quick-Start, Quick-Start has been
proposed as a mechanism that could be of use in controlled
environments, and not as a mechanism that would be intended or
appropriate for ubiquitous deployment in the global Internet.
Further experimentation would be required to confirm the deployment
of Quick-Start and to investigate performance issues that may arise,
prior to any recommendation for use over the general Internet.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
IANA has assigned a DCCP Option Type (45) from the DCCP Option Types
Registry. This Option is applicable to all CCIDs and is known as the
"Quick-Start Response" Option and is defined in <a href="#section-2.2.1">Section 2.2.1</a>. It
specifies a length value in the format used for options numbered
32-128.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgments</span>
The author gratefully acknowledges the previous work by Sally Floyd
to identify issues that impact Quick-Start for DCCP, and her comments
to improve this document. We also acknowledge comments and
corrections from Pasi Sarolahti, Vincent Roca, Mark Allman, Michael
Scharf, and others in the IETF DCCP Working Group (WG).
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Security issues are discussed in [<a href="./rfc4782" title=""Quick-Start for TCP and IP"">RFC4782</a>]. Middlebox deployment
issues are also highlighted in <a href="#section-2.8">Section 2.8</a>. No new security issues
are raised within this document.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4340">RFC4340</a>] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", <a href="./rfc4340">RFC 4340</a>, March 2006.
[<a id="ref-RFC4341">RFC4341</a>] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", <a href="./rfc4341">RFC 4341</a>, March 2006.
[<a id="ref-RFC4342">RFC4342</a>] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", <a href="./rfc4342">RFC 4342</a>,
March 2006.
[<a id="ref-RFC4782">RFC4782</a>] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
"Quick-Start for TCP and IP", <a href="./rfc4782">RFC 4782</a>, January 2007.
[<a id="ref-RFC4828">RFC4828</a>] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
(TFRC): The Small-Packet (SP) Variant", <a href="./rfc4828">RFC 4828</a>, April
2007.
[<a id="ref-RFC5348">RFC5348</a>] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", <a href="./rfc5348">RFC</a>
<a href="./rfc5348">5348</a>, September 2008.
[<a id="ref-RFC5622">RFC5622</a>] Floyd, S., and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate
Control for Small Packets (TFRC-SP)", <a href="./rfc5622">RFC 5622</a>, August
2009.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3344">RFC3344</a>] Perkins, C., Ed., "IP Mobility Support for IPv4", <a href="./rfc3344">RFC</a>
<a href="./rfc3344">3344</a>, August 2002.
[<a id="ref-RFC3775">RFC3775</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
[<a id="ref-RFC3390">RFC3390</a>] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", <a href="./rfc3390">RFC 3390</a>, October 2002.
[<a id="ref-RFC4821">RFC4821</a>] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", <a href="./rfc4821">RFC 4821</a>, March 2007.
<span class="grey">Fairhurst & Sathiaseelan Experimental [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5634">RFC 5634</a> Quick-Start for DCCP August 2009</span>
Authors' Addresses
Godred Fairhurst
School of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
Scotland, UK
EMail: gorry@erg.abdn.ac.uk
URI: <a href="http://www.erg.abdn.ac.uk/users/gorry">http://www.erg.abdn.ac.uk/users/gorry</a>
Arjuna Sathiaseelan
School of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
Scotland, UK
EMail: arjuna@erg.abdn.ac.uk
URI: <a href="http://www.erg.abdn.ac.uk/users/arjuna">http://www.erg.abdn.ac.uk/users/arjuna</a>
Fairhurst & Sathiaseelan Experimental [Page 22]
</pre>
|
