Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00

Magnus Westerlund <> Fri, 15 November 2013 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9736D11E8102 for <>; Fri, 15 Nov 2013 01:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CvPmeNfX9Bi9 for <>; Fri, 15 Nov 2013 01:02:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C4A6811E8109 for <>; Fri, 15 Nov 2013 01:02:17 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-e8-5285e318c967
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C3.CE.23787.813E5825; Fri, 15 Nov 2013 10:02:16 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.328.9; Fri, 15 Nov 2013 10:02:16 +0100
Message-ID: <>
Date: Fri, 15 Nov 2013 10:02:16 +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: "Ram Mohan R (rmohanr)" <>, "" <>, "" <>
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+NgFuplluLIzCtJLcpLzFFi42KZGfG3VlficWuQwdYz+hYrnjxisVjetYPR Yu2/dnYHZo8pvzeyeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGXuXn2Et+KpdcWHzZ6YG xrlKXYycHBICJhKLvhxhhLDFJC7cW8/WxcjFISRwiFFi6b497BDOckaJJf9/soJU8QpoS3w9 2cfcxcjBwSKgKvH8tCdImE3AQuLmj0Y2EFtUIFji/KvF7BDlghInZz5hAbFFBM4zShz5LgRi Cwu4SCyecZIZxBYS0JP48OUxE4jNKaAvcXvqTVaQ8RIC4hI9jUEgYWagkilXWxghbHmJ5q2z oVq1JRqaOlgnMArOQrJtFpKWWUhaFjAyr2Jkz03MzEkvN9zECAzSg1t+6+5gPHVO5BCjNAeL kjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYRVIdOWUuTIu4JesrsX5fznHmJ3qG 4btsrvx/o/TnkOa/8G1d3ftkc7puXhZV09Lz73eXq7th1nNuc8pGx2QfNe/m36csp3dNWfG4 wN9kyb4s/djU6xs2qQhV+h5f5zXnQNLeFWw/7be9FVu1zXblzLNCfrxMJhEf68+t4F/+qF9b 9m/u2+lvlViKMxINtZiLihMBvwo7/iACAAA=
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
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: Fri, 15 Nov 2013 09:02:24 -0000


Removing things where I am in agreement or like your response.

On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote:
> Hi Magnus,
> Thanks for your comments. Please see inline for responses.
> -----Original Message-----
> From: Magnus Westerlund <>
> Date: Tuesday, 12 November 2013 8:28 PM

>> 3. Section 1:
>> "This document describes a new STUN usage with a request and response
>>   which verifies the remote peer consents to receive traffic, and
>>   detects loss of liveness."
>> I am missing a word after "request and response", transaction or
>> messages maybe?
> NEW:
> This document describes a new STUN usage with a request and response
> messages which verifies the remote peer consents to receive traffic, and
> detects loss of liveness.

Isn't it either "which verifies the remote peer's consent to" or "which
verifies that the remote peer consents to"?

>> 5. Section 4:
>>   Consent freshness serves as a circuit breaker (so that if the path or
>>   remote peer fails the WebRTC browser stops sending all traffic on
>>   that remote peer), determining session liveness serves the purpose of
>>   notifying the application of connectivity failure so that the
>>   application can take appropriate action.
>> What is the definition of a peer here?
> Peer is the sink for the traffic originated from the sender for that flow
> (5 tuple). If a browser uses different 5 tuple for each stream(Audio,
> video, data) it sends then it should do consent for each flow. If it uses
> same 5-tuple (mux case) then there will be only one consent.

Please be explicit about this. I think it is easy to interpret that this
would apply to all flows from one end-point to a given destination address.

>> What scope does the stop sending
>> have?
> The stream that is being sent on a flow(5 tuple) for which a consent has
> failed will be stopped. If all the streams are muxed on a same 5 tuple the
> entire traffic will be stopped.

I am fine with this, as long as the document is explicit about this
being the scope.

>> 6. Section 4:
>>   1.  A consent timer, Tc, whose value is determined by the browser.
>>       This value MUST be 15 seconds.
>> I see a contradiction here, should it be determined by the browser or be
>> 15 s? If it is 15, can you please motivate why it is this value, or
>> point to where it is motivated?
> The default value of 15 was some thing that EKR and Justin gave us based
> on the implementation/testing and fine tuning they have done on their
> browsers. I agree we can have some text around it that explains how this
> number is arrived. We will add the same.

Good, I think it is important we understand the considerations of why
this is a reasonable choice.

>> 8. Section 4:
>>   If a valid STUN Binding Response is not received after 500ms, the
>>   STUN Binding Request is retransmitted (with the same Transaction ID
>>   and all other fields).  As long as a valid STUN Binding Response is
>>   not received, this retransmission is repeated every 500ms until Tf
>>   seconds have elapsed or a valid response is received.
>> So no exponential back-off on the retransmission timer. I think that is
>> fine. However, I think it do require you to expand a bit on what happens
>> when one gets multiple response on the same Transaction ID. For example
>> additional responses do they or do they not reset the Tc timer?
> Additional responses MUST reset the Tc timer.

Okay, that appears fine.

>> Then I wonder about the cases where the RTT is above 500 ms, should one
>> then scale this factor to be once per RTT?

What about this question?

>> 9. Section 4:
>> "with the same Transaction ID"
>> Why not use a new transaction ID for each sent packet? It would allow
>> tracking loss and determine RTT more reliable. All for the small cost of
>> keeping track of slightly more Transaction IDs?
> Yes, new transaction ID will help to determine the packet loss and RTT.

Yes, so what is preferable here? Doing cloned retransmission, or
generating new TIDs for each outgoing request?

>> 10. Section 4.
>>   Liveness timer: If no packets have been received on the local port in
>>   Tr seconds, the WebRTC browser MUST inform the JavaScript that
>>   connectivity has been lost.  The JavaScript application will use this
>>   notification however it desires (e.g., cease transmitting to the
>>   remote peer, provide a notification to the user, etc.).  Note the
>>   definition of a received packet is liberal, and includes an SRTP
>>   packet that fails authentication, a STUN Binding Request with an
>>   invalid USERNAME or PASSWORD, or any other packet.
>> I think this requires some considerations in regards to RTT. If the RTT
>> is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
>> = 1 second would fire on a single loss.
> Ok.  will start a discussion for this item in a separate email.



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: