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

Magnus Westerlund <> Wed, 13 November 2013 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C24D21F9F80 for <>; Wed, 13 Nov 2013 00:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.555
X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEGdthy+egVT for <>; Wed, 13 Nov 2013 00:24:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A749511E80FB for <>; Wed, 13 Nov 2013 00:24:33 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-7c-5283373fedee
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 1C.CE.15980.F3733825; Wed, 13 Nov 2013 09:24:31 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Wed, 13 Nov 2013 09:24:28 +0100
Message-ID: <>
Date: Wed, 13 Nov 2013 09:25:42 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: 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+NgFmphluLIzCtJLcpLzFFi42KZGfG3VtfevDnIYHqvrsWxvi42i7X/2tkd mDyuTLjC6rFkyU+mAKYoLpuU1JzMstQifbsEroy+L1/ZCw4EVCyffpm1gfGKfRcjJ4eEgInE /ouHWCFsMYkL99azdTFycQgJHGKUONrbwgrhLGeUuHLxMiNIFa+AtsSazqtMIDaLgKpE+8IH YHE2AQuJmz8a2UBsUYFgifOvFrND1AtKnJz5hAXEFgGK9z5/D1YvDFS/fN9WsLiQgI/E/kfb wOKcAroSC6ZsBrI5gC4Sl+hpDAIJMwvoSUy52sIIYctLNG+dzQzRqi3R0NTBOoFRcBaSbbOQ tMxC0rKAkXkVI3tuYmZOern5JkZgSB7c8ttgB+Om+2KHGKU5WJTEeT+8dQ4SEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwHgy7siELUrmudxHVYLansr0/cv46NQ3W65nX9Uyf4cJnKcLLLj/ ns99Zr33tGbSSUlXrXx73/N/PBcqvrIy5IjLTXmQW35+xor/xb9YPs/kSF42/4zd0+5DL0/Z iadE8GkeicrKy/E+q2bKryt4Z7n+jW3vvikEr+8q+T+bZe1LUb5ru6dkhyuxFGckGmoxFxUn AgD2rDDoFwIAAA==
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-01
X-Mailman-Version: 2.1.12
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: Wed, 13 Nov 2013 08:24:39 -0000


Many follow up comments inline.

On 2013-11-12 20:10, Harald Alvestrand wrote:
> On 11/12/2013 03:20 PM, Magnus Westerlund wrote:
>> Hi,
>> Here are my review comments on draft-ietf-rtcweb-transports-01:
>> 1. Front page: I would strongly suggest moving requirements language
>> into some numbered section.
>> 2. Section 2.1:
>>    o  TCP.  This is used for HTTP/WebSockets, as well as for TURN/SSL
>>       and ICE-TCP.
>> Are there really any need for ICE-TCP? Can't this simply be removed?
> This question belongs in 2.2 - it's a MAY requirement there (but there
> have been arguments in pntaw that it should be a SHOULD).
> In both cases,

Okay, I have responded to Partha's question because I don't understand
his motivation yet.

>> 3. Section 2.1:
>>    For both protocols, 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.ietf-rtcweb-qos].
>> First, I don't think one can assume the ability to set DSCP code points.
>> I think one should express that it is desirable to do it.
>> Secondly, I think one has to be aware that setting DSCP on a per packet
>> basis may be less commonly working than even just marking a flow
>> consistently.
> References? Is this an assumption, or based on actual
> experiments/experiences?

Hmm, I might have overstated my case here. I can't actually find a
reference to this. My observation digging through some APIs, like
Windows QoS2, and also the regular socket API is that they appear much
easier to use if you just set a DSCP rather than like to juggle it on
per packet basis. But, I can't support they are impossible to use.

>> Thirdly, the I-D.ietf-rtcweb-qos is dead, and if anything it should be
>> replaced by draft-dhesikan-tsvwg-rtcweb-qos-02.
> I will take instructions from the chairs on this point; I think we need
> to specify what -qos- used to say, and resurrecting that draft may be
> easier/better than adopting a new one.
> So far, I have not seen anything from the chairs (before now) that
> announces that it's dead.

Okay, we might not have been public enough on this. It was requested by
the Transport ADs quite some time ago that doing the QoS document in our
WG was not appropriate and requested us to direct the document to TSVWG.
Which was done, and where it hasn't made progress.

You might have noted that James Polk did comment in the milestone part
in the monday session of IETF88 about our QoS milestone should be killed.

>> 4. Section 2.1:
>>    If DSCP code points can only be set on a per-socket basis, not per-
>>    packet, one loses the ability to have the network discriminate
>>    reliably between classes of traffic sent over the same transport, but
>>    this does not prevent communication.
>> As this means all packets in the flow gets same treatment, one can point
>> out that using multiple RTP sessions and transport flows allow one to
>> have multiple different priority levels.
> That's an implication of what this says. The ability to differentiate
> between different flows is common enough that it is assumed.

Sorry, for being picky, but what flow definition are you using in the
above sentence. The one related to the applications flows, like an RTP
packet stream with the same SSRC, or a SCTP Stream, or do you mean all
packets with the same six-tuple, i.e. src addr, src port, dest addr,
dest port, Transport protocol, DSCP?

Even so, are there need to discuss also here the possibility that these
transport level limitations have impact on the default behavior of the
WebRTC implementation on what it suggest given that an application have
requested different priorities.

>> 5. Section 2.1:
>>    This specification does not assume that the implementation will have
>>    access to ICMP or raw IP.
>> I think it should point out the advantage of being capable of receiving
>> ICMP in MTU discovery.
> I think this is not realistic for the browser use case, where the stack
> is implemented as an unprivilleged application. I think the requirements
> need to be achievable in that situation, which is the point of this
> explicit non-assumption.

And my point is that not all WebRTC end-points will have this
limitation. I am all positive in describing the issues when you can't do
it, similar I do like to point out that when one can do it, one should
because it do give an significant advantage.

> That means that path MTU discovery for UDP will have to depend on
> observing the packet loss patterns, if done at all. I think that's
> realistic.

I agree that given no possibility to setting DF and receving ICMP one
will be limited. However, there appear to exist a possibility to read
the currently known IP MTU using the Socket API. This might actually be
relevant when using IPv6, where ICMP much more needs to work.

>> In addition I think you can bring up the benefits from being capable of
>> setting DF bit.
> Is there a benefit, given the point above?

I claim that not all WebRTC endpoints will have this limiation. Either
from being a central conference node with native implementation, or by
being a privileged application.

> Is there a common userspace way to achieve this?

I don't know about common, but some OS do appear to have settings for
it. For example Linux appears to have a setsockopt flag called
IP_MTU_DISCOVER which allows you to force the DF always on IP_PMTUDISC_DO.

>> 6. Section 2.2:
>>    ICE TCP candidates [RFC6062] MAY be supported; this may allow
>>    applications to achieve peer-to-peer communication across UDP-
>>    blocking firewalls, but this also requires use of the SRTP/AVPF/TCP
>>    profile of RTP.
>> I would question if this at all should be discussed. First of all a
>> TURN/TCP or TURN/TLS/TCP relay fulfills the needs to cross a only TCP
>> allowing firewall.
> The PNTAW discussion seems to indicate that there are scenarios where
> this is realistic.

Assuming that the result of the discussion is that it is needed.

>> Secondly, if one likes to use TCP/TLS/RTP/SAVPF then
>> one would need to use RFC 4571 framing, or do you have another proposal?
> I think the spec has to point to something that defines the framing,
> otherwise this won't achieve interoperability. Is RFC 4571 the right
> reference?

It is is one framing that is defined for RTP over TCP. It will be able
to carry also the DTLS and STUN packets over the TCP connection. The
main question is the need to define a signalling name for this,
especially if one likes to consider it as pure datagram service, instead
of specific ones. The alternative is that we will need
TCP/DTLS/RTP/SAVPF and TCP/DTLS/SCTP as signalling entities in SDP.

>> I would also note that such a combination do require us to do a bit of
>> specification work to bring RFC 4571 up to date to allow us use both
>> profiles beyond AVP as well as indicating usage of DTLS-SRTP over that
>> TCP framing. Considering that this appears to be a redundant and less
>> likely to work mechanism I would propose to remove it from consideration
>> even for MAY.
> Redundant with what other mechanism?

>From my perspective using end to end TCP with ICE-TCP is redundant from
the perspective of getting through restrictive firewalls compared to
TURN/TCP or TURN/TLS/TCP. I will agree with them not being identical,
but I question the motivation for requiring implementation of ICE-TCP
for this case, which anyway are supported by having TURN/TCP.

>> 7. Section 2.2.:
>>    o  TURN, including TURN over TCP[RFC5766].
>> Missing space between TCP and reference.
>> 8. Section 2.2:
>>    TURN over TLS over TCP MAY be supported.  (QUESTION: SHOULD?  MUST?)
>> I think MAY is a fine level for this. But it clearly should be an issue
>> raised to the WG for further debate.
> This is being debated on PNTAW.

I will look there, however I do recommend that the conclusion from that
discussion being posted to the WG list for confirmation.

>> 9. Section 2.3:
>>    The setup protocol for RTCWEB data channels is described in
>>    [I-D.jesup-rtcweb-data-protocol].
>> That draft is now a WG draft.
>> 10. Section 2.3:
>>    RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>>    the same port pair, as described in the DTLS_SRTP specification
>>    [RFC5764], section 5.1.2.  Further separation of the DTLS traffic
>>    into SCTP and "other" is described in <need reference>.
>> A. I would note that one actually must be capable of multiplexing DTLS,
>> RTP and STUN messages on the same port pair.
> That is described in RFC 5764 section 5.1.2. Since ICE is completely
> useless if it can't be multiplexed over the same port pair as the stuff
> it's probing for, I regard the ability to demultiplex STUN packets as
> implicit in the statement "we're using ICE".

Fine, the reference do include the STUN separation.

>> B. What about that needed reference. I think it is
>> draft-ietf-rtcweb-data-channel that should have this text.
> I'll check if it does.

Does not appear to have anything about this. But I think this is less
appropriate place to discuss that multiplexing.

>> 11. Section 4:
>> I think this document do need to discuss DSCP and ICMP and the issues
>> they can cause. Or possibly provide input to the security consideration
>> document.
> Please send text or pointers.

Will try.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: