draft-aboba-avtcore-quic-multiplexing-01.txt | draft-aboba-avtcore-quic-multiplexing-02.txt | |||
---|---|---|---|---|
AVTCORE Working Group B. Aboba | AVTCORE Working Group B. Aboba | |||
INTERNET-DRAFT Microsoft Corporation | INTERNET-DRAFT Microsoft Corporation | |||
Category: Informational P. Thatcher | Category: Informational P. Thatcher | |||
Expires: April 29, 2018 Google | Expires: April 23, 2019 Google | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
29 October 2017 | 23 October 2018 | |||
QUIC Multiplexing | QUIC Multiplexing | |||
draft-aboba-avtcore-quic-multiplexing-01.txt | draft-aboba-avtcore-quic-multiplexing-02.txt | |||
Abstract | Abstract | |||
If QUIC is to be used in a peer-to-peer manner, with NAT traversal, | If QUIC is to be used in a peer-to-peer manner, with NAT traversal, | |||
then it is necessary to be able to demultiplex QUIC and STUN flows | then it is necessary to be able to demultiplex QUIC and other | |||
running on a single UDP port. This memo discusses options for how to | protocols used in WebRTC on a single UDP port. This memo discusses | |||
perform such demultiplexing. It also considers demultiplexing of | options for demultiplexing. | |||
QUIC and WebRTC traffic (both media and data) when running on a | ||||
single UDP port. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 April 29, 2018. | This Internet-Draft will expire on April 23, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. QUIC Header Changes . . . . . . . . . . . . . . . . . . . 4 | 2.1. Subsequent changes . . . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Multiplexing Shim . . . . . . . . . . . . . . . . . . . . 5 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5.1. Informative references . . . . . . . . . . . . . . . . . . 5 | |||
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.1. Informative references . . . . . . . . . . . . . . . . . . 7 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
1. Introduction | 1. Introduction | |||
QUIC [I-D.ietf-quic-transport] is a new network transport protocol. | QUIC [I-D.ietf-quic-transport] is a new network transport protocol. | |||
While it is initially intended as a replacement for TCP in order to | While it is initially intended as a replacement for TCP in order to | |||
better support HTTP/2 [RFC7540] it should eventually be useful as a | better support HTTP/2 [RFC7540] it should eventually be useful as a | |||
general purpose transport. HTTP is an asymmetric client-server | general purpose transport. HTTP is an asymmetric client-server | |||
protocol, but other uses of QUIC might operate in a peer-to-peer | protocol, but other uses of QUIC might operate in a peer-to-peer | |||
manner and so will need effective NAT traversal using ICE [RFC5245], | manner and so will need effective NAT traversal using ICE [RFC5245], | |||
which which makes use of STUN [RFC5389] and TURN [RFC5766] to | which which makes use of STUN [RFC5389] and TURN [RFC5766] to | |||
discover NAT bindings. This STUN and TURN traffic needs to run on | discover NAT bindings. Therefore for QUIC to be utilized for peer- | |||
the same UDP port as the QUIC traffic. Accordingly, if QUIC is to be | to-peer data transport, QUIC and STUN must be able to multiplex on | |||
used in a peer-to-peer manner, then it needs to be possible to | the same port. | |||
demultiplex QUIC, STUN, and TURN traffic running on a single UDP | ||||
port. This memo discusses how to do this. | ||||
In addition, there are a number of ways in which communication | In a WebRTC scenario where RTP is used to transport audio and video | |||
between WebRTC peers may utilize QUIC. One of these is transport of | and QUIC is used for data exchange, SRTP [RFC3711] is keyed using | |||
RTP over QUIC, described in [I-D.rtpfolks-quic-rtp-over-quic]. | DTLS-SRTP [RFC5764] and therefore SRTP/SRTCP [RFC3550], STUN, TURN, | |||
Another is use of QUIC for data exchange. A Javascript API for use of | DTLS [RFC6347] and QUIC will need to be multiplexed on the same port. | |||
QUIC in WebRTC data exchange has been incorporated into the ORTC API | ||||
[ORTC], under development within the W3C ORTC Community Group. | ||||
In a WebRTC scenario where ICE is utilized for NAT traversal, SRTP | Within the W3C, a Javascript API for the use of QUIC for peer-to-peer | |||
[RFC3711] is keyed using DTLS-SRTP [RFC5764] and QUIC is used for | data exchange [WEBRTC-QUIC] is under development within the ORTC | |||
data exchange, RTP/RTCP [RFC3550], STUN, TURN, DTLS [RFC6347], ZRTP | Community Group. | |||
[RFC6189] and QUIC may all need to be multiplexed over a single ICE | ||||
transport. | ||||
As noted in [RFC7983] Figure 3, protocol demultiplexing currently | As noted in [RFC7983] Figure 3, protocol demultiplexing currently | |||
relies upon differentiation based on the first octet, as follows: | relies upon differentiation based on the first octet, as follows: | |||
+----------------+ | +----------------+ | |||
| [0..3] -+--> forward to STUN | | [0..3] -+--> forward to STUN | |||
| | | | | | |||
| [16..19] -+--> forward to ZRTP | | [16..19] -+--> forward to ZRTP | |||
| | | | | | |||
packet --> | [20..63] -+--> forward to DTLS | packet --> | [20..63] -+--> forward to DTLS | |||
| | | | | | |||
| [64..79] -+--> forward to TURN Channel | | [64..79] -+--> forward to TURN Channel | |||
| | | | | | |||
| [128..191] -+--> forward to RTP/RTCP | | [128..191] -+--> forward to RTP/RTCP | |||
+----------------+ | +----------------+ | |||
Figure 1: DTLS-SRTP receiver's packet demultiplexing algorithm. | Figure 1: RFC 7983 packet demultiplexing algorithm. | |||
As noted by Colin Perkins and Lars Eggert in [QUIC-Issue] this | As noted by Colin Perkins and Lars Eggert in [QUIC-Issue] this | |||
creates a potential conflict with the current design of the QUIC | created a potential conflict with the design of the QUIC headers | |||
headers described in [I-D.ietf-quic-transport], since the first octet | described in versions of [I-D.ietf-quic-transport] prior to -08. | |||
of the QUIC header is either: | ||||
+-+-+-+-+-+-+-+-+ | ||||
|1| Type (7) | Long header packet | ||||
+-+-+-+-+-+-+-+-+ | ||||
which potentially produces values of the first octet in the range | ||||
129-134, conflicting with RTP/RTCP, or | ||||
+-+-+-+-+-+-+-+-+ | ||||
|0|C|K| Type (5)| Short header packet | ||||
+-+-+-+-+-+-+-+-+ | ||||
which produces values for the first octet in the ranges 1-3, 33-35, | ||||
65-67 or 97-99, potentially conflicting with STUN, DTLS and TURN. | ||||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
2. Solutions | 2. Solution | |||
This section presents potential solutions to the QUIC multiplexing | ||||
problem, including changes to the QUIC headers, addition of a | ||||
multiplexing octet and use of heuristics. | ||||
2.1. QUIC Header Changes | ||||
As noted in [QUIC-Issue], one potential solution involves changes to | At IETF 100, Colin Perkins presented a demultiplexing proposal [QUIC- | |||
the QUIC headers, such as setting the top two bits of the first octet | MULTI]. The proposal which was subsequently proposed as a Pull | |||
of a QUIC packet to 1. This would imply a reduction in the size of | Request to the QUIC Transport specification and merged in draft-ietf- | |||
the type fields: | quic-transport-08, involved renumbering of the QUIC long header | |||
packet type field as well as inverting the sense of the "C" bit in | ||||
the short header packet. | ||||
+-+-+-+-+-+-+-+-+ | The demultiplexing algorithm resulting from the changes appears as | |||
|1|1|1|Type (5) | Long header packet | follows: | |||
+-+-+-+-+-+-+-+-+ | ||||
+-+-+-+-+-+-+-+-+ | +----------------+ | |||
|1|1|0|C|K|Type3| Short header packet | | [0..3] -+--> forward to STUN | |||
+-+-+-+-+-+-+-+-+ | | | | |||
| [16..19] -+--> forward to ZRTP | ||||
| | | ||||
packet --> | [20..63] -+--> forward to DTLS | ||||
| | | ||||
| [64..79] -+--> forward to TURN Channel | ||||
| [64..127] -+--> forward to QUIC (Short Header) | ||||
| | | ||||
| [128..191] -+--> forward to RTP/RTCP | ||||
| [250..255] +--> forward to QUIC (Long Header) | ||||
+----------------+ | ||||
Note: [QUIC-Spin] proposes to add a spin bit to the type octet within | Figure 2: Revised packet demultiplexing algorithm. | |||
the QUIC header, in order to allow for RTT calculation. This would | ||||
leave 4 bits for the type field in the long header packet and 2 bits | ||||
for the type field in the short header, which would accommodate the | ||||
type field values allocated in [I-D.ietf-quic-transport]. | ||||
The advantage to this approach is that it adds no additional | Note that while the above diagram has a potential conflict between | |||
overhead on-the-wire. However it does require a reduction in the | packets sent in TURN Channels and the QUIC short header, this | |||
size of the QUIC Type fields and could potentially require | conflict is not considered serious for WebRTC where TURN Channels are | |||
allocation of the following initial octet code points for QUIC: | rarely used. | |||
For the Long header, 225-230 (241-246 when the spin bit is set) | ||||
and for the Short header, 193-195 (209-11 with spin bit set), | ||||
209-211 (225-227 with spin bit set) and 217-219 (233-235 with the | ||||
spin bit set). Utilizing all of these code points for QUIC would | ||||
leave limited code points available for future allocations. | ||||
2.2. Multiplexing Shim | 2.1. Subsequent changes | |||
In this approach, an initial octet not allocated within [RFC7983] | Since then, additional changes have been made to the QUIC transport | |||
would be prepended to each QUIC packet, allowing QUIC packets to be | headers. While the QUIC Long Header packet type field retains its | |||
differentiated from RTP, RTCP, DTLS, STUN, TURN and ZRTP based on the | original allocations between 0x7C and 0x7F, as of draft -15, the | |||
first octet alone. As an example, an octet with decimal value 192 | first octet of the Short Header now appears as follows: | |||
could be used: | ||||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
|1|1|0|0|0|0|0|0| | |0|K|1|1|0|R|R|R| | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Advantages of this approach include simplicity and the consumption | Where: | |||
of only a single initial octet code point for demultiplexing of | ||||
QUIC. The disadvantage is the addition of a single octet of | ||||
overhead to every QUIC packet, which could impact performance | ||||
where small payloads are exchanged, such as in peer-to-peer | ||||
gaming. | ||||
2.3. Heuristics | ||||
During the QUIC WG interim in Seattle, Martin Thomson suggested the | ||||
following heuristics for differentiation of QUIC packets from | ||||
RTP/RTCP/DTLS/STUN/TURN/ZRTP: | ||||
1. Demultiplex differently during the "QUIC handshake" | K = indicates the key phase. | |||
and "steady state". | R = reserved bits, set randomly by endpoints not actively using them. | |||
2. During handshake, we only need to worry about the QUIC | ||||
Long header, which simplifies the logic. | ||||
a. Force all handshake packets to utilize the QUIC Long header. | ||||
b. The QUIC Long header (0x1XXXXXXX) (or 0x11XXXXXX with | ||||
the spin bit set) does not conflict with STUN (0x000000XX), | ||||
DTLS (0x000XXXXX), or TURN Channel (0x01XXXXXX). | ||||
c. The QUIC Long header does conflict with RTP/RTCP (0x10XXXXXX), | ||||
but those packets typically aren't sent until the QUIC | ||||
handshake is completed. Corner case: an application starts | ||||
off with audio and video keyed with DTLS-SRTP without QUIC, | ||||
then the application wishes to add QUIC data (e.g. the user | ||||
clicks on the "white-board" icon). | ||||
i. Alternative: force the RTP padding bit to 1 | ||||
using a one-byte pad if there isn't already | ||||
padding (pad == 0x01). Then force QUIC to have | ||||
a type < 64 (the current max is 8). | ||||
ii. Alternative: Disallow QUIC in this case, use SCTP data | ||||
exchange instead. | ||||
3. During "steady state", we only need to worry about the QUIC | ||||
Short header. | ||||
a. QUIC doesn't need the Long header after the handshake. | ||||
b. The QUIC Short header (0x0XXXXXXX or 0x01XXXXXX with | ||||
the spin bit set) does not conflict with RTP/RTCP | ||||
(0x10XXXXXX), so we only need to worry about | ||||
conflicts with STUN/TURN/DTLS/ZRTP. | ||||
c. Disallow simultaneous use of DTLS and QUIC | ||||
Short header packets. | ||||
i. Alternative: when using DTLS and QUIC at the same | ||||
time, only use the QUIC Long header. Not optimal, | ||||
but isn't really needed. | ||||
d. ICE can be demultiplexed using the magic cookie | ||||
and checksum. | ||||
i. Alternative: STUN can only conflict with 3 | ||||
QUIC packet types: Version Negotiation, | ||||
Client Initial, and Server Stateless Retry. | ||||
Out of those, none should be needed during | ||||
the steady state. | ||||
e. We shouldn't need to demultiplex QUIC with TURN channel | ||||
data or other STUN traffic. What about consent packets? | ||||
This approach has the advantage that it requires no changes to | This potentially produces values of the first octet in the ranges | |||
QUIC headers, nor does it add any overhead to QUIC packets. | 48-55 which potentially conflicts with DTLS, and 80-87 which | |||
Disadvantages include additional complexity within the | conflicts with TURN channels (not an issue). | |||
multiplexing algorithm, the consumption of additional multiplexing | ||||
code points, and potential future difficulties in adapting the | ||||
algorithm to support changes to the QUIC protocol or additional | ||||
protocols to be multiplexed. | ||||
3. Security Considerations | 3. Security Considerations | |||
The solutions discussed in this document could potentially introduce | The solutions discussed in this document could potentially introduce | |||
some additional security considerations beyond those detailed in | some additional security considerations beyond those detailed in | |||
[RFC7983]. | [RFC7983]. | |||
Due to the additional logic required, if mis-implemented, heuristics | Due to the additional logic required, if mis-implemented, heuristics | |||
have the potential to mis-classify packets. | have the potential to mis-classify packets. | |||
When QUIC is used for only for data exchange, the TLS-within-QUIC | When QUIC is used for only for data exchange, the TLS-within-QUIC | |||
exchange [I-D.ietf-quic-tls] derives keys used solely to protect the | exchange [I-D.ietf-quic-tls] derives keys used solely to protect the | |||
QUIC data packets. If properly implemented, this should not affect | QUIC data packets. If properly implemented, this should not affect | |||
the transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP, | the transport of SRTP nor the derivation of SRTP keys via DTLS-SRTP, | |||
but if badly implemented, both transport and key derivation could be | but if badly implemented, both transport and key derivation could be | |||
skipping to change at page 7, line 19 ¶ | skipping to change at page 5, line 27 ¶ | |||
4. IANA Considerations | 4. IANA Considerations | |||
This document does not require actions by IANA. | This document does not require actions by IANA. | |||
5. References | 5. References | |||
5.1. Informative References | 5.1. Informative References | |||
[I-D.ietf-quic-tls] | [I-D.ietf-quic-tls] | |||
Thomson, M. and S. Turner, "Using Transport Layer Security | Thomson, M. and S. Turner, "Using Transport Layer Security | |||
(TLS) to Secure QUIC", draft-ietf-quic-tls-07 (work in | (TLS) to Secure QUIC", draft-ietf-quic-tls-15 (work in | |||
progress), October 13, 2017. | progress), October 3, 2018. | |||
[I-D.ietf-quic-transport] | [I-D.ietf-quic-transport] | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", draft-ietf-quic-transport-07 (work | and Secure Transport", draft-ietf-quic-transport-15 (work | |||
in progress), October 13, 2017. | in progress), October 3, 2018. | |||
[I-D.rtpfolks-quic-rtp-over-quic] | ||||
Ott, J., Even, R., Perkins, C. and V. Singh, "RTP over | ||||
QUIC", draft-rtpfolks-quic-rtp-over-quic-01 (work in | ||||
progress), September 1, 2017. | ||||
[ORTC] Raymond, R., Aboba, B. and J. Uberti, "Object RTC (ORTC) | ||||
API for WebRTC", W3C, http://draft.ortc.org/, October 2017. | ||||
[QUIC-Issue] Perkins, C., "QUIC header format/demultiplexing", | [QUIC-Issue] Perkins, C., "QUIC header format/demultiplexing", | |||
https://github.com/quicwg/base-drafts/issues/426, March, | https://github.com/quicwg/base-drafts/issues/426, March, | |||
2017. | 2017. | |||
[QUIC-Spin] Huitema, C., "QUIC Latency Spin Bit", | [QUIC-MULTI] Perkins, C., "QUIC Multiplexing and Peer-to-Peer", | |||
https://github.com/quicwg/base-drafts/issues/609, June | presentation to IETF AVTCORE WG at IETF 100, | |||
<https://datatracker.ietf.org/meeting/100/materials/ | ||||
slides-100-avtcore-quic-multiplexing-with-rtp-03>, November | ||||
2017. | 2017. | |||
[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, DOI | Requirement Levels", BCP 14, RFC 2119, DOI | |||
10.17487/RFC2119, March 1997, <http://www.rfc- | 10.17487/RFC2119, March 1997, <http://www.rfc- | |||
editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July | |||
skipping to change at page 8, line 33 ¶ | skipping to change at page 6, line 34 ¶ | |||
Real-time Transport Protocol (SRTP)", RFC 5764, DOI | Real-time Transport Protocol (SRTP)", RFC 5764, DOI | |||
10.17487/RFC5764, May 2010, <http://www.rfc- | 10.17487/RFC5764, May 2010, <http://www.rfc- | |||
editor.org/info/rfc5764>. | editor.org/info/rfc5764>. | |||
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using | [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using | |||
Relays around NAT (TURN): Relay Extensions to Session | Relays around NAT (TURN): Relay Extensions to Session | |||
Traversal Utilities for NAT (STUN)", RFC 5766, DOI | Traversal Utilities for NAT (STUN)", RFC 5766, DOI | |||
10.17487/RFC5766, April 2010, <http://www.rfc- | 10.17487/RFC5766, April 2010, <http://www.rfc- | |||
editor.org/info/rfc5766>. | editor.org/info/rfc5766>. | |||
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: | ||||
Media Path Key Agreement for Unicast Secure RTP", RFC 6189, | ||||
DOI 10.17487/RFC6189, April 2011, <http://www.rfc- | ||||
editor.org/info/rfc6189>. | ||||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <http://www.rfc-editor.org/info/rfc6347>. | January 2012, <http://www.rfc-editor.org/info/rfc6347>. | |||
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI | |||
10.17487/RFC7540, May 2015, <https://www.rfc- | 10.17487/RFC7540, May 2015, <https://www.rfc- | |||
editor.org/info/rfc7540>. | editor.org/info/rfc7540>. | |||
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme | [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme | |||
Updates for Secure Real-time Transport Protocol (SRTP) | Updates for Secure Real-time Transport Protocol (SRTP) | |||
Extension for Datagram Transport Layer Security (DTLS)", | Extension for Datagram Transport Layer Security (DTLS)", | |||
RFC 7983, DOI 10.17487/RFC7983, September 2016, | RFC 7983, DOI 10.17487/RFC7983, September 2016, | |||
<https://www.rfc-editor.org/info/rfc7983>. | <https://www.rfc-editor.org/info/rfc7983>. | |||
[WEBRTC-QUIC] | ||||
Thatcher, P. and B. Aboba, "QUIC API For WebRTC", W3C | ||||
Editor's Draft (work in progress), October 2018, | ||||
<https://w3c.github.io/webrtc-quic> | ||||
Acknowledgments | Acknowledgments | |||
We would like to thank Martin Thomson, Roni Even and other | We would like to thank Martin Thomson, Roni Even and other | |||
participants in the IETF QUIC and AVTCORE working groups for their | participants in the IETF QUIC and AVTCORE working groups for their | |||
discussion of the QUIC multiplexing issue, and their input relating | discussion of the QUIC multiplexing issue, and their input relating | |||
to potential solutions. | to potential solutions. | |||
Authors' Addresses | Authors' Addresses | |||
Bernard Aboba | Bernard Aboba | |||
End of changes. 31 change blocks. | ||||
184 lines changed or deleted | 95 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |