Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02

[Harald Alvestrand <[e-mail]>]

On 02/19/2014 11:08 AM, Magnus Westerlund wrote:
> Hi,
>
> I have reviewed the Transports for RTCWEB
> (draft-ietf-rtcweb-transports-02)
Thanks!
>  and have the following comments.
>
> 1. Section 1.
>
>  This document focuses on the data
>    transport protocos that are used by conforming implementations.
>
> Missing "l" in protocos.
Fixed.
>
> 2. Section 3.1:
>    For both protocols, IPv4 and IPv6 support is assumed; applications
>    MUST be able to utilize both IPv4 and IPv6 where available.
>
> What "applications" are intended in this sentence. I get a feeling that
> "applications" here could be replaced by "WebRTC implementations"

Javascript applications. I think I should add the word "application" to
-overview's vocabulary; it is actually used in that meaning in that
document (also in the forms "Web application" and "browser-based
application".

>
>
> 3. Section 3.1:
>    For UDP, this specification assumes the ability to set the DSCP code
>    point of the sockets opened on a per-packet basis, in order to
>    achieve the prioritizations described in
>    [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are
>    multiplexed.  It does not assume that the DSCP codepoints will be
>    honored, and does assume that they may be zeroed or changed, since
>    this is a local configuration issue.
>
> I wonder if this should be moved into 3.2 section instead. At least the
> part in 3.1 should focus on the DSCP setting part on the transport flow.
> The implications of it working or not should be moved to 3.2. A forward
> pointer to that second can be used instead.

I think it fits better in 3.1 - this is about the assumptions that the
specifcation makes about the parts of the system that it is not a
specification for.

>
> 4. Order of Section 3.2 and 3.3.
>
> I think the order should be swapped between 3.2. and 3.3. That way the
> Multiplexing section can provide definitions of all the stream concepts
> that exists in WebRTC and how they can be combined. More about this later.
>
> 5. Content of Section 3.2
>
> This section needs to be expanded to start with a general discussion of
> how QoS can be applied to get a benefit. But, I think one need to be
> clear that it can't be assumed to be available in implementations or
> WebRTC based applications.

I want to push back on this. It seems inappropriate that the RTCWEB QoS
specification start off with a tutorial on what QoS is and how one can
use it to gain a benefit. That material should be available elsewhere.
(Recommendations?)

>
> It needs to also discuss flow-based QoS mechanism. What are the
> implications if that is what is available and what choices does one have
> to address this by configuring the multiplexing different.

I do not want to discuss material for which there are no references.
What particular flow-based mechanisms do you have in mind, and what are
the relevant references?

>  I think this
> is the logical place to take the main discussion of that, as it can
> address both RTP streams and the data channel together. Please consider
> pointers to appropriate discussion in Section 12.1.3 in
> draft-ietf-rtcweb-rtp-usage.

I do not think this document should repeat any material from rtp-usage,
but rtp-usage does not consider any aspect of QoS marking for multiple
streams using the same 5-tuple, nor does it say anything about
flow-based or DPI-based mechanisms apart from noting their existence.

Agree that the multiplexing aspect should be discussed somewhere, but
I'm not sure where.
>
> I do note that writing this section appropriately is difficult until the
> content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up.

True.
>
> 6. Content of Section 3.3:
>
> I think this section should focus on making clear what different types
> of streams that exist in the WebRTC context, and what choices of
> multiplexing that are possible. Basically ensure that the full set of
> combinations are made clear.

Isn't this material that really should be in
draft-ietf-avtcore-rtp-multi-stream or
draft-ietf-avtcore-multiplex-guidelines?

Again, this seems the wrong draft for having a discussion of those issues.
>
> A. All RTP packet streams and data channel over a single UDP flow.
>
> B. All RTP packet streams over one UDP flow and the data channel over
> another UDP flow.
>
> C. The RTP packet streams over different UDP flows based on content type
> and separate data channel.
>
> D. Each RTP packet stream over its own UDP flow (RTP session) and the
> data channel over its own UDP flow.
>
> The above with the additional dimension, that each RTP sessions, RTCP
> can be in its own UDP flow.
>
> There is also a question if the data channel can be aggregated with only
> one RTP session, where there are multiple ones configured.
>
> The QoS related discussion of this can be moved to the QoS section to
> keep that focused.
>
> However, the discussion of the pro and cons with having one or more flow
> is good and could even be expanded to list reasons such as legacy
> interop over a gateway.
>
> 7. Section 3.3:
>    RTCWEB implementations MUST support the ability to send and receive
>    multiple SSRCs on the same transport, and MUST support the ability to
>    send and receive multiple SSRCs on multiple simultaneous transports,
>    including the ability to send and receive audio and video on the same
>    transport.
>
> I think this sentence is restating what is already required by Section
> 4.1 in draft-ietf-rtcweb-rtp-usage: If you want to enforce this, I
> suggest to do that by reference to that text rather than using RFC 2119
> normative statements.

Yes, rtp-usage contains these requirements. I can delete it from here.
Thanks!

However, this removes the handle on which I hung the discussion of why
one would want to multiplex or not, which I inserted because you
requested it. This discussion also seems to be present in rtp-usage, so
it seems appropriate to delete that too.

>
>
> 8. Section 3.4:
>    ICE [RFC5245] MUST be supported.  The implementation MUST be a full
>    ICE implementation, not ICE-Lite.
>
>    In order to deal with situations where both parties are behind NATs
>    which perform endpoint-dependent mapping (as defined in [RFC5128]
>    section 2.4), TURN [RFC5766] MUST be supported.
>
> These paragraph implies STUN and TURN server configuration. Should that
> configuration question be discussed with the appropriate pointers to the
> API?
This document has no pointers to the API at the moment, and I do not
want to add them - it's a layering violation of sorts. We can add
pointers to JSEP, which is kind of close to the API.

But the main point seems to be that STUN and TURN servers MUST be
configurable, both from the browser setup and from the (JS) application.
I'm adding a sentence saying that.

>
> 9. Section 3.4:
>    In order to deal with firewalls that block all UDP traffic, TURN
>    using TCP between the client and the server MUST be supported, and
>    TURN using TLS between the client and the server MUST be supported.
>    See [RFC5766] section 2.1 for details.
>
> I think the following part: "TURN using TLS between" should be changed
> over "TURN using TLS over TCP between" to make it clear that this is
> using TLS/TCP rather than TLS/FOO.
Done.
>
> 10. Section 3.4:
>    TURN TCP candidates [RFC6062] SHOULD be supported; this allows
>    applications to achieve peer-to-peer communication when both parties
>    are behind UDP-blocking firewalls using a single TURN server.  (In
>    this case, one can also achieve communication using two TURN servers
>    that use TCP between the server and the client, and UDP between the
>    TURN servers.)
>
> My understanding of RFC6062 is that it allows one to establish a vanilla
> TCP connection on the far side of the TURN server as well as connecting
> that one to an almost vanilla TCP connection (just a initial TURN
> ConnectionBind request) that A establish to the TURN server, i.e.
> WebRTC-A -(Turn/TCP)-> TURN_Server -(TCP)-> WebRTC-B.
>
> The end-result is that a relayed vanilla TCP connection is established
> between the WebRTC endpoints (A and B). As the WebRTC transport so far
> defined only works with datagrams, i.e. DTLS or RTP/RTCP packets they
> can't be sent natively over a TCP byte stream. Thus, if this mode of
> operation is to be supported a framing is required on this leg.
>
> A possibility here could be RFC 4571 if one want to go this way.

I added a 4571 reference, and a note saying this is up for discussion.
If we frame RTP over TCP, we also have to decide what we do about the SCTP.

>
> 11. Section 3.4:
>
>    ICE-TCP candidates [RFC6544] MAY be supported; this may allow
>    applications to communicate to peers with public IP addresses across
>    UDP-blocking firewalls without using a TURN server.
>
> Also this option would need to use a framing of the datagrams.

Yep.

Updated draft to be submitted once submission reopens.

>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.