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

[Harald Alvestrand <[e-mail]>]

Reviving an old thread, since I'm getting the changes in:

On 02/25/2014 11:46 AM, Magnus Westerlund wrote:
> 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.

If two JS applications want to communicate, and the two systems are
connected with IPv4 but not connected with IPv6, communication should
happen, otherwise the implementation is non-conformant.

If the two systems are connected with IPv6 and not IPv4, communication
should happen, otherwise the implementation is non-conformant.

Communication, or the lack of it, is clearly a property that's
observable at the JS application level.

(the detail that the IPv* addresses are visible in the candidates and in
the SDP is an implementation detail that doesn't belong here.)

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

Or maybe rewritten to a language that we both understand. Leaving it
roughly as-is for the moment.

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

Added forward pointer, since I now have somewhere for it to point.
>>> 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'll add some general words about 5-tuples and 6-tuples to the QoS section.
Let's see if that resolves the remaining issues below; I don't want to
use too much time on this before launching a revised document to invite
others' comments.



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

This got cleared up in London - SCTP would go over 4571 too.

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


-- 
Surveillance is pervasive. Go Dark.