draft-ietf-webtrans-overview-02.txt   draft-ietf-webtrans-overview-03.txt 
WEBTRANS V. Vasiliev WEBTRANS V. Vasiliev
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track 28 July 2021 Intended status: Standards Track 7 March 2022
Expires: 29 January 2022 Expires: 8 September 2022
The WebTransport Protocol Framework The WebTransport Protocol Framework
draft-ietf-webtrans-overview-02 draft-ietf-webtrans-overview-03
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 29 January 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are 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 Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. Common Transport Requirements . . . . . . . . . . . . . . . . 5 2. Common Transport Requirements . . . . . . . . . . . . . . . . 5
3. Session Establishment . . . . . . . . . . . . . . . . . . . . 6 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 6
4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6 4. Transport Features . . . . . . . . . . . . . . . . . . . . . 6
4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Datagrams . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Protocol-Specific Features . . . . . . . . . . . . . . . 8 5. Transport Properties . . . . . . . . . . . . . . . . . . . . 7
4.4. Bandwidth Prediction . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Buffering and Prioritization . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Transport Properties . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
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 3, line 26 skipping to change at page 3, line 26
One existing option available to Web developers are WebRTC data One existing option available to Web developers are WebRTC data
channels [RFC8831], which provide a WebSocket-like API for a peer-to- channels [RFC8831], which provide a WebSocket-like API for a peer-to-
peer SCTP channel protected by DTLS. In theory, it is possible to peer SCTP channel protected by DTLS. In theory, it is possible to
use it for the use cases addressed by this specification. However, use it for the use cases addressed by this specification. However,
in practice, its use in non-browser-to-browser settings has been in practice, its use in non-browser-to-browser settings has been
quite low due to its dependency on ICE (which fits poorly with the quite low due to its dependency on ICE (which fits poorly with the
Web model) and userspace SCTP (which has very few implementations Web model) and userspace SCTP (which has very few implementations
available). available).
An alternative design would be to layer WebSockets over HTTP/3 An alternative design would be to open multiple WebSocket connections
[I-D.ietf-quic-http] in a manner similar to how they are currently over HTTP/3 [I-D.ietf-httpbis-h3-websockets] in a manner similar to
layered over HTTP/2 [RFC8441]. That would avoid head-of-line how they are currently layered over HTTP/2 [RFC8441]. That would
blocking and provide an ability to cancel a stream by closing the avoid head-of-line blocking and provide an ability to cancel a stream
corresponding WebSocket object. However, this approach has a number by closing the corresponding WebSocket object. However, this
of drawbacks, which all stem primarily from the fact that approach has a number of drawbacks, which all stem primarily from the
semantically each WebSocket is a completely independent entity: fact that 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.ietf-quic-datagram]) are not available. DATAGRAM frame [I-D.ietf-quic-datagram]) are not available.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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
may or may not be exhibited by a WebTransport protocol. Some of
those are inherent for all instances of a given transport protocol
(TCP-based transport cannot support unreliable delivery), while
others can vary even within the same protocol (QUIC connections
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 WebTransport 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 protocol used. on any specific protocol used.
Any WebTransport protocol MUST use TLS [RFC8446] or a semantically All WebTransport protocols 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 WebTransport protocol MUST require the user agent to obtain and All WebTransport protocols 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 a mechanism satisfying this
this requirement. requirement.
Any WebTransport protocol MUST limit the rate at which the client All WebTransport protocols 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 [RFC9002]). congestion control mechanism (such as [RFC5681] or [RFC9002]).
Any WebTransport protocol MUST support simultaneously establishing All WebTransport protocols MUST support simultaneously establishing
multiple sessions between the same client and server. multiple sessions between the same client and server.
Any WebTransport protocol MUST prevent the clients from establishing All WebTransport protocols MUST prevent clients from establishing
transport sessions to network endpoints that are not WebTransport transport sessions to network endpoints that are not WebTransport
servers. servers.
Any WebTransport protocol MUST provide a way for servers to filter All WebTransport protocols MUST provide a way for the user agent to
clients that can access it by checking the initiating origin indicate the origin [RFC6454] of the client to the server.
[RFC6454].
Any WebTransport protocol MUST provide a way for a server endpoint All WebTransport protocols 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 an asynchronous process. A
although in some transports it can succeed instantaneously (for session is considered _ready_ from the client's perspective when the
instance, if a transport is immediately pooled with an existing server has confirmed that it is willing to accept the session with
connection). A session MUST NOT be considered established until it the provided origin and URI. WebTransport protocols MAY allow
is secure against replay attacks. For instance, in protocols clients to send data before the session is ready; however, they MUST
creating a new TLS 1.3 session [RFC8446], this would mean that the NOT use mechanisms that are unsafe against replay attacks without an
user agent MUST NOT treat the session as established until it explicit indication from the client.
received a Finished message from the server.
In some cases, a WebTransport protocol might allow transmitting 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
unless the client has explicitly requested 0-RTT for specific streams
or datagrams it knows to be safely replayable.
4. Transport Features 4. Transport Features
The following transport features are defined in this document. This
list is not meant to be comprehensive; future documents may define
new features for both new and already existing transports.
All transport protocols MUST provide datagrams, unidirectional and All transport protocols MUST provide datagrams, unidirectional and
bidirectional streams in order to make the transport protocols easily bidirectional streams in order to make the transport protocols
interchangeable. interchangeable.
4.1. Datagrams 4.1. Datagrams
A datagram is a sequence of bytes that is limited in size (generally A datagram is a sequence of bytes that is limited in size (generally
to the path MTU) and is not expected to be transmitted reliably. The to the path MTU) and is not expected to be transmitted reliably. The
general goal for WebTransport datagrams is to be similar in behavior general goal for WebTransport datagrams is to be similar in behavior
to UDP while being subject to common requirements expressed in to UDP while being subject to common requirements expressed in
Section 2. Section 2.
The WebTransport sender is not expected to retransmit datagrams, A WebTransport sender is not expected to retransmit datagrams, though
though it may if it is using a TCP-based protocol or some other it may end up doing so if it is using a TCP-based protocol or some
underlying protocol that requires reliable delivery. WebTransport other underlying protocol that only provides reliable delivery.
datagrams are not expected to be flow controlled, meaning that the WebTransport datagrams are not expected to be flow controlled,
receiver might drop datagrams if the application is not consuming meaning that the receiver might drop datagrams if the application is
them fast enough. not consuming them fast enough.
The application MUST be provided with the maxiumum datagram size that The application MUST be provided with the maximum datagram size that
it can send. The size SHOULD be derived from the result of it can send. The size SHOULD be derived from the result of
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.
skipping to change at page 7, line 49 skipping to change at page 7, line 30
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.
In addition to flow controlling stream data, the creation of new In addition to flow controlling stream data, the creation of new
streams is flow controlled as well: an endpoint may only open a streams is flow controlled as well: an endpoint may only open a
limited number of streams until the peer explicitly allows creating limited number of streams until the peer explicitly allows creating
more streams. more streams.
Every stream within a transport has a unique 64-bit number 5. Transport Properties
identifying it. Both unidirectional and bidirectional streams share
the number space. The client and the server have to agree on the
numbering, so it can be referenced in the application payload.
WebTransport does not impose any other specific restrictions on the
structure of stream IDs, and they should be treated as opaque 64-bit
blobs.
4.3. Protocol-Specific Features
In addition to features described above, there are some capabilities
that may be provided by an individual protocol but are not
universally applicable to all protocols. Those are allowed, but any
protocol is expected to be useful without those features, and
portable clients should not rely on them.
A notable class of protocol-specific features are features available
only in non-pooled transports. Since those transports have a
dedicated connection, a user agent can provide clients with an
extensive amount of transport-level data that would be too noisy and
difficult to interpret when the connection is shared with unrelated
traffic. For instance, a user agent can provide the number of
packets lost, or the number of times stream data was delayed due to
flow control. It can also expose variables related to congestion
control, such as the size of the congestion window or the current
pacing rate.
4.4. Bandwidth Prediction
Using congestion control state and transport metrics, the client can
predict the rate at which it can send data. That is essential for
many WebTransport use cases; for instance, real time media
applications adapt the video bitrate to be a fraction of the
throughput they expect to be available. While not all transport
protocols can provide low-level transport details, all protocols
SHOULD provide the client with an estimate of the available
bandwidth.
5. Buffering and Prioritization
TODO: expand this outline into a full summary.
* Datagrams are intended for low-latency communications, so the
buffers for them should be small, and prioritized over stream
data.
* In general, the transport should not apply aggregation algorithms
(e.g., Nagle's algorithm [RFC0896]) to datagrams.
6. Transport Properties
In addition to common requirements, each transport can have multiple
optional properties associated with it. Querying them allows the
client to ascertain the presence of features it can use without
requiring knowledge of all protocols. This allows introducing new
transports as drop-in replacements for existing ones.
The following properties are defined in this specification: WebTransport defines common semantics for multiple protocols to allow
them to be used interchangeably. Nevertheless, those protocols still
have substantially different performance properties that an
application may want to query.
* Stream independence. This indicates that there is no head of line The most notable property is support for unreliable data delivery.
blocking between different streams. The protocol is defined to support unreliable delivery if:
* Partial reliability. This indicates that if a stream is reset, * Resetting a stream results in the lost stream data no longer being
none of the data sent on it will be retransmitted. This also retransmitted, and
indicates that datagrams will not be retransmitted.
* Pooling support. Indicates that multiple transports using this * The datagrams are never retransmitted.
transport protocol may end up sharing the same transport layer
connection, and thus share a congestion controller and other
contexts.
* Connection mobility. Indicates that the transport may continue Another important property is pooling support. Pooling means that
existing even if the network path between the client and the multiple transport sessions may end up sharing the same transport
server changes. layer connection, and thus share a congestion controller and other
contexts.
7. Security Considerations 6. Security Considerations
Providing untrusted clients with a reasonably low-level access to the Providing untrusted clients with a reasonably low-level access to the
network comes with risks. This document mitigates those risks by network comes with risks. This document mitigates those risks by
imposing a set of common requirements described in Section 2. imposing a set of common requirements described in Section 2.
WebTransport mandates the use of TLS for all protocols implementing WebTransport mandates the use of TLS for all protocols implementing
it. This has a dual purpose. On one hand, it protects the transport it. This has a dual purpose. On one hand, it protects the transport
from the network, including both potential attackers and ossification from the network, including both potential attackers and ossification
by middleboxes. On the other hand, it protects the network elements by middleboxes. On the other hand, it protects the network elements
from potential confusion attacks such as the one discussed in from potential confusion attacks such as the one discussed in
skipping to change at page 10, line 11 skipping to change at page 8, line 34
example, the client must not be able to distinguish between a network example, the client must not be able to distinguish between a network
address that is unreachable and one that is reachable but is not a address that is unreachable and one that is reachable but is not a
WebTransport server. WebTransport server.
WebTransport does not support any traditional means of HTTP-based WebTransport does not support any traditional means of HTTP-based
authentication. It is not necessarily based on HTTP, and hence does authentication. It is not necessarily based on HTTP, and hence does
not support HTTP cookies or HTTP authentication. Since it requires not support HTTP cookies or HTTP authentication. Since it requires
TLS, individual transport protocols MAY expose TLS-based TLS, individual transport protocols MAY expose TLS-based
authentication capabilities such as client certificates. authentication capabilities such as client certificates.
8. IANA Considerations 7. IANA Considerations
There are no requests to IANA in this document. There are no requests to IANA in this document.
9. References 8. References
9.1. Normative References 8.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://doi.org/10.17487/RFC2119>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC3986>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC6454>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC8174>. May 2017, <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
9.2. Informative References 8.2. Informative References
[CSP] W3C, "Content Security Policy Level 3", July 2021, [CSP] W3C, "Content Security Policy Level 3", March 2022,
<https://www.w3.org/TR/CSP/>. <https://www.w3.org/TR/CSP/>.
[I-D.ietf-httpbis-h3-websockets]
Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work
in Progress, Internet-Draft, draft-ietf-httpbis-h3-
websockets-04, 8 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
h3-websockets-04>.
[I-D.ietf-quic-datagram] [I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet- Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-03, 12 July 2021, Draft, draft-ietf-quic-datagram-10, 4 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-03>.
[I-D.ietf-quic-http]
Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. datagram-10>.
[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-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
dtls13-43>. dtls13-43>.
[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, DOI 10.17487/RFC0896, January 1984,
<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://doi.org/10.17487/RFC5681>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC6455>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC7675>. October 2015, <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC8441>. <https://www.rfc-editor.org/rfc/rfc8441>.
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://doi.org/10.17487/RFC8831>. <https://www.rfc-editor.org/rfc/rfc8831>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://doi.org/10.17487/RFC9000>. <https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://doi.org/10.17487/RFC9002>. May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
Author's Address Author's Address
Victor Vasiliev Victor Vasiliev
Google Google
Email: vasilvv@google.com Email: vasilvv@google.com
 End of changes. 51 change blocks. 
172 lines changed or deleted 90 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/