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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Wed, 05 February 2014 06:19 UTC

Return-Path: <rmohanr@cisco.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 A1D051A0047 for <rtcweb@ietfa.amsl.com>; Tue, 4 Feb 2014 22:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.436
X-Spam-Level:
X-Spam-Status: No, score=-14.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 DyYlYhSyqJoM for <rtcweb@ietfa.amsl.com>; Tue, 4 Feb 2014 22:19:18 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8EE1A0045 for <rtcweb@ietf.org>; Tue, 4 Feb 2014 22:19:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7431; q=dns/txt; s=iport; t=1391581158; x=1392790758; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IzGkzFchKYBD70bVsRZquVvC22NbOJeRD6SzWlx464c=; b=HKcLFxxbZKZOy5iVoopTfbOidGsdwUAcUPFko2V8V6TXt5uvqkjUZwz/ obU/kZUL+fFsYS+7Jg0N42Gy/+eqkD7HhDkFHRMWzc2gKRUVJbY/rZqJT OVGpwaBoBeTId8bnA5SZklxNlv+0Y+aaew80+SlWMm4YAEbMfTBlNMvCH I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFABvX8VKtJXG8/2dsb2JhbABZgwyBD75MgQcWdIIlAQEBBAx5AgICAQgRAwEBAQEYDwcbFxQJCAIEARKIBc5IFwSODxEBVwYShCAEiRGKb4QrkiGDLYFxOQ
X-IronPort-AV: E=Sophos;i="4.95,785,1384300800"; d="scan'208";a="301954787"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2014 06:19:16 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s156JG1K001673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 06:19:16 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 00:19:15 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO37eJ8ro8smXte0emoSniQAx1D5olYa0AgAEGPACAajfBYIAW1hEA
Date: Wed, 5 Feb 2014 06:19:14 +0000
Message-ID: <CF17D349.7A310%rmohanr@cisco.com>
References: <CEAB0083.6FBE3%rmohanr@cisco.com> <5285E318.3090006@ericsson.com> <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A2428EC28@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [72.163.212.124]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <800BA6F97370BB4A9943E82F9C6083FD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 05 Feb 2014 06:19:20 -0000

Hi Magnus,

Sorry for delay. Please see inline for answers


>-----Original Message-----
>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
>Sent: Friday, November 15, 2013 2:32 PM
>To: Ram Mohan R (rmohanr);
>draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.orgorg; rtcweb@ietf.org
>Subject: Re: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
>
>Hi,
>
>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 <magnus.westerlund@ericsson.com>
>> 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"?


I will change to "which verifies the remote peer's consent 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.

Sure. We will add the above text and make it clearer in Section 4


>
>> 
>> 
>> 
>>> 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.

Will make this explicit in the draft


>
>
>>>
>>> 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.

Sure. Will check with Justin/EKR and add some text that justifies why 15
sec is default.



>
>
>>>
>>> 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 ?


>
>>>
>>> 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.



>
>> 
>> 
>>>
>>> 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.

Regards,

Ram

>
>Good
>
>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
>----------------------------------------------------------------------
>