[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 ----------------------------------------------------------------------
- [rtcweb] Comments on draft-ietf-rtcweb-stun-conse… Magnus Westerlund
- Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-c… Ram Mohan R (rmohanr)
- Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-c… Magnus Westerlund
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Bernard Aboba
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Martin Thomson
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Bernard Aboba
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Michael Tuexen
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Martin Thomson
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Christer Holmberg
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Christer Holmberg
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Martin Thomson
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Martin Thomson
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-… Roman Shpount
- Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-c… Ram Mohan R (rmohanr)
- Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-c… Magnus Westerlund