Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 13 February 2014 08:15 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF3F1A0169 for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 00:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh-3eG1zYWiS for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 00:15:01 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0D1A0113 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 00:15:00 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-62-52fc7f028243
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B8.AF.23809.20F7CF25; Thu, 13 Feb 2014 09:14:58 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.347.0; Thu, 13 Feb 2014 09:14:57 +0100
Message-ID: <52FC7F01.7090406@ericsson.com>
Date: Thu, 13 Feb 2014 09:14:57 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CEAB0083.6FBE3%rmohanr@cisco.com> <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com> <CF17D349.7A310%rmohanr@cisco.com>
In-Reply-To: <CF17D349.7A310%rmohanr@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rpep/k+QwZtPIhbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWce/aGtWCDasXtx08YGxh3yHYxcnBICJhI nJkX1cXICWSKSVy4t56ti5GLQ0jgEKPEqz9HWCGc5YwSEzddZgap4hXQlth97SOYzSKgKrHk z18mEJtNwELi5o9GNhBbVCBYYueB34wQ9YISJ2c+YQGxRQTCJKafWABmCwu4SCyecZIZYsEm RokVE/pZQRKcAvoSHz8cZ4S4TlyipzEIJMwsoCcx5WoLI4QtL9G8dTbYDUJA9zQ0dbBOYBSc hWTdLCQts5C0LGBkXsXInpuYmZNebrSJERiSB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUw7l5/IYYn8PL5BK656t1nv5TZGry6EXaV+Z3U7vtNNj1J PyfvsXm1Wkzo2LKcrwUXW6cu4LOxn/z464m1B5tEpMWseFY/KdBUlDj4TPvk9Jnii212ndpa pm4tmOYW7ajIHHbtA9djq7Wim842LpX54L/yckJz/nkJhr8ccm9l7Nb0/v8ke+9UuBJLcUai oRZzUXEiAF8t8z4XAgAA
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 13 Feb 2014 08:15:05 -0000
Hi, (As individual) removing the parts that appears resolved. On 2014-02-05 07:19, Ram Mohan R (rmohanr) wrote: >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote: >>> From: Magnus Westerlund <magnus.westerlund@ericsson.com> > > > >> >> >>>> >>>> 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? > > The ICE agent can learn the RTT of a given path from RTCP reports (if > present). If there is no RTCP reports then it can use STUN BindReq/Res to > learn RTT. > > STUN allows you to learn the RTT of a path when you sending Binding > request and get a Binding response for a candidate pair. Before consent > timer > is started the browser¹s ICE agent would have done ICE checks and > concluded on a candidate for each media stream. So an ICE agent can use > the RTT learnt here. > Thoughts on this ? I think using the STUN connectivity checks to gather an RTT estimate is fine for this and likely the easiest. That avoids the need to have the RTCP stack closely integrated with the consent mechanism. And if I understand each new request has a new Transaction ID, that way one can keep a running filtered RTT estimate to use for this. But, I do believe that we should ha a mechanism in place to protect against RTTs > 500 ms. In buffer bloat case, as well as certain paths they do occur. > > >> >>>> >>>> 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? > > Using same Transaction ID would lead the peer ICE agent think this request > as a retransmission and it may not reset its Consent timer. So I think > using new ID is better. Good, lets use a new TID. > > > >> >>> >>> >>>> >>>> 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. >>> > > As discussed above the ICE agent can learn the RTT of a given path from > RTCP reports (if present) or compute the RTT from STUN BindReq/Response. > It can then use the learnt value > to influence the Tr value. I will leave it to you to consider how to use and specify a proposal for this. Cheers 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: 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