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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Feb 2014 11:08:30 +0100

Hi,

I have reviewed the Transports for RTCWEB
(draft-ietf-rtcweb-transports-02) 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.

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"

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.

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.

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 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 note that writing this section appropriately is difficult until the
content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up.

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.

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.

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?

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.

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.

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Feb 2014 19:47:03 +0100

On 02/19/2014 11:08 AM, Magnus Westerlund wrote:
> (draft-ietf-rtcweb-transports-02)
Thanks!
>  and have the following comments.
>
> 1. Section 1.
>
Fixed.
> "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".

> 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.

> 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?)

> 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

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.
> content of draft-dhesikan-tsvwg-rtcweb-qos has firmed up.

True.
> 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.
> suggest to do that by reference to that text rather than using RFC 2119

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.

> configuration question be discussed with the appropriate pointers to the
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.

> using TLS/TCP rather than TLS/FOO.
Done.
> 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.

> Also this option would need to use a framing of the datagrams.

Yep.

Updated draft to be submitted once submission reopens.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Feb 2014 11:46:57 +0100

> document (also in the forms "Web application" and "browser-based

Sorry, then I find the above requirement a bit strangely targeted. I
think we can require that IPv4 and IPv6 support for the applicable
protocol pieces in what we define. But, on the JS application level?
Also what explicit addressing information is visible on that level.

It might be that this requirement needs to be split or at least apply to
multiple levels.

> specifcation makes about the parts of the system that it is not a

I am fine with the first sentence staying, it is the second part that
needs more discussion and I think it should be moved and expanded on.
Thus a forward pointer may be appropriate here.

> use it to gain a benefit. That material should be available elsewhere.

I would like to agree with you, however we are putting together the
pieces in a way that stands some of the previous assumptions on their
heads. Thus, we don't have easy access to pointers.

I can see this discussion going into
draft-ietf-avtcore-multiplex-guidelines when it concerns RTP. However,
you also have the data channel to consider. Thus, there exist no
references that I know that discusses this particular combination and
its implications.

> What particular flow-based mechanisms do you have in mind, and what are

RSVP we can start with, but I think equally applicable is 3GPP QoS. But
finding the right reference here might be a bit problematic.

I think one can cover the general property of flow based QoS in a single
sentence. However, that usage has implications for the peer connection
and its configuration. We have text in the rtp-usage that makes it clear
about the requirement to be able to send multiple RTP sessions on
different flows. But the combination with the data channel is not
covered. Thus, I think that belongs in the transports document. The
question is how much lead in material you need for that discussion?

> flow-based or DPI-based mechanisms apart from noting their existence.

No, I am not talking about repeating. I am discussing the requirements
on being able to separate the data channel on transport level (UDP) from
the RTP sessions over their RTP, as well as being able to put them on
common UDP flows.

> draft-ietf-avtcore-rtp-multi-stream or

This is not appropriate place, this only discusses multiple SSRCs in the
same RTP session.

> draft-ietf-avtcore-multiplex-guidelines?

This one definitely needs such discussion yes.

Also draft-ietf-avtcore-multi-media-rtp-session has some parts of this,
due to the potential for different needs based on media type.

> Again, this seems the wrong draft for having a discussion of those issues.

However, adding the data channel into this, is something WebRTC
specific, thus you are not getting away from dealing with it.

> it seems appropriate to delete that too.

As I argue above, there is a need to take a full WebRTC level discussion
of the multiplexing issues. I think the appropriate here is to try to
ensure the AVTCORE documents contains the relevant pieces so you know
what to reference and then try to put togheter a high level RTP + Data
channel multiplexing considerations in this document.

> I'm adding a sentence saying that.

That is probably sufficient.

> If we frame RTP over TCP, we also have to decide what we do about the SCTP.

Yes, I get the impression that the people arguing for the WebRTC over
IP/TCP has not thought through the implications and I definitely like a
discussion of this.

Also, in which context are you wondering over SCTP in the above?

Cheers

Magnus Westerlund