draft-ietf-rtcweb-transports-12.txt   draft-ietf-rtcweb-transports-13.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track March 21, 2016 Intended status: Standards Track June 6, 2016
Expires: September 22, 2016 Expires: December 8, 2016
Transports for WebRTC Transports for WebRTC
draft-ietf-rtcweb-transports-12 draft-ietf-rtcweb-transports-13
Abstract Abstract
This document describes the data transport protocols used by WebRTC, This document describes the data transport protocols used by WebRTC,
including the protocols used for interaction with intermediate boxes including the protocols used for interaction with intermediate boxes
such as firewalls, relays and NAT boxes. such as firewalls, relays and NAT boxes.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 22, 2016. This Internet-Draft will expire on December 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 24 skipping to change at page 2, line 24
3.5. Transport protocols implemented . . . . . . . . . . . . . 6 3.5. Transport protocols implemented . . . . . . . . . . . . . 6
4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 6
4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 7
4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 14
A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 14 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 14
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 14 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 14
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 14 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 14
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15
A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15
A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15
A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16
A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16
A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16
A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 16 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 16
A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16
A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 16 A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 16
A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
WebRTC is a protocol suite aimed at real time multimedia exchange WebRTC is a protocol suite aimed at real time multimedia exchange
between browsers, and between browsers and other entities. between browsers, and between browsers and other entities.
WebRTC is described in the WebRTC overview document, WebRTC is described in the WebRTC overview document,
[I-D.ietf-rtcweb-overview], which also defines terminology used in [I-D.ietf-rtcweb-overview], which also defines terminology used in
this document, including the terms "WebRTC device" and "WebRTC this document, including the terms "WebRTC device" and "WebRTC
skipping to change at page 5, line 48 skipping to change at page 5, line 48
UDP-blocking firewalls without using a TURN server. UDP-blocking firewalls without using a TURN server.
If TCP connections are used, RTP framing according to [RFC4571] MUST If TCP connections are used, RTP framing according to [RFC4571] MUST
be used, both for the RTP packets and for the DTLS packets used to be used, both for the RTP packets and for the DTLS packets used to
carry data channels. carry data channels.
The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section
11 (300 Try Alternate) MUST be supported. 11 (300 Try Alternate) MUST be supported.
The WebRTC implementation MAY support accessing the Internet through The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy. If it does so, it MUST support the "ALPN" header as an HTTP proxy. If it does so, it MUST include the "ALPN" header as
specified in [RFC7639], and proxy authentication as described in specified in [RFC7639], and proxy authentication as described in
Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported. Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported.
3.5. Transport protocols implemented 3.5. Transport protocols implemented
For transport of media, secure RTP is used. The details of the For transport of media, secure RTP is used. The details of the
profile of RTP used are described in "RTP Usage" profile of RTP used are described in "RTP Usage"
[I-D.ietf-rtcweb-rtp-usage]. Key exchange MUST be done using DTLS- [I-D.ietf-rtcweb-rtp-usage]. Key exchange MUST be done using DTLS-
SRTP, as described in [I-D.ietf-rtcweb-security-arch]. SRTP, as described in [I-D.ietf-rtcweb-security-arch].
skipping to change at page 7, line 21 skipping to change at page 7, line 21
section below. section below.
4.1. Local prioritization 4.1. Local prioritization
Local prioritization is applied at the local node, before the packet Local prioritization is applied at the local node, before the packet
is sent. This means that the prioritization has full access to the is sent. This means that the prioritization has full access to the
data about the individual packets, and can choose differing treatment data about the individual packets, and can choose differing treatment
based on the stream a packet belongs to. based on the stream a packet belongs to.
When an WebRTC implementation has packets to send on multiple streams When an WebRTC implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion controller, that are congestion-controlled under the same congestion control
the WebRTC implementation SHOULD cause data to be emitted in such a regime, the WebRTC implementation SHOULD cause data to be emitted in
way that each stream at each level of priority is being given such a way that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload approximately twice the transmission capacity (measured in payload
bytes) of the level below. bytes) of the level below.
Thus, when congestion occurs, a "high" priority flow will have the Thus, when congestion occurs, a "high" priority flow will have the
ability to send 8 times as much data as a "very-low" priority flow if ability to send 8 times as much data as a "very-low" priority flow if
both have data to send. This prioritization is independent of the both have data to send. This prioritization is independent of the
media type. The details of which packet to send first are media type. The details of which packet to send first are
implementation defined. implementation defined.
For example: If there is a high priority audio flow sending 100 byte For example: If there is a high priority audio flow sending 100 byte
skipping to change at page 8, line 47 skipping to change at page 8, line 47
All packets carrying data from the SCTP association supporting the All packets carrying data from the SCTP association supporting the
data channels MUST use a single DSCP code point. The code point used data channels MUST use a single DSCP code point. The code point used
SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the
highest priority data channel carried. Note that this means that all highest priority data channel carried. Note that this means that all
data packets, no matter what their relative priority is, will be data packets, no matter what their relative priority is, will be
treated the same by the network. treated the same by the network.
All packets on one TCP connection, no matter what it carries, MUST All packets on one TCP connection, no matter what it carries, MUST
use a single DSCP code point. use a single DSCP code point.
More advice on the use of DSCP code points with RTP is given in More advice on the use of DSCP code points with RTP and on the
relationship between DSCP and congestion control is given in
[RFC7657]. [RFC7657].
There exist a number of schemes for achieving quality of service that There exist a number of schemes for achieving quality of service that
do not depend solely on DSCP code points. Some of these schemes do not depend solely on DSCP code points. Some of these schemes
depend on classifying the traffic into flows based on 5-tuple (source depend on classifying the traffic into flows based on 5-tuple (source
address, source port, protocol, destination address, destination address, source port, protocol, destination address, destination
port) or 6-tuple (5-tuple + DSCP code point). Under differing port) or 6-tuple (5-tuple + DSCP code point). Under differing
conditions, it may therefore make sense for a sending application to conditions, it may therefore make sense for a sending application to
choose any of the configurations: choose any of the configurations:
skipping to change at page 10, line 32 skipping to change at page 10, line 35
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Loreto, S., and G. Camarillo, "Stream Holmberg, C., Loreto, S., and G. Camarillo, "Stream
Control Transmission Protocol (SCTP)-Based Media Transport Control Transmission Protocol (SCTP)-Based Media Transport
in the Session Description Protocol (SDP)", draft-ietf- in the Session Description Protocol (SDP)", draft-ietf-
mmusic-sctp-sdp-16 (work in progress), February 2016. mmusic-sctp-sdp-16 (work in progress), February 2016.
[I-D.ietf-rtcweb-alpn] [I-D.ietf-rtcweb-alpn]
Thomson, M., "Application Layer Protocol Negotiation for Thomson, M., "Application Layer Protocol Negotiation for
Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb-
alpn-02 (work in progress), January 2016. alpn-04 (work in progress), May 2016.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015. protocol-09 (work in progress), January 2015.
skipping to change at page 11, line 11 skipping to change at page 11, line 15
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015. rtcweb-security-arch-11 (work in progress), March 2015.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
and other packet markings for WebRTC QoS", draft-ietf- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
tsvwg-rtcweb-qos-15 (work in progress), March 2016. qos-17 (work in progress), May 2016.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015. dtls-encaps-09 (work in progress), January 2015.
[I-D.ietf-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", draft-ietf-tsvwg- Stream Control Transmission Protocol", draft-ietf-tsvwg-
skipping to change at page 17, line 5 skipping to change at page 17, line 5
o Changed the names of the four priority levels to conform to other o Changed the names of the four priority levels to conform to other
specs. specs.
A.12. Changes from -11 to -12 A.12. Changes from -11 to -12
o Added a SHOULD NOT about using deprecated temporary IPv6 o Added a SHOULD NOT about using deprecated temporary IPv6
addresses. addresses.
o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657 o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657
A.13. Changes from -12 to -13
o Clarify that the ALPN header needs to be sent.
o Mentioned that RFC 7657 also talks about congestion control
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 11 change blocks. 
13 lines changed or deleted 21 lines changed or added

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