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

[Magnus Westerlund <[e-mail]>]

On 2014-02-19 19:47, Harald Alvestrand wrote:
> 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".

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.

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

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.

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

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.

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

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?

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

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.

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

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.

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

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.

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

That is probably sufficient.

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

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

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