draft-ietf-quic-transport-02.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: September 14, 2017 Mozilla Expires: September 25, 2017 Mozilla
March 13, 2017 March 24, 2017
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-02 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on September 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 62, line 32 skipping to change at page 62, line 32
15.1. Normative References 15.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-19 (work in progress), Version 1.3", draft-ietf-tls-tls13-19 (work in progress),
March 2017. March 2017.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control". and Congestion Control", draft-ietf-quic-recovery-latest
(work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC". Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 65, line 7 skipping to change at page 65, line 7
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
o Narrow the packet number encoding range requirement (#67, #286, o Narrow the packet number encoding range requirement (#67, #286,
#299, #323, #356) #299, #323, #356)
o Defined client address validation (#52, #118, #120, #275) o Defined client address validation (#52, #118, #120, #275)
o Define transport parameters as a TLS extension (#122) o Define transport parameters as a TLS extension (#49, #122)
o SCUP and COPT parameters are no longer valid (#116, #117) o SCUP and COPT parameters are no longer valid (#116, #117)
o Transport parameters for 0-RTT are either remembered from before, o Transport parameters for 0-RTT are either remembered from before,
or assume default values (#126) or assume default values (#126)
o The server chooses connection IDs in its final flight (#119, #349, o The server chooses connection IDs in its final flight (#119, #349,
#361) #361)
o The server echoes the Connection ID and packet number fields when o The server echoes the Connection ID and packet number fields when
sending a Version Negotiation packet (#133, #295, #244) sending a Version Negotiation packet (#133, #295, #244)
o Definied a minimum packet size for the initial handshake packet o Defined a minimum packet size for the initial handshake packet
from the client (#69, #136, #139, #164) from the client (#69, #136, #139, #164)
o Path MTU Discovery (#64, #106) o Path MTU Discovery (#64, #106)
o The initial handshake packet from the client needs to fit in a o The initial handshake packet from the client needs to fit in a
single packet (#338) single packet (#338)
o Forbid acknowledgment of packets containing only ACK and PADDING o Forbid acknowledgment of packets containing only ACK and PADDING
(#291) (#291)
skipping to change at page 66, line 10 skipping to change at page 66, line 10
o Forbid the use of Public Reset where CONNECTION_CLOSE is possible o Forbid the use of Public Reset where CONNECTION_CLOSE is possible
(#289) (#289)
o Define packet protection rules (#336) o Define packet protection rules (#336)
o Require that stream be entirely delivered or reset, including o Require that stream be entirely delivered or reset, including
acknowledgment of all STREAM frames or the RST_STREAM, before it acknowledgment of all STREAM frames or the RST_STREAM, before it
closes (#381) closes (#381)
o Remove stream reservation from state machine (#174, #280) o Remove stream reservation from state machine (#174, #280)
o Only stream 0 does not contributing to connection-level flow o Only stream 1 does not contribute to connection-level flow control
control (#204) (#204)
o Stream 1 counts towards the maximum concurrent stream limit (#201, o Stream 1 counts towards the maximum concurrent stream limit (#201,
#282) #282)
o Remove connection-level flow control exclusion for some streams o Remove connection-level flow control exclusion for some streams
(except 1) (#246) (except 1) (#246)
o RST_STREAM affects connection-level flow control (#162, #163) o RST_STREAM affects connection-level flow control (#162, #163)
o Flow control accounting uses the maximum data offset on each o Flow control accounting uses the maximum data offset on each
 End of changes. 8 change blocks. 
10 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/