draft-ietf-webtrans-overview-01.txt   draft-ietf-webtrans-overview-02.txt 
WEBTRANS V. Vasiliev WEBTRANS V. Vasiliev
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track 18 October 2020 Intended status: Standards Track 28 July 2021
Expires: 21 April 2021 Expires: 29 January 2022
The WebTransport Protocol Framework The WebTransport Protocol Framework
draft-ietf-webtrans-overview-01 draft-ietf-webtrans-overview-02
Abstract Abstract
The WebTransport Protocol Framework enables clients constrained by The WebTransport Protocol Framework enables clients constrained by
the Web security model to communicate with a remote server using a the Web security model to communicate with a remote server using a
secure multiplexed transport. It consists of a set of individual secure multiplexed transport. It consists of a set of individual
protocols that are safe to expose to untrusted applications, combined protocols that are safe to expose to untrusted applications, combined
with a model that allows them to be used interchangeably. with a model that allows them to be used interchangeably.
This document defines the overall requirements on the protocols used This document defines the overall requirements on the protocols used
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 21 April 2021. This Internet-Draft will expire on 29 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 3, line 18 skipping to change at page 3, line 18
stream between a client and a server could rely on WebSockets stream between a client and a server could rely on WebSockets
[RFC6455], a message-based protocol compatible with the Web security [RFC6455], a message-based protocol compatible with the Web security
model. However, since the abstraction it provides is a single model. However, since the abstraction it provides is a single
ordered stream of messages, it suffers from head-of-line blocking ordered stream of messages, it suffers from head-of-line blocking
(HOLB), meaning that all messages must be sent and received in order (HOLB), meaning that all messages must be sent and received in order
even if they are independent and some of them are no longer needed. even if they are independent and some of them are no longer needed.
This makes it a poor fit for latency-sensitive applications which This makes it a poor fit for latency-sensitive applications which
rely on partial reliability and stream independence for performance. rely on partial reliability and stream independence for performance.
One existing option available to Web developers are WebRTC data One existing option available to Web developers are WebRTC data
channels [I-D.ietf-rtcweb-data-channel], which provide a WebSocket- channels [RFC8831], which provide a WebSocket-like API for a peer-to-
like API for a peer-to-peer SCTP channel protected by DTLS. In peer SCTP channel protected by DTLS. In theory, it is possible to
theory, it is possible to use it for the use cases addressed by this use it for the use cases addressed by this specification. However,
specification. However, in practice, its use in non-browser-to- in practice, its use in non-browser-to-browser settings has been
browser settings has been quite low due to its dependency on ICE quite low due to its dependency on ICE (which fits poorly with the
(which fits poorly with the Web model) and userspace SCTP (which has Web model) and userspace SCTP (which has very few implementations
very few implementations available). available).
An alternative design would be to layer WebSockets over HTTP/3 An alternative design would be to layer WebSockets over HTTP/3
[I-D.ietf-quic-http] in a manner similar to how they are currently [I-D.ietf-quic-http] in a manner similar to how they are currently
layered over HTTP/2 [RFC8441]. That would avoid head-of-line layered over HTTP/2 [RFC8441]. That would avoid head-of-line
blocking and provide an ability to cancel a stream by closing the blocking and provide an ability to cancel a stream by closing the
corresponding WebSocket object. However, this approach has a number corresponding WebSocket object. However, this approach has a number
of drawbacks, which all stem primarily from the fact that of drawbacks, which all stem primarily from the fact that
semantically each WebSocket is a completely independent entity: semantically each WebSocket is a completely independent entity:
* Each new stream would require a WebSocket handshake to agree on * Each new stream would require a WebSocket handshake to agree on
application protocol used, meaning that it would take at least one application protocol used, meaning that it would take at least one
RTT to establish each new stream before the client can write to RTT to establish each new stream before the client can write to
it. it.
* Only clients can initiate streams. Server-initiated streams and * Only clients can initiate streams. Server-initiated streams and
other alternative modes of communication (such as the QUIC other alternative modes of communication (such as the QUIC
DATAGRAM frame [I-D.pauly-quic-datagram]) are not available. DATAGRAM frame [I-D.ietf-quic-datagram]) are not available.
* While the streams would normally be pooled by the user agent, this * While the streams would normally be pooled by the user agent, this
is not guaranteed, and the general process of mapping a WebSocket is not guaranteed, and the general process of mapping a WebSocket
to a server is opaque to the client. This introduces to a server is opaque to the client. This introduces
unpredictable performance properties into the system, and prevents unpredictable performance properties into the system, and prevents
optimizations which rely on the streams being on the same optimizations which rely on the streams being on the same
connection (for instance, it might be possible for the client to connection (for instance, it might be possible for the client to
request different retransmission priorities for different streams, request different retransmission priorities for different streams,
but that would be much more complex unless they are all on the but that would be much more complex unless they are all on the
same connection). same connection).
skipping to change at page 4, line 24 skipping to change at page 4, line 24
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
WebTransport is a framework that aims to abstract away the underlying WebTransport is a framework that aims to abstract away the underlying
transport protocol while still exposing a few key transport-layer transport protocol while still exposing a few key transport-layer
aspects to application developers. It is structured around the aspects to application developers. It is structured around the
following concepts: following concepts:
Transport session: A transport session is a single communication WebTransport session: A WebTransport session is a single
context established between a client and a server. It may communication context established between a client and a server.
correspond to a specific transport-layer connection, or it may be It may correspond to a specific transport-layer connection, or it
a logical entity within an existing multiplexed transport-layer may be a logical entity within an existing multiplexed transport-
connection. Transport sessions are logically independent from one layer connection. Transport sessions are logically independent
another even if some sessions can share an underlying transport- from one another even if some sessions can share an underlying
layer connection. transport-layer connection.
Transport protocol: A transport protocol (WebTransport protocol in WebTransport protocol: A WebTransport protocol is a specific
contexts where this might be ambiguous) is an instantiation of protocol that can be used to establish a WebTransport session.
WebTransport over a given transport-layer protocol.
Datagram: A datagram is a unit of transmission that is treated Datagram: A datagram is a unit of transmission that is treated
atomically. atomically.
Stream: A stream is a sequence of bytes that is reliably delivered Stream: A stream is a sequence of bytes that is reliably delivered
to the receiving application in the same order as it was to the receiving application in the same order as it was
transmitted by the sender. Streams can be of arbitrary length, transmitted by the sender. Streams can be of arbitrary length,
and therefore cannot always be buffered entirely in memory. It is and therefore cannot always be buffered entirely in memory.
expected for transport protocols and APIs to provide partial WebTransport protocols and APIs are expected to provide partial
stream data to the application before the stream has been entirely stream data to the application before the stream has been entirely
received. received.
Message: A message is a stream that is sufficiently small that it Message: A message is a stream that is sufficiently small that it
can be fully buffered before being passed to the application. can be fully buffered before being passed to the application.
WebTransport does not define messages as a primitive, since from WebTransport does not define messages as a primitive, since from
the transport perspective they can be simulated by fully buffering the transport perspective they can be simulated by fully buffering
a stream before passing it to the application. However, this a stream before passing it to the application. However, this
distinction is important to highlight since some of the similar distinction is important to highlight since some of the similar
protocols and APIs (notably WebSocket [RFC6455]) use messages as a protocols and APIs (notably WebSocket [RFC6455]) use messages as a
core abstraction. core abstraction.
Transport property: A transport property is a specific behavior that Transport property: A transport property is a specific behavior that
may or may not be exhibited by a transport. Some of those are may or may not be exhibited by a WebTransport protocol. Some of
inherent for all instances of a given transport protocol (TCP- those are inherent for all instances of a given transport protocol
based transport cannot support unreliable delivery), while others (TCP-based transport cannot support unreliable delivery), while
can vary even within the same protocol (QUIC connections may or others can vary even within the same protocol (QUIC connections
may not support connection migration). may or may not support connection migration).
Server: A WebTransport server is an application that accepts Server: A WebTransport server is an application that accepts
incoming transport sessions. incoming WebTransport sessions.
Client: A WebTransport client is an application that initiates the Client: A WebTransport client is an application that initiates the
transport session and may be running in a constrained security transport session and may be running in a constrained security
context, for instance, a JavaScript application running inside a context, for instance, a JavaScript application running inside a
browser. browser.
User agent: A WebTransport user agent is a software system that has User agent: A WebTransport user agent is a software system that has
an unrestricted access to the host network stack and can create an unrestricted access to the host network stack and can create
transports on behalf of the client. transports on behalf of the client.
2. Common Transport Requirements 2. Common Transport Requirements
Since clients are not necessarily trusted and have to be constrained Since clients are not necessarily trusted and have to be constrained
by the Web security model, WebTransport imposes certain requirements by the Web security model, WebTransport imposes certain requirements
on any specific transport protocol used. on any specific protocol used.
Any transport protocol used MUST use TLS [RFC8446] or a semantically Any WebTransport protocol MUST use TLS [RFC8446] or a semantically
equivalent security protocol (for instance, DTLS equivalent security protocol (for instance, DTLS
[I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or [I-D.ietf-tls-dtls13]). The protocols SHOULD use TLS version 1.3 or
later, unless they aim for backwards compatibility with legacy later, unless they aim for backwards compatibility with legacy
systems. systems.
Any transport protocol used MUST require the user agent to obtain and Any WebTransport protocol MUST require the user agent to obtain and
maintain explicit consent from the server to send data. For maintain explicit consent from the server to send data. For
connection-oriented protocols (such as TCP or QUIC), the connection connection-oriented protocols (such as TCP or QUIC), the connection
establishment and keep-alive mechanisms suffice. STUN Consent establishment and keep-alive mechanisms suffice. STUN Consent
Freshness [RFC7675] is another example of the mechanism satisfying Freshness [RFC7675] is another example of the mechanism satisfying
this requirement. this requirement.
Any transport protocol used MUST limit the rate at which the client Any WebTransport protocol MUST limit the rate at which the client
sends data. This SHOULD be accomplished via a feedback-based sends data. This SHOULD be accomplished via a feedback-based
congestion control mechanism (such as [RFC5681] or congestion control mechanism (such as [RFC5681] or [RFC9002]).
[I-D.ietf-quic-recovery]).
Any transport protocol used MUST support simultaneously establishing Any WebTransport protocol MUST support simultaneously establishing
multiple sessions between the same client and server. multiple sessions between the same client and server.
Any transport protocol used MUST prevent the clients from Any WebTransport protocol MUST prevent the clients from establishing
establishing transport sessions to network endpoints that are not transport sessions to network endpoints that are not WebTransport
WebTransport servers. servers.
Any transport protocol used MUST provide a way for servers to filter Any WebTransport protocol MUST provide a way for servers to filter
clients that can access it by checking the initiating origin clients that can access it by checking the initiating origin
[RFC6454]. [RFC6454].
Any transport protocol used MUST provide a way for a server endpoint Any WebTransport protocol MUST provide a way for a server endpoint
location to be described using a URI [RFC3986]. This enables location to be described using a URI [RFC3986]. This enables
integration with various Web platform features that represent integration with various Web platform features that represent
resources as URIs, such as Content Security Policy [CSP]. resources as URIs, such as Content Security Policy [CSP].
3. Session Establishment 3. Session Establishment
WebTransport session establishment is most often asynchronous, WebTransport session establishment is most often asynchronous,
although in some transports it can succeed instantaneously (for although in some transports it can succeed instantaneously (for
instance, if a transport is immediately pooled with an existing instance, if a transport is immediately pooled with an existing
connection). A session MUST NOT be considered established until it connection). A session MUST NOT be considered established until it
is secure against replay attacks. For instance, in protocols is secure against replay attacks. For instance, in protocols
creating a new TLS 1.3 session [RFC8446], this would mean that the creating a new TLS 1.3 session [RFC8446], this would mean that the
user agent MUST NOT treat the session as established until it user agent MUST NOT treat the session as established until it
received a Finished message from the server. received a Finished message from the server.
In some cases, the transport protocol might allow transmitting data In some cases, a WebTransport protocol might allow transmitting data
before the session is established; an example is TLS 0-RTT data. before the session is established; an example is TLS 0-RTT data.
Since this data can be replayed by attackers, it MUST NOT be used Since this data can be replayed by attackers, it MUST NOT be used
unless the client has explicitly requested 0-RTT for specific streams unless the client has explicitly requested 0-RTT for specific streams
or datagrams it knows to be safely replayable. or datagrams it knows to be safely replayable.
4. Transport Features 4. Transport Features
The following transport features are defined in this document. This The following transport features are defined in this document. This
list is not meant to be comprehensive; future documents may define list is not meant to be comprehensive; future documents may define
new features for both new and already existing transports. new features for both new and already existing transports.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
performing path MTU discovery. performing path MTU discovery.
4.2. Streams 4.2. Streams
A unidirectional stream is a one-way reliable in-order stream of A unidirectional stream is a one-way reliable in-order stream of
bytes where the initiator is the only endpoint that can send data. A bytes where the initiator is the only endpoint that can send data. A
bidirectional stream allows both endpoints to send data and can be bidirectional stream allows both endpoints to send data and can be
conceptually represented as a pair of unidirectional streams. conceptually represented as a pair of unidirectional streams.
The streams are in general expected to follow the semantics and the The streams are in general expected to follow the semantics and the
state machine of QUIC streams ([I-D.ietf-quic-transport], Sections 2 state machine of QUIC streams ([RFC9000], Sections 2 and 3). TODO:
and 3). TODO: describe the stream state machine explicitly. describe the stream state machine explicitly.
A WebTransport stream can be reset, indicating that the endpoint is A WebTransport stream can be reset, indicating that the endpoint is
not interested in either sending or receiving any data related to the not interested in either sending or receiving any data related to the
stream. In that case, the sender is expected to not retransmit any stream. In that case, the sender is expected to not retransmit any
data that was already sent on that stream. data that was already sent on that stream.
Streams SHOULD be sufficiently lightweight that they can be used as Streams SHOULD be sufficiently lightweight that they can be used as
messages. messages.
Data sent on a stream is flow controlled by the transport protocol. Data sent on a stream is flow controlled by the transport protocol.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
There are no requests to IANA in this document. There are no requests to IANA in this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://doi.org/10.17487/RFC2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://doi.org/10.17487/RFC3986>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://doi.org/10.17487/RFC6454>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://doi.org/10.17487/RFC8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://doi.org/10.17487/RFC8446>.
9.2. Informative References 9.2. Informative References
[CSP] W3C, "Content Security Policy Level 3", October 2020, [CSP] W3C, "Content Security Policy Level 3", July 2021,
<https://www.w3.org/TR/CSP/>. <https://www.w3.org/TR/CSP/>.
[I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-03, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-03>.
[I-D.ietf-quic-http] [I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-31, 24 September 2020, <http://www.ietf.org/ quic-http-34, 2 February 2021,
internet-drafts/draft-ietf-quic-http-31.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
[I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-31, 24 September 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
recovery-31.txt>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-31, 24 September 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-31.txt>.
[I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", Work in Progress, Internet-Draft, draft-ietf-
rtcweb-data-channel-13, 4 January 2015,
<http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-
data-channel-13.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-38, 29 May 2020, <http://www.ietf.org/internet- dtls13-43, 30 April 2021,
drafts/draft-ietf-tls-dtls13-38.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
dtls13-43>.
[I-D.pauly-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-pauly-quic-datagram-05, 4 November 2019,
<http://www.ietf.org/internet-drafts/draft-pauly-quic-
datagram-05.txt>.
[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, DOI 10.17487/RFC0896, January 1984, RFC 896, DOI 10.17487/RFC0896, January 1984,
<https://www.rfc-editor.org/info/rfc896>. <https://doi.org/10.17487/RFC0896>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://doi.org/10.17487/RFC5681>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://doi.org/10.17487/RFC6455>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>. October 2015, <https://doi.org/10.17487/RFC7675>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018, RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/info/rfc8441>. <https://doi.org/10.17487/RFC8441>.
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://doi.org/10.17487/RFC8831>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://doi.org/10.17487/RFC9000>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://doi.org/10.17487/RFC9002>.
Author's Address Author's Address
Victor Vasiliev Victor Vasiliev
Google Google
Email: vasilvv@google.com Email: vasilvv@google.com
 End of changes. 36 change blocks. 
89 lines changed or deleted 81 lines changed or added

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