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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 12 November 2013 14:57 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B6E11E8169 for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 06:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.718
X-Spam-Level:
X-Spam-Status: No, score=-103.718 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v09jYz5zpgCx for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 06:57:39 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A80D511E8143 for <rtcweb@ietf.org>; Tue, 12 Nov 2013 06:57:38 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-b0-528241dce60d
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 41.92.27941.CD142825; Tue, 12 Nov 2013 15:57:33 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 15:57:32 +0100
Message-ID: <52824222.2000907@ericsson.com>
Date: Tue, 12 Nov 2013 15:58:42 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFJMWRmVeSWpSXmKPExsUyM+Jvre5dx6Ygg/kv2CxWPHnEYrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJVxdEZ+Qb9yxf3L7UwNjOekuxg5OSQETCRa //1ghrDFJC7cW8/WxcjFISRwhFHi4KF1LBDOckaJ2zdOADkcHLwC2hJzfkmDmCwCqhKT38SB 9LIJWEjc/NHIBmKLCgRLnH+1mB3E5hUQlDg58wkLiC0ikCJx4tE8sF3CAg4Shw5PYAIZIyEg LtHTGAQSZhbQk5hytYURwpaXaN46G6xcCGhpQ1MH6wRG/llIps5C0jILScsCRuZVjBzFqcVJ uelGBpsYgeF1cMtvix2Ml//aHGKU5mBREuf9+NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjjhIXb0mH1tKbTgc7xFQWHzm4aWr23gMSj5o538eErXh/ve2ouq6Y20fVrcKn+1tYbZ4I nXCpNNpoycT+7+R957qDsoz3LSsypRR+zbi30tGZN0SwYmrgp/uert5/F3BUXRC8/brcTj2u b0L7E6XqgpqD7Y99CzTmNBysuu2RuqzX4+uzJaVKLMUZiYZazEXFiQAqGmSR/QEAAA==
Subject: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 14:57:47 -0000

Hi,

Here are my review comments on draft-ietf-rtcweb-stun-consent-freshness-00

1. General:
I understood one reason for splitting this out in its own document is
that we might have other future users of this mechanism. Thus I think it
should be written to be less WebRTC specific. It is appropriate to use
WebRTC as motivation for requirements etc, but the actual description of
the mechanism should be done in a neutral way.

2. Section 1.
   When a session is first established, WebRTC implementations are
   required to perform STUN connectivity checks as part of ICE
   [RFC5245].  That initial consent is not described further in this
   document.

When generalizing this, I think it is important to make clear that it is
assumed that ICE is being used for that initial consent.

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?

4. Section 3:
 A
   response is necessary both for consent to continue sending traffic,
   as well as to ensure connectivity.

Is verify rather than "ensure" better?

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.

traffic on/traffic to

What is the definition of a peer here? What scope does the stop sending
have?

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?

7. Section 4:
   If a valid STUN Binding Response is received, the consent timer is
   reset and fires again Tc seconds later.

Is it reset to the time of receiving it or the time of sending the
initial request this is the response for?

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?

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

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?

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.

Cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------