Draft: rtcweb-transports

Commentary: See changelog for details . 
 From   on the rtcweb mailing list : Dear all , Sorry for re - opening this discussion at such a late stage , but , by way of agreeing with  's comment below that the document should say more about congestion control , I still find it very strange that the text does not cite draft - ietf - rmcat - coupled - cc . Mirja mentions draft - ietf - rmcat - cc - requirements-09 , and I agree that this should be cited , but this requirements document is also generic and does not provide much concrete guidance on how to implement things - so I 'd say it 's not enough . draft - ietf - rmcat - coupled - cc-03 is now in WGLC and has so far only received editorial comments . We have lots of proof that this mechanism works very well ; whenever it 's known that flows share a bottleneck ( as is the case for all rtcweb streams between the same hosts ) , this allows to precisely divide bandwidth among flows based on priorities , and it yields overall lower latency due to reduced on - the - wire competition ( well in line with the first requirement laid out in draft - ietf - rmcat - cc - requirements-09 ) . Using the DSCP may protect against other traffic but it 's also just hoping for routers to do the right thing . I think that possibilities should be laid out to people intending to implement rtcweb . Maybe the goal was to avoid a dependency on specific RMCAT congestion controls ; I can understand that , but the algorithm in draft - ietf - rmcat - coupled - cc , while containing sections explaining how to apply it to NADA and GCC , is pretty generic and can be quite easily adapted for other controls ( as we 've successfully done ) . Accordingly , the draft presents the algorithm as the generic thing that it is . I brought this missing citation issue up in the past , and it was addressed , but IMO very weakly : Specifically , let us consider this statement at this URL : I regard the mention of coupled CC as mostly " pointless but harmless " . The initial decision to mention a single controller was to mention only the most restricted case ; if the chairs think extending this to coupled CC is OK , I do n't have any strong reason to push back against it . The extensive use of " common ( coupled ) " in RFC 7657 is ( in my opinion ) a mistake ; these two are not the same thing , and I ca n't see that RFC 7657 is really clear about the difference . Why is it pointless to tell folks who implement rtcweb protocols that this is a possible mechanism to use , and point them directly at it ? I also do n't understand the " mistake " about the extensive use of " common ( coupled ) " in RFC 7657 : the outcome is almost identical ( again , we have lots of graphs using various congestion controls to prove my point ) , so what 's the problem ? To me , it 's very strange and inconsistent that draft - ietf - rtcweb - transports-15 points at draft - ietf - tsvwg - rtcweb - qos for concrete implementation guidance , but does n't point at draft - ietf - rmcat - coupled - cc for the same ; it talks about the possibility of having " multiple streams that are congestion - controlled under the same congestion control regime " but it does n't give any hint about how to do that ( which is what a pointer to draft - ietf - rmcat - coupled - cc would achieve ) . Cheers ,    a paragraph in -16 
 This conversation was lost when was closed . That works for me , given that it calls out a specific case I think was raised , and continues to use SHOULD . I 'll add this . 
 The whole paragraph now reads ( -16 ): If some of the temporary IPv6 addresses , but not all , are marked deprecated , the WebRTC endpoint SHOULD discard the deprecated addresses , unless they are used by an ongoing connection . In an ICE restart , deprecated addresses that are currently in use MAY be retained . 
 From   in IESG review : 
 Comment from   : This is listed as “ MUST implement ” in draft - ietf - rtcweb - rtp - usage-26 , which is referenced from Section 3.5 of the rtcweb - transport draft . 
 From   , text suggestion : rtcweb - transport says " For transport of media , secure RTP is used . The details of the profile of RTP used are described in " RTP Usage “ [ I - D.ietf - rtcweb - rtp - usage ] . " Given that this doc is called " Transports for WebRTC “ , I would appreciate if it says slightly more about the recommendations given in rtcweb - rtp - usage , especialy regarding congestion control . What ’s about the following ? " For transport of media , secure RTP is used . The details of the profile of RTP used are described in " RTP Usage “ [ I - D.ietf - rtcweb - rtp - usage ] , which mandates the use of a circuit breaker [ draft - ietf - avtcore - rtp - circuit - breakers-17 ] and congestion control ( see [ draft - ietf - rmcat - cc - requirements-09 ] for further guidance ) . “ 
 Note in 
 From   ( raised 20 - 22 June 2016 ): There is still the issue of what to say in section 3.4 about auto - discovery of TURN servers and the conflicts between application provided , auto discovered , and configured TURN servers . Section 3.4 currently includes the statement " WebRTC browsers MUST support configuration of STUN and TURN servers , both from browser configuration and from an application " . Previously I suggested the text : " WebRTC browsers MUST support configuration of STUN and TURN servers , both from browser configuration and from an application . WebRTC browsers MAY also discover TURN servers using TURN Auto - Discovery [ draft - ietf - tram - turn - server - discovery ] . To resolve conflicts between TURN servers provided by configuration , auto - discovery , and the application WebRTC browsers MAY implement the procedures specified in Recursively Encapsulated TURN ( RETURN ) [ draft - ietf - rtcweb - return ] ” . This suggestion was based on the fact that the -return- draft is I believe the only place where there is a statement about what to do about the conflict between application provided and locally configured TURN servers . 
 Agree . I 've additionally proposed that  's final sentence is changed to a SHOULD ( RECOMMEND ): " To resolve conflicts between TURN servers provided by configuration , auto - discovery , and the application WebRTC browsers are RECOMMENDED to implement the procedures specified in Recursively Encapsulated TURN ( RETURN ) [ draft - ietf - rtcweb - return ] " 
 WG chairs decision :  ,   raised an issue with draft - ietf - rtcweb - transports that was considered during the IESG process ( this is  issue 42 ) . When the subject of configuration was discussed , the chairs did not see consensus for a normative requirement to support RETURN at this stage . We have therefore recommended that the documents only note the existence of RETURN in the relevant RFC editor note or update . regards ,  , Sean , Cullen 
 Added text in -16 : Note that there is other work around STUN and TURN server discovery and management , including [ discovery ] for server discovery , as well as [ return ] . 
 From Suresh 's IESG review : Similarly , it also says " When a client gathers all IPv6 addresses on a host ... " but it is not clear what " client " the draft is referring to . I replied that the term was intended to mean " WebRTC endpoint " , but that fix did n't make it to -15 . 
 Changed all occurences of " client " , " WebRTC device " and " WebRTC implementation " to " WebRTC endpoint " for -16 . 
 From    IESG review : 
 Earlier discussions have shown a preference for a ) keeping terminology in -overview , and b ) keeping references to -overview informational , to avoid the " all must be done before anything is done " problem . Treating definitions consistently seems reasonable to me . Agree that it 's borderline . Advice sought . 
 After mulling on the matter , moving these to normative in -16 .
WebRTC is described in the WebRTC overview document, I-D.ietf-rtcweb-
overview, which also defines terminology used in this document,
including the terms "WebRTC device" and "WebRTC browser".
WebRTC is described in the WebRTC overview document, I-D.ietf-rtcweb-
overview, which also defines terminology used in this document,
including the terms "WebRTC endpoint" and "WebRTC browser".
This document describes requirements that apply to all WebRTC
devices.  When there are requirements that apply only to WebRTC
browsers, this is called out explicitly.
This document describes requirements that apply to all WebRTC
endpoints.  When there are requirements that apply only to WebRTC
browsers, this is called out explicitly.
Platforms that do not give access to these interfaces will not be
able to support a conforming WebRTC implementation.
Platforms that do not give access to these interfaces will not be
able to support a conforming WebRTC endpoint.
When a client gathers all IPv6 addresses on a host, and both non-
deprecated temporary addresses and permanent addresses of the same
scope are present, the client SHOULD discard the permanent addresses
before exposing addresses to the application or using them in ICE.
This is consistent with the default policy described in RFC6724.
If some of the temporary IPv6 addresses, but not all, are marked
deprecated, the client SHOULD discard the deprecated addresses.  In
an ICE restart, deprecated addresses that are currently in use MAY be
retained.
When a WebRTC endpoint gathers all IPv6 addresses on its host, and
both non-deprecated temporary addresses and permanent addresses of
the same scope are present, the WebRTC endpoint SHOULD discard the
permanent addresses before exposing addresses to the application or
using them in ICE.  This is consistent with the default policy
described in RFC6724.
If some of the temporary IPv6 addresses, but not all, are marked
deprecated, the WebRTC endpoint SHOULD discard the deprecated
addresses, unless they are used by an ongoing connection.  In an ICE
restart, deprecated addresses that are currently in use MAY be
retained.
In order to deal with firewalls that block all UDP traffic, the mode
of TURN that uses TCP between the client and the server MUST be
supported, and the mode of TURN that uses TLS over TCP between the
client and the server MUST be supported.  See RFC5766 section 2.1 for
details.
TURN TCP candidates, where the connection from the client's TURN
server to the peer is a TCP connection, RFC6062 MAY be supported.
Note that there is other work around STUN and TURN sever discovery
and management, including I-D.ietf-tram-turn-server-discovery for
server discovery, as well as I-D.ietf-rtcweb-return.
In order to deal with firewalls that block all UDP traffic, the mode
of TURN that uses TCP between the WebRTC endpoint and the TURN server
MUST be supported, and the mode of TURN that uses TLS over TCP
between the WebRTC endpoint and the TURN server MUST be supported.
See RFC5766 section 2.1 for details.
TURN TCP candidates, where the connection from the WebRTC endpoint's
TURN server to the peer is a TCP connection, RFC6062 MAY be
supported.
Third, using TCP between the client's TURN server and the peer may
result in more performance problems than using UDP, e.g. due to head
of line blocking.
Third, using TCP between the WebRTC endpoint's TURN server and the
peer may result in more performance problems than using UDP, e.g. due
to head of line blocking.
The WebRTC implementation MAY support accessing the Internet through
an HTTP proxy.  If it does so, it MUST include the "ALPN" header as
specified in RFC7639, and proxy authentication as described in
Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
The WebRTC endpoint MAY support accessing the Internet through an
HTTP proxy.  If it does so, it MUST include the "ALPN" header as
specified in RFC7639, and proxy authentication as described in
Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
For transport of media, secure RTP is used.  The details of the
profile of RTP used are described in "RTP Usage" I-D.ietf-rtcweb-rtp-
usage.  Key exchange MUST be done using DTLS-SRTP, as described in I-
D.ietf-rtcweb-security-arch.
For data transport over the WebRTC data channel I-D.ietf-rtcweb-data-
channel, WebRTC implementations MUST support SCTP over DTLS over ICE.
This encapsulation is specified in I-D.ietf-tsvwg-sctp-dtls-encaps.
Negotiation of this transport in SDP is defined in I-D.ietf-mmusic-
sctp-sdp.  The SCTP extension for NDATA, I-D.ietf-tsvwg-sctp-ndata,
MUST be supported.
For transport of media, secure RTP is used.  The details of the
profile of RTP used are described in "RTP Usage" I-D.ietf-rtcweb-rtp-
usage, which mandates the use of a circuit breaker I-D.ietf-avtcore-
rtp-circuit-breakers and congstion control (see I-D.ietf-rmcat-cc-
requirements for further guidance).
Key exchange MUST be done using DTLS-SRTP, as described in I-D.ietf-
rtcweb-security-arch.
For data transport over the WebRTC data channel I-D.ietf-rtcweb-data-
channel, WebRTC endpoints MUST support SCTP over DTLS over ICE.  This
encapsulation is specified in I-D.ietf-tsvwg-sctp-dtls-encaps.
Negotiation of this transport in SDP is defined in I-D.ietf-mmusic-
sctp-sdp.  The SCTP extension for NDATA, I-D.ietf-tsvwg-sctp-ndata,
MUST be supported.
WebRTC implementations MUST support multiplexing of DTLS and RTP over
the same port pair, as described in the DTLS-SRTP specification
RFC5764, section 5.1.2, with clarifications in I-D.ietf-avtcore-
rfc5764-mux-fixes.  All application layer protocol payloads over this
DTLS connection are SCTP packets.
WebRTC endpoints MUST support multiplexing of DTLS and RTP over the
same port pair, as described in the DTLS-SRTP specification RFC5764,
section 5.1.2, with clarifications in I-D.ietf-avtcore-rfc5764-mux-
fixes.  All application layer protocol payloads over this DTLS
connection are SCTP packets.
The WebRTC prioritization model is that the application tells the
WebRTC implementation about the priority of media and data that is
controlled from the API.
The WebRTC prioritization model is that the application tells the
WebRTC endpoint about the priority of media and data that is
controlled from the API.
When an WebRTC implementation has packets to send on multiple streams
that are congestion-controlled under the same congestion control
regime, the WebRTC implementation SHOULD cause data to be emitted in
such a way that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload
bytes) of the level below.
When an WebRTC endpoint has packets to send on multiple streams that
are congestion-controlled under the same congestion control regime,
the WebRTC endpoint SHOULD cause data to be emitted in such a way
that each stream at each level of priority is being given
approximately twice the transmission capacity (measured in payload
bytes) of the level below.
Note that this specification doesn't dictate when disparate streams
are to be "congestion controlled under the same congestion control
regime".  The issue of coupling congestion controllers is explored
further in I-D.ietf-rmcat-coupled-cc.