-
Notifications
You must be signed in to change notification settings - Fork 201
/
draft-ietf-quic-transport.txt
7784 lines (5355 loc) · 324 KB
/
draft-ietf-quic-transport.txt
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
QUIC J. Iyengar, Ed.
Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed.
Expires: August 18, 2019 Mozilla
February 14, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-latest
Abstract
This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-transport>.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Iyengar & Thomson Expires August 18, 2019 [Page 1]
Internet-Draft QUIC Transport Protocol February 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Document Structure . . . . . . . . . . . . . . . . . . . 6
1.2. Terms and Definitions . . . . . . . . . . . . . . . . . . 7
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 8
2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Stream Types and Identifiers . . . . . . . . . . . . . . 9
2.2. Sending and Receiving Data . . . . . . . . . . . . . . . 10
2.3. Stream Prioritization . . . . . . . . . . . . . . . . . . 10
3. Stream States . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Sending Stream States . . . . . . . . . . . . . . . . . . 11
3.2. Receiving Stream States . . . . . . . . . . . . . . . . . 13
3.3. Permitted Frame Types . . . . . . . . . . . . . . . . . . 16
3.4. Bidirectional Stream States . . . . . . . . . . . . . . . 16
3.5. Solicited State Transitions . . . . . . . . . . . . . . . 18
4. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Data Flow Control . . . . . . . . . . . . . . . . . . . . 19
4.2. Flow Credit Increments . . . . . . . . . . . . . . . . . 20
4.3. Handling Stream Cancellation . . . . . . . . . . . . . . 21
4.4. Stream Final Size . . . . . . . . . . . . . . . . . . . . 22
4.5. Controlling Concurrency . . . . . . . . . . . . . . . . . 22
5. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Connection ID . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Issuing Connection IDs . . . . . . . . . . . . . . . 24
5.1.2. Consuming and Retiring Connection IDs . . . . . . . . 25
5.2. Matching Packets to Connections . . . . . . . . . . . . . 25
5.2.1. Client Packet Handling . . . . . . . . . . . . . . . 26
5.2.2. Server Packet Handling . . . . . . . . . . . . . . . 27
5.3. Life of a QUIC Connection . . . . . . . . . . . . . . . . 27
6. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 28
6.1. Sending Version Negotiation Packets . . . . . . . . . . . 28
6.2. Handling Version Negotiation Packets . . . . . . . . . . 28
6.2.1. Version Negotiation Between Draft Versions . . . . . 29
6.3. Using Reserved Versions . . . . . . . . . . . . . . . . . 29
7. Cryptographic and Transport Handshake . . . . . . . . . . . . 29
7.1. Example Handshake Flows . . . . . . . . . . . . . . . . . 31
7.2. Negotiating Connection IDs . . . . . . . . . . . . . . . 32
Iyengar & Thomson Expires August 18, 2019 [Page 2]
Internet-Draft QUIC Transport Protocol February 2019
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 33
7.3.1. Values of Transport Parameters for 0-RTT . . . . . . 34
7.3.2. New Transport Parameters . . . . . . . . . . . . . . 35
8. Address Validation . . . . . . . . . . . . . . . . . . . . . 35
8.1. Address Validation During Connection Establishment . . . 36
8.1.1. Address Validation using Retry Packets . . . . . . . 37
8.1.2. Address Validation for Future Connections . . . . . . 37
8.1.3. Address Validation Token Integrity . . . . . . . . . 39
8.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 40
8.3. Initiating Path Validation . . . . . . . . . . . . . . . 40
8.4. Path Validation Responses . . . . . . . . . . . . . . . . 41
8.5. Successful Path Validation . . . . . . . . . . . . . . . 41
8.6. Failed Path Validation . . . . . . . . . . . . . . . . . 41
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 42
9.1. Probing a New Path . . . . . . . . . . . . . . . . . . . 43
9.2. Initiating Connection Migration . . . . . . . . . . . . . 43
9.3. Responding to Connection Migration . . . . . . . . . . . 44
9.3.1. Peer Address Spoofing . . . . . . . . . . . . . . . . 44
9.3.2. On-Path Address Spoofing . . . . . . . . . . . . . . 45
9.3.3. Off-Path Packet Forwarding . . . . . . . . . . . . . 45
9.4. Loss Detection and Congestion Control . . . . . . . . . . 47
9.5. Privacy Implications of Connection Migration . . . . . . 47
9.6. Server's Preferred Address . . . . . . . . . . . . . . . 48
9.6.1. Communicating A Preferred Address . . . . . . . . . . 49
9.6.2. Responding to Connection Migration . . . . . . . . . 49
9.6.3. Interaction of Client Migration and Preferred Address 50
9.7. Use of IPv6 Flow-Label and Migration . . . . . . . . . . 50
10. Connection Termination . . . . . . . . . . . . . . . . . . . 51
10.1. Closing and Draining Connection States . . . . . . . . . 51
10.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . . . 52
10.3. Immediate Close . . . . . . . . . . . . . . . . . . . . 53
10.4. Stateless Reset . . . . . . . . . . . . . . . . . . . . 54
10.4.1. Detecting a Stateless Reset . . . . . . . . . . . . 56
10.4.2. Calculating a Stateless Reset Token . . . . . . . . 57
10.4.3. Looping . . . . . . . . . . . . . . . . . . . . . . 58
11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 58
11.1. Connection Errors . . . . . . . . . . . . . . . . . . . 59
11.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 59
12. Packets and Frames . . . . . . . . . . . . . . . . . . . . . 60
12.1. Protected Packets . . . . . . . . . . . . . . . . . . . 60
12.2. Coalescing Packets . . . . . . . . . . . . . . . . . . . 61
12.3. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 61
12.4. Frames and Frame Types . . . . . . . . . . . . . . . . . 63
13. Packetization and Reliability . . . . . . . . . . . . . . . . 65
13.1. Packet Processing and Acknowledgment . . . . . . . . . . 66
13.1.1. Sending ACK Frames . . . . . . . . . . . . . . . . . 66
13.1.2. ACK Frames and Packet Protection . . . . . . . . . . 67
13.2. Retransmission of Information . . . . . . . . . . . . . 67
Iyengar & Thomson Expires August 18, 2019 [Page 3]
Internet-Draft QUIC Transport Protocol February 2019
13.3. Explicit Congestion Notification . . . . . . . . . . . . 70
13.3.1. ECN Counts . . . . . . . . . . . . . . . . . . . . . 70
13.3.2. ECN Verification . . . . . . . . . . . . . . . . . . 71
14. Packet Size . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.1. Path Maximum Transmission Unit (PMTU) . . . . . . . . . 73
14.2. ICMP Packet Too Big Messages . . . . . . . . . . . . . . 74
14.3. Datagram Packetization Layer PMTU Discovery . . . . . . 75
15. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 75
16. Variable-Length Integer Encoding . . . . . . . . . . . . . . 76
17. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 77
17.1. Packet Number Encoding and Decoding . . . . . . . . . . 77
17.2. Long Header Packets . . . . . . . . . . . . . . . . . . 78
17.2.1. Version Negotiation Packet . . . . . . . . . . . . . 81
17.2.2. Initial Packet . . . . . . . . . . . . . . . . . . . 82
17.2.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . 85
17.2.4. Handshake Packet . . . . . . . . . . . . . . . . . . 86
17.2.5. Retry Packet . . . . . . . . . . . . . . . . . . . . 87
17.3. Short Header Packets . . . . . . . . . . . . . . . . . . 90
18. Transport Parameter Encoding . . . . . . . . . . . . . . . . 91
18.1. Transport Parameter Definitions . . . . . . . . . . . . 92
19. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 95
19.1. PADDING Frame . . . . . . . . . . . . . . . . . . . . . 95
19.2. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 96
19.3. ACK Frames . . . . . . . . . . . . . . . . . . . . . . . 96
19.3.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 98
19.3.2. ECN Counts . . . . . . . . . . . . . . . . . . . . . 99
19.4. RESET_STREAM Frame . . . . . . . . . . . . . . . . . . . 100
19.5. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 101
19.6. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 101
19.7. NEW_TOKEN Frame . . . . . . . . . . . . . . . . . . . . 102
19.8. STREAM Frames . . . . . . . . . . . . . . . . . . . . . 103
19.9. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 104
19.10. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . 105
19.11. MAX_STREAMS Frames . . . . . . . . . . . . . . . . . . . 106
19.12. DATA_BLOCKED Frame . . . . . . . . . . . . . . . . . . . 107
19.13. STREAM_DATA_BLOCKED Frame . . . . . . . . . . . . . . . 107
19.14. STREAMS_BLOCKED Frames . . . . . . . . . . . . . . . . . 108
19.15. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . 108
19.16. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 110
19.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 111
19.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . 111
19.19. CONNECTION_CLOSE Frames . . . . . . . . . . . . . . . . 111
19.20. Extension Frames . . . . . . . . . . . . . . . . . . . . 112
20. Transport Error Codes . . . . . . . . . . . . . . . . . . . . 113
20.1. Application Protocol Error Codes . . . . . . . . . . . . 114
21. Security Considerations . . . . . . . . . . . . . . . . . . . 114
21.1. Handshake Denial of Service . . . . . . . . . . . . . . 114
21.2. Amplification Attack . . . . . . . . . . . . . . . . . . 115
Iyengar & Thomson Expires August 18, 2019 [Page 4]
Internet-Draft QUIC Transport Protocol February 2019
21.3. Optimistic ACK Attack . . . . . . . . . . . . . . . . . 116
21.4. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 116
21.5. Stream Fragmentation and Reassembly Attacks . . . . . . 116
21.6. Stream Commitment Attack . . . . . . . . . . . . . . . . 117
21.7. Explicit Congestion Notification Attacks . . . . . . . . 117
21.8. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 117
21.9. Version Downgrade . . . . . . . . . . . . . . . . . . . 118
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118
22.1. QUIC Transport Parameter Registry . . . . . . . . . . . 118
22.2. QUIC Frame Type Registry . . . . . . . . . . . . . . . . 120
22.3. QUIC Transport Error Codes Registry . . . . . . . . . . 120
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 122
23.1. Normative References . . . . . . . . . . . . . . . . . . 123
23.2. Informative References . . . . . . . . . . . . . . . . . 124
Appendix A. Sample Packet Number Decoding Algorithm . . . . . . 126
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 126
B.1. Since draft-ietf-quic-transport-17 . . . . . . . . . . . 127
B.2. Since draft-ietf-quic-transport-16 . . . . . . . . . . . 127
B.3. Since draft-ietf-quic-transport-15 . . . . . . . . . . . 129
B.4. Since draft-ietf-quic-transport-14 . . . . . . . . . . . 129
B.5. Since draft-ietf-quic-transport-13 . . . . . . . . . . . 129
B.6. Since draft-ietf-quic-transport-12 . . . . . . . . . . . 130
B.7. Since draft-ietf-quic-transport-11 . . . . . . . . . . . 131
B.8. Since draft-ietf-quic-transport-10 . . . . . . . . . . . 131
B.9. Since draft-ietf-quic-transport-09 . . . . . . . . . . . 132
B.10. Since draft-ietf-quic-transport-08 . . . . . . . . . . . 132
B.11. Since draft-ietf-quic-transport-07 . . . . . . . . . . . 133
B.12. Since draft-ietf-quic-transport-06 . . . . . . . . . . . 134
B.13. Since draft-ietf-quic-transport-05 . . . . . . . . . . . 134
B.14. Since draft-ietf-quic-transport-04 . . . . . . . . . . . 134
B.15. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 135
B.16. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 135
B.17. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 136
B.18. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 138
B.19. Since draft-hamilton-quic-transport-protocol-01 . . . . . 138
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 139
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 139
1. Introduction
QUIC is a multiplexed and secure general-purpose transport protocol
that provides:
o Stream multiplexing
o Stream and connection-level flow control
Iyengar & Thomson Expires August 18, 2019 [Page 5]
Internet-Draft QUIC Transport Protocol February 2019
o Low-latency connection establishment
o Connection migration and resilience to NAT rebinding
o Authenticated and encrypted header and payload
QUIC uses UDP as a substrate to avoid requiring changes to legacy
client operating systems and middleboxes. QUIC authenticates all of
its headers and encrypts most of the data it exchanges, including its
signaling, to avoid incurring a dependency on middleboxes.
1.1. Document Structure
This document describes the core QUIC protocol and is structured as
follows.
o Streams are the basic service abstraction that QUIC provides.
* Section 2 describes core concepts related to streams,
* Section 3 provides a reference model for stream states, and
* Section 4 outlines the operation of flow control.
o Connections are the context in which QUIC endpoints communicate.
* Section 5 describes core concepts related to connections,
* Section 6 describes version negotiation,
* Section 7 details the process for establishing connections,
* Section 8 specifies critical denial of service mitigation
mechanisms,
* Section 9 describes how endpoints migrate a connection to a new
network path,
* Section 10 lists the options for terminating an open
connection, and
* Section 11 provides general guidance for error handling.
o Packets and frames are the basic unit used by QUIC to communicate.
* Section 12 describes concepts related to packets and frames,
Iyengar & Thomson Expires August 18, 2019 [Page 6]
Internet-Draft QUIC Transport Protocol February 2019
* Section 13 defines models for the transmission, retransmission,
and acknowledgement of data, and
* Section 14 specifies rules for managing the size of packets.
o Finally, encoding details of QUIC protocol elements are described
in:
* Section 15 (Versions),
* Section 16 (Integer Encoding),
* Section 17 (Packet Headers),
* Section 18 (Transport Parameters),
* Section 19 (Frames), and
* Section 20 (Errors).
Accompanying documents describe QUIC's loss detection and congestion
control [QUIC-RECOVERY], and the use of TLS for key negotiation
[QUIC-TLS].
This document defines QUIC version 1, which conforms to the protocol
invariants in [QUIC-INVARIANTS].
1.2. Terms and Definitions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Commonly used terms in the document are described below.
QUIC: The transport protocol described by this document. QUIC is a
name, not an acronym.
QUIC packet: The smallest unit of QUIC that can be encapsulated in a
UDP datagram. Multiple QUIC packets can be encapsulated in a
single UDP datagram.
Endpoint: An entity that can participate in a QUIC connection by
generating, receiving, and processing QUIC packets. There are
only two types of endpoint in QUIC: client and server.
Iyengar & Thomson Expires August 18, 2019 [Page 7]
Internet-Draft QUIC Transport Protocol February 2019
Client: The endpoint initiating a QUIC connection.
Server: The endpoint accepting incoming QUIC connections.
Connection ID: An opaque identifier that is used to identify a QUIC
connection at an endpoint. Each endpoint sets a value for its
peer to include in packets sent towards the endpoint.
Stream: A unidirectional or bidirectional channel of ordered bytes
within a QUIC connection. A QUIC connection can carry multiple
simultaneous streams.
Application: An entity that uses QUIC to send and receive data.
1.3. Notational Conventions
Packet and frame diagrams in this document use the format described
in Section 3.1 of [RFC2360], with the following additional
conventions:
[x]: Indicates that x is optional
x (A): Indicates that x is A bits long
x (A/B/C) ...: Indicates that x is one of A, B, or C bits long
x (i) ...: Indicates that x uses the variable-length encoding in
Section 16
x (*) ...: Indicates that x is variable-length
2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. An alternative view of QUIC streams
is as an elastic "message" abstraction.
Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow
control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not
provide any means of ensuring ordering between bytes on different
streams.
Iyengar & Thomson Expires August 18, 2019 [Page 8]
Internet-Draft QUIC Transport Protocol February 2019
QUIC allows for an arbitrary number of streams to operate
concurrently and for an arbitrary amount of data to be sent on any
stream, subject to flow control constraints (see Section 4) and
stream limits.
2.1. Stream Types and Identifiers
Streams can be unidirectional or bidirectional. Unidirectional
streams carry data in one direction: from the initiator of the stream
to its peer. Bidirectional streams allow for data to be sent in both
directions.
Streams are identified within a connection by a numeric value,
referred to as the stream ID. Stream IDs are unique to a stream. A
QUIC endpoint MUST NOT reuse a stream ID within a connection. Stream
IDs are encoded as variable-length integers (see Section 16).
The least significant bit (0x1) of the stream ID identifies the
initiator of the stream. Client-initiated streams have even-numbered
stream IDs (with the bit set to 0), and server-initiated streams have
odd-numbered stream IDs (with the bit set to 1).
The second least significant bit (0x2) of the stream ID distinguishes
between bidirectional streams (with the bit set to 0) and
unidirectional streams (with the bit set to 1).
The least significant two bits from a stream ID therefore identify a
stream as one of four types, as summarized in Table 1.
+------+----------------------------------+
| Bits | Stream Type |
+------+----------------------------------+
| 0x0 | Client-Initiated, Bidirectional |
| | |
| 0x1 | Server-Initiated, Bidirectional |
| | |
| 0x2 | Client-Initiated, Unidirectional |
| | |
| 0x3 | Server-Initiated, Unidirectional |
+------+----------------------------------+
Table 1: Stream ID Types
Within each type, streams are created with numerically increasing
stream IDs. A stream ID that is used out of order results in all
streams of that type with lower-numbered stream IDs also being
opened.
Iyengar & Thomson Expires August 18, 2019 [Page 9]
Internet-Draft QUIC Transport Protocol February 2019
The first bidirectional stream opened by the client has a stream ID
of 0.
2.2. Sending and Receiving Data
STREAM frames (Section 19.8) encapsulate data sent by an application.
An endpoint uses the Stream ID and Offset fields in STREAM frames to
place data in order.
Endpoints MUST be able to deliver stream data to an application as an
ordered byte-stream. Delivering an ordered byte-stream requires that
an endpoint buffer any data that is received out of order, up to the
advertised flow control limit.
QUIC makes no specific allowances for delivery of stream data out of
order. However, implementations MAY choose to offer the ability to
deliver data out of order to a receiving application.
An endpoint could receive data for a stream at the same stream offset
multiple times. Data that has already been received can be
discarded. The data at a given offset MUST NOT change if it is sent
multiple times; an endpoint MAY treat receipt of different data at
the same offset within a stream as a connection error of type
PROTOCOL_VIOLATION.
Streams are an ordered byte-stream abstraction with no other
structure that is visible to QUIC. STREAM frame boundaries are not
expected to be preserved when data is transmitted, when data is
retransmitted after packet loss, or when data is delivered to the
application at a receiver.
An endpoint MUST NOT send data on any stream without ensuring that it
is within the flow control limits set by its peer. Flow control is
described in detail in Section 4.
2.3. Stream Prioritization
Stream multiplexing can have a significant effect on application
performance if resources allocated to streams are correctly
prioritized.
QUIC does not provide frames for exchanging prioritization
information. Instead it relies on receiving priority information
from the application that uses QUIC.
A QUIC implementation SHOULD provide ways in which an application can
indicate the relative priority of streams. When deciding which
Iyengar & Thomson Expires August 18, 2019 [Page 10]
Internet-Draft QUIC Transport Protocol February 2019
streams to dedicate resources to, the implementation SHOULD use the
information provided by the application.
3. Stream States
This section describes streams in terms of their send or receive
components. Two state machines are described: one for the streams on
which an endpoint transmits data (Section 3.1), and another for
streams on which an endpoint receives data (Section 3.2).
Unidirectional streams use the applicable state machine directly.
Bidirectional streams use both state machines. For the most part,
the use of these state machines is the same whether the stream is
unidirectional or bidirectional. The conditions for opening a stream
are slightly more complex for a bidirectional stream because the
opening of either send or receive sides causes the stream to open in
both directions.
An endpoint MUST open streams of the same type in increasing order of
stream ID.
Note: These states are largely informative. This document uses
stream states to describe rules for when and how different types
of frames can be sent and the reactions that are expected when
different types of frames are received. Though these state
machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations. An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements
these states.
3.1. Sending Stream States
Figure 1 shows the states for the part of a stream that sends data to
a peer.
Iyengar & Thomson Expires August 18, 2019 [Page 11]
Internet-Draft QUIC Transport Protocol February 2019
o
| Create Stream (Sending)
| Peer Creates Bidirectional Stream
v
+-------+
| Ready | Send RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Send STREAM / |
| STREAM_DATA_BLOCKED |
| |
| Peer Creates |
| Bidirectional Stream |
v |
+-------+ |
| Send | Send RESET_STREAM |
| |---------------------->|
+-------+ |
| |
| Send STREAM + FIN |
v v
+-------+ +-------+
| Data | Send RESET_STREAM | Reset |
| Sent |------------------>| Sent |
+-------+ +-------+
| |
| Recv All ACKs | Recv ACK
v v
+-------+ +-------+
| Data | | Reset |
| Recvd | | Recvd |
+-------+ +-------+
Figure 1: States for Sending Parts of Streams
The sending part of stream that the endpoint initiates (types 0 and 2
for clients, 1 and 3 for servers) is opened by the application. The
"Ready" state represents a newly created stream that is able to
accept data from the application. Stream data might be buffered in
this state in preparation for sending.
Sending the first STREAM or STREAM_DATA_BLOCKED frame causes a
sending part of a stream to enter the "Send" state. An
implementation might choose to defer allocating a stream ID to a
stream until it sends the first frame and enters this state, which
can allow for better stream prioritization.
Iyengar & Thomson Expires August 18, 2019 [Page 12]
Internet-Draft QUIC Transport Protocol February 2019
The sending part of a bidirectional stream initiated by a peer (type
0 for a server, type 1 for a client) enters the "Ready" state then
immediately transitions to the "Send" state if the receiving part
enters the "Recv" state (Section 3.2).
In the "Send" state, an endpoint transmits - and retransmits as
necessary - stream data in STREAM frames. The endpoint respects the
flow control limits set by its peer, and continues to accept and
process MAX_STREAM_DATA frames. An endpoint in the "Send" state
generates STREAM_DATA_BLOCKED frames if it is blocked from sending by
stream or connection flow control limits Section 4.1.
After the application indicates that all stream data has been sent
and a STREAM frame containing the FIN bit is sent, the sending part
of the stream enters the "Data Sent" state. From this state, the
endpoint only retransmits stream data as necessary. The endpoint
does not need to check flow control limits or send
STREAM_DATA_BLOCKED frames for a stream in this state.
MAX_STREAM_DATA frames might be received until the peer receives the
final stream offset. The endpoint can safely ignore any
MAX_STREAM_DATA frames it receives from its peer for a stream in this
state.
Once all stream data has been successfully acknowledged, the sending
part of the stream enters the "Data Recvd" state, which is a terminal
state.
From any of the "Ready", "Send", or "Data Sent" states, an
application can signal that it wishes to abandon transmission of
stream data. Alternatively, an endpoint might receive a STOP_SENDING
frame from its peer. In either case, the endpoint sends a
RESET_STREAM frame, which causes the stream to enter the "Reset Sent"
state.
An endpoint MAY send a RESET_STREAM as the first frame that mentions
a stream; this causes the sending part of that stream to open and
then immediately transition to the "Reset Sent" state.
Once a packet containing a RESET_STREAM has been acknowledged, the
sending part of the stream enters the "Reset Recvd" state, which is a
terminal state.
3.2. Receiving Stream States
Figure 2 shows the states for the part of a stream that receives data
from a peer. The states for a receiving part of a stream mirror only
some of the states of the sending part of the stream at the peer.
The receiving part of a stream does not track states on the sending
Iyengar & Thomson Expires August 18, 2019 [Page 13]
Internet-Draft QUIC Transport Protocol February 2019
part that cannot be observed, such as the "Ready" state. Instead,
the receiving part of a stream tracks the delivery of data to the
application, some of which cannot be observed by the sender.
o
| Recv STREAM / STREAM_DATA_BLOCKED / RESET_STREAM
| Create Bidirectional Stream (Sending)
| Recv MAX_STREAM_DATA / STOP_SENDING (Bidirectional)
| Create Higher-Numbered Stream
v
+-------+
| Recv | Recv RESET_STREAM
| |-----------------------.
+-------+ |
| |
| Recv STREAM + FIN |
v |
+-------+ |
| Size | Recv RESET_STREAM |
| Known |---------------------->|
+-------+ |
| |
| Recv All Data |
v v
+-------+ Recv RESET_STREAM +-------+
| Data |--- (optional) --->| Reset |
| Recvd | Recv All Data | Recvd |
+-------+<-- (optional) ----+-------+
| |
| App Read All Data | App Read RST
v v
+-------+ +-------+
| Data | | Reset |
| Read | | Read |
+-------+ +-------+
Figure 2: States for Receiving Parts of Streams
The receiving part of a stream initiated by a peer (types 1 and 3 for
a client, or 0 and 2 for a server) is created when the first STREAM,
STREAM_DATA_BLOCKED, or RESET_STREAM is received for that stream.
For bidirectional streams initiated by a peer, receipt of a
MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the
stream also creates the receiving part. The initial state for the
receiving part of stream is "Recv".
Iyengar & Thomson Expires August 18, 2019 [Page 14]
Internet-Draft QUIC Transport Protocol February 2019
The receiving part of a stream enters the "Recv" state when the
sending part of a bidirectional stream initiated by the endpoint
(type 0 for a client, type 1 for a server) enters the "Ready" state.
An endpoint opens a bidirectional stream when a MAX_STREAM_DATA or
STOP_SENDING frame is received from the peer for that stream.
Receiving a MAX_STREAM_DATA frame for an unopened stream indicates
that the remote peer has opened the stream and is providing flow
control credit. Receiving a STOP_SENDING frame for an unopened
stream indicates that the remote peer no longer wishes to receive
data on this stream. Either frame might arrive before a STREAM or
STREAM_DATA_BLOCKED frame if packets are lost or reordered.
Before creating a stream, all streams of the same type with lower-
numbered stream IDs MUST be created. This ensures that the creation
order for streams is consistent on both endpoints.
In the "Recv" state, the endpoint receives STREAM and
STREAM_DATA_BLOCKED frames. Incoming data is buffered and can be
reassembled into the correct order for delivery to the application.
As data is consumed by the application and buffer space becomes
available, the endpoint sends MAX_STREAM_DATA frames to allow the
peer to send more data.
When a STREAM frame with a FIN bit is received, the final size of the
stream is known (see Section 4.4). The receiving part of the stream
then enters the "Size Known" state. In this state, the endpoint no
longer needs to send MAX_STREAM_DATA frames, it only receives any
retransmissions of stream data.
Once all data for the stream has been received, the receiving part
enters the "Data Recvd" state. This might happen as a result of
receiving the same STREAM frame that causes the transition to "Size
Known". In this state, the endpoint has all stream data. Any STREAM
or STREAM_DATA_BLOCKED frames it receives for the stream can be
discarded.
The "Data Recvd" state persists until stream data has been delivered
to the application. Once stream data has been delivered, the stream
enters the "Data Read" state, which is a terminal state.
Receiving a RESET_STREAM frame in the "Recv" or "Size Known" states
causes the stream to enter the "Reset Recvd" state. This might cause
the delivery of stream data to the application to be interrupted.
It is possible that all stream data is received when a RESET_STREAM
is received (that is, from the "Data Recvd" state). Similarly, it is
possible for remaining stream data to arrive after receiving a
Iyengar & Thomson Expires August 18, 2019 [Page 15]
Internet-Draft QUIC Transport Protocol February 2019
RESET_STREAM frame (the "Reset Recvd" state). An implementation is
free to manage this situation as it chooses. Sending RESET_STREAM
means that an endpoint cannot guarantee delivery of stream data;
however there is no requirement that stream data not be delivered if
a RESET_STREAM is received. An implementation MAY interrupt delivery
of stream data, discard any data that was not consumed, and signal
the receipt of the RESET_STREAM immediately. Alternatively, the
RESET_STREAM signal might be suppressed or withheld if stream data is
completely received and is buffered to be read by the application.
In the latter case, the receiving part of the stream transitions from
"Reset Recvd" to "Data Recvd".
Once the application has been delivered the signal indicating that
the stream was reset, the receiving part of the stream transitions to
the "Reset Read" state, which is a terminal state.
3.3. Permitted Frame Types
The sender of a stream sends just three frame types that affect the
state of a stream at either sender or receiver: STREAM
(Section 19.8), STREAM_DATA_BLOCKED (Section 19.13), and RESET_STREAM
(Section 19.4).
A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or
STREAM_DATA_BLOCKED after sending a RESET_STREAM; that is, in the
terminal states and in the "Reset Sent" state. A receiver could
receive any of these three frames in any state, due to the
possibility of delayed delivery of packets carrying them.
The receiver of a stream sends MAX_STREAM_DATA (Section 19.10) and
STOP_SENDING frames (Section 19.5).
The receiver only sends MAX_STREAM_DATA in the "Recv" state. A
receiver can send STOP_SENDING in any state where it has not received
a RESET_STREAM frame; that is states other than "Reset Recvd" or
"Reset Read". However there is little value in sending a
STOP_SENDING frame in the "Data Recvd" state, since all stream data
has been received. A sender could receive either of these two frames
in any state as a result of delayed delivery of packets.
3.4. Bidirectional Stream States
A bidirectional stream is composed of sending and receiving parts.
Implementations may represent states of the bidirectional stream as
composites of sending and receiving stream states. The simplest
model presents the stream as "open" when either sending or receiving
Iyengar & Thomson Expires August 18, 2019 [Page 16]
Internet-Draft QUIC Transport Protocol February 2019
parts are in a non-terminal state and "closed" when both sending and
receiving streams are in terminal states.
Table 2 shows a more complex mapping of bidirectional stream states
that loosely correspond to the stream states in HTTP/2 [HTTP2]. This
shows that multiple states on sending or receiving parts of streams
are mapped to the same composite state. Note that this is just one
possibility for such a mapping; this mapping requires that data is
acknowledged before the transition to a "closed" or "half-closed"
state.
+-----------------------+---------------------+---------------------+
| Sending Part | Receiving Part | Composite State |
+-----------------------+---------------------+---------------------+
| No Stream/Ready | No Stream/Recv *1 | idle |
| | | |
| Ready/Send/Data Sent | Recv/Size Known | open |
| | | |
| Ready/Send/Data Sent | Data Recvd/Data | half-closed |
| | Read | (remote) |
| | | |
| Ready/Send/Data Sent | Reset Recvd/Reset | half-closed |
| | Read | (remote) |
| | | |
| Data Recvd | Recv/Size Known | half-closed (local) |
| | | |
| Reset Sent/Reset | Recv/Size Known | half-closed (local) |
| Recvd | | |
| | | |
| Reset Sent/Reset | Data Recvd/Data | closed |
| Recvd | Read | |
| | | |
| Reset Sent/Reset | Reset Recvd/Reset | closed |
| Recvd | Read | |
| | | |
| Data Recvd | Data Recvd/Data | closed |
| | Read | |
| | | |
| Data Recvd | Reset Recvd/Reset | closed |
| | Read | |
+-----------------------+---------------------+---------------------+
Table 2: Possible Mapping of Stream States to HTTP/2
Note (*1): A stream is considered "idle" if it has not yet been
created, or if the receiving part of the stream is in the "Recv"
state without yet having received any frames.
Iyengar & Thomson Expires August 18, 2019 [Page 17]
Internet-Draft QUIC Transport Protocol February 2019
3.5. Solicited State Transitions
If an endpoint is no longer interested in the data it is receiving on
a stream, it MAY send a STOP_SENDING frame identifying that stream to
prompt closure of the stream in the opposite direction. This
typically indicates that the receiving application is no longer
reading data it receives from the stream, but it is not a guarantee
that incoming data will be ignored.
STREAM frames received after sending STOP_SENDING are still counted
toward connection and stream flow control, even though these frames
will be discarded upon receipt.
A STOP_SENDING frame requests that the receiving endpoint send a
RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame
MUST send a RESET_STREAM frame if the stream is in the Ready or Send
state. If the stream is in the Data Sent state and any outstanding
data is declared lost, an endpoint SHOULD send a RESET_STREAM frame
in lieu of a retransmission.
An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but MAY use any application error
code. The endpoint that sends a STOP_SENDING frame MAY ignore the
error code carried in any RESET_STREAM frame it receives.
If the STOP_SENDING frame is received on a stream that is already in
the "Data Sent" state, an endpoint that wishes to cease
retransmission of previously-sent STREAM frames on that stream MUST
first send a RESET_STREAM frame.
STOP_SENDING SHOULD only be sent for a stream that has not been reset
by the peer. STOP_SENDING is most useful for streams in the "Recv"
or "Size Known" states.
An endpoint is expected to send another STOP_SENDING frame if a
packet containing a previous STOP_SENDING is lost. However, once
either all stream data or a RESET_STREAM frame has been received for
the stream - that is, the stream is in any state other than "Recv" or
"Size Known" - sending a STOP_SENDING frame is unnecessary.
An endpoint that wishes to terminate both directions of a
bidirectional stream can terminate one direction by sending a
RESET_STREAM, and it can encourage prompt termination in the opposite
direction by sending a STOP_SENDING frame.