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

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Thu, 14 November 2013 17:23 UTC

Return-Path: <rmohanr@cisco.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 7736921F9C55 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 09:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8]
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 9rCFrajAA-G7 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 09:23:44 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6621F9A7D for <rtcweb@ietf.org>; Thu, 14 Nov 2013 09:23:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6656; q=dns/txt; s=iport; t=1384449823; x=1385659423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4if+Vm5opCkbp6k+EZMMzyp4JXMBE/stETYuWU7YWow=; b=jhVvn1DZ9CBXrV6pcGdql5zD/+73AOD/qD0d0EzKmj4U/YNNYT6yStBJ SxP05insP9C+AnDKRe1dwheDqrUVj8B9/3bcqTPRh41fnMXW1CqxpgJbd MXwga7lR95QPRQLabfT9XIoaExV995dVdxn76kEAXM+MstBE8iVd2130t w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAAwGhVKtJXG+/2dsb2JhbABagweBC78hgSAWdIIlAQEBBAx5AgQBCBEDAQIZDyIXFAkIAgQBEogBwEMEjhKBUAYShBkDiQqKYoQkkgyDKIFxOQ
X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284863178"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2013 17:23:43 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAEHNhq0019562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 17:23:43 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.193]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:23:42 -0600
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO4V5D8ro8smXte0emoSniQAx1Dw==
Date: Thu, 14 Nov 2013 17:23:42 +0000
Message-ID: <CEAB0083.6FBE3%rmohanr@cisco.com>
In-Reply-To: <52824222.2000907@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.65.51.158]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FD2E0F79DFE28443AB2FD46EB1433A8D@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.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: Thu, 14 Nov 2013 17:23:50 -0000

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
To: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org"
<draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>rg>,
"rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
Resent-From: <draft-alias-bounces@tools.ietf.org>
Resent-To: <dwing@cisco.com>om>, <mperumal@cisco.com>om>, Cisco Employee
<rmohanr@cisco.com>om>, <tireddy@cisco.com>
Resent-Date: Tuesday, 12 November 2013 8:27 PM

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

Ok. We will add text in Abstract/Introduction to reflect this point.

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


Yes. We will add text to make it clear.

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



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

Agree will replace with "verify"

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

Thanks. will fix this.


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



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

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


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

Consent timer is reset to the time of receiving it


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


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

Yes, new transaction ID will help to determine the packet loss and RTT.



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


Regards,
Ram


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