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

Magnus Westerlund <> Mon, 31 March 2014 09:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3EC5B1A098B for <>; Mon, 31 Mar 2014 02:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ICX0WtHu7-qD for <>; Mon, 31 Mar 2014 02:41:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4D5451A0901 for <>; Mon, 31 Mar 2014 02:41:54 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f328e0000012ab-96-5339385eb31a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9B.A3.04779.E5839335; Mon, 31 Mar 2014 11:41:50 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 31 Mar 2014 11:41:49 +0200
Message-ID: <>
Date: Mon, 31 Mar 2014 11:41:49 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Harald Alvestrand <>, "" <>, Harald Alvestrand <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3RjfOwjLY4PsCdYtjfV1sFidunGa2 WPuvnd2B2ePKhCusHgs2lXosWfKTKYA5issmJTUnsyy1SN8ugSvjRuNWloJtJhUbVuc1MHZr dTFyckgImEj82vaDFcIWk7hwbz1bFyMXh5DAYUaJgwebWSGc5YwSr/40soFU8QpoSxw7dwXM ZhFQlfg/6zI7iM0mYCFx8wdEjahAsMTSOYtZIOoFJU7OfAJkc3CICJRL/PknDxIWFnCUePJ6 BiPE/HZGiTtnjjGC1HAK6Eos+ZEAYkoIiEv0NAaBlDML6ElMudrCCGHLSzRvnc0MYgsBXdPQ 1ME6gVFwFpJls5C0zELSsoCReRUje25iZk56ueEmRmCAHtzyW3cH46lzIocYpTlYlMR5P7x1 DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWPOWwY/p9ZW/U7oNmTvck+42MkhMTTf+2Prh 9Z4pL958ubRKnOecQ5LkLY/VTFmzM6zv7ahZ+XSP6r6TXDIswl+sbp6Ok5tfrdu7+9OGbSdf CE9jTmywn1d3pkRn1/Z5b49Nj5Jd32PXrfaOIVO4oOPlRzFphXblYiYNtVPZwk/DPp39+L/7 ghJLcUaioRZzUXEiAKYkeQseAgAA
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Mar 2014 09:41:57 -0000

Please see inline.

On 2014-03-30 22:46, Harald Alvestrand wrote:
> 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:

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

I am not disagreeing with what you write above. However, the
implementation requirement on supporting IPv6 and IPv4 is on the WebRTC
endpoint, i.e. the media framework, the ICE implementation etc. A JS
application should be IP version agnostic as long as it doesn't much SDP

That is why I raised this issue about "application" rather than the
WebRTC endpoint being the one that should support both IPv4 if endpoint
is provisioned with them.

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

Yes, rewrite is likely good.

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


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

Okay, I am fine with doing this incremental so that we can figure out
the appropriate boundaries and bring other docs up to required level also.


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: