Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

Salvatore Loreto <salvatore.loreto@ericsson.com> Sat, 02 March 2013 06:26 UTC

Return-Path: <salvatore.loreto@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 80D2221F90B3 for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 22:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.175
X-Spam-Level:
X-Spam-Status: No, score=-106.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ghq5XT5DtB for <rtcweb@ietfa.amsl.com>; Fri, 1 Mar 2013 22:26:09 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E64421F8D65 for <rtcweb@ietf.org>; Fri, 1 Mar 2013 22:26:01 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-76-51319b78baee
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B7.73.32353.87B91315; Sat, 2 Mar 2013 07:26:00 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sat, 2 Mar 2013 07:25:59 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 22C5D2443 for <rtcweb@ietf.org>; Sat, 2 Mar 2013 08:26:00 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7DC6D54165 for <rtcweb@ietf.org>; Sat, 2 Mar 2013 08:25:57 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 303B9540A0 for <rtcweb@ietf.org>; Sat, 2 Mar 2013 08:25:57 +0200 (EET)
Message-ID: <51319B77.6050900@ericsson.com>
Date: Sat, 02 Mar 2013 08:25:59 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20130225182705.666.1653.idtracker@ietfa.amsl.com> <E721D8C6A2E1544DB2DEBC313AF54DE224023E19@xmb-rcd-x02.cisco.com> <CABkgnnXkBSTNPDw-e=RMOU9UsucPeQyFya6w0R83CZvUqww_-A@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE22402509E@xmb-rcd-x02.cisco.com> <CABkgnnV3Oo2B8xyeb1=-3pu0b81Xhk5D_-TYmu3Swmsi-JY8Lw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE224029975@xmb-rcd-x02.cisco.com> <CABkgnnUti73HVLp7x4jrZmq8xmt7PMrv0UTAAoi0rkE_Z0W15g@mail.gmail.com>
In-Reply-To: <CABkgnnUti73HVLp7x4jrZmq8xmt7PMrv0UTAAoi0rkE_Z0W15g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW7FbMNAg9cLtC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu0Hl9kL9vJXzJns18C4iaeLkZNDQsBE4v3sb4wQtpjEhXvr 2boYuTiEBE4ySlxtv8IM4axnlNg9dxNU5gKjxIYzVxghnMOMEhPPH4VyzjBK/Hy1mA1kGK+A tsSE63NYQGwWARWJfd9PMoHYbAJmEs8fbmEGsUUFkiX+PTrCCFEvKHFy5hOwehEBYYmtr3rB 6oUFAiUOdd1nglrNLPF8x06wBZxAibl/H4PZzAK2EhfmXGeBsOUltr+dwwzxkZrE1XObwGwh AS2J3rOdTBMYRWYh2TcLSfssJO0LGJlXMbLnJmbmpJebb2IEhvPBLb8NdjBuui92iFGag0VJ nDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaNR030zVdz9S9oflq2hP1bnN6MHbK7 z4e8uRPPffqBdL+5uGe9a5/eoaUdCtWhBU5COf9mvg61W828ctlaMfOPn75e7E6/ePBl3MTP 3ze4zH958dx6s+hwwSi3whx7zy/6POtuWdufj3jwYtrrW46CEklz/x65XR62JHayK+NeTbE7 /84ISk1WYinOSDTUYi4qTgQAfT8okzUCAAA=
Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
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: Sat, 02 Mar 2013 06:26:18 -0000

On 2/28/13 8:32 PM, Martin Thomson wrote:
> On 28 February 2013 09:45, Muthu Arul Mozhi Perumal (mperumal)
> <mperumal@cisco.com> wrote:
>> |Imagine that you are running Tr at 1 second, with a complete
>> |transaction required before you do anything.  Do you run 39 in
>> |parallel with hundreds of checks, or do you not create a new
>> |transaction when another is outstanding?
>>
>> Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful:
> I would expect that to be hard for a low Tr value.  Overlapped
> requests seem like a real possibility for Tr=1s.
>
>> - Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery).
> Be careful here that you don't create a failure mode whereby you lose
> NAT bindings.
I agree with Martin,
you should be careful (I suggest to remove it) with this constrain as 
you also recommend (SHOULD) not to use
ICE keep alive and RTP keepalive

>
>> - Don't generate a new liveness check if any traffic was received since the last liveness check.
> Definitely.  Mandatory even.
>
>> |We've discussed tightening the timers once the session is live.  We've
>> |also discussed tightening timers when the session is starting.  Both
>> |of which I would have expected to see in the document as proposed
>> |solutions.
>>
>> Not sure I understood. Do you mean tightening the backoff timer?
> The initial timer and the number of rounds before giving up.  In fact,
> I don't consider exponential back-off to be a useful feature for a
> live flow.  It's there to help avoid overwhelming unknown peers with
> checks.  Exponential back-off could go entirely.  Hence the suggestion
> for a constant interval.  A constant interval also avoids having
> transitory problems trigger unnecessarily harsh actions like ICE
> restart.
remove back-off seems a reasonable thing to do

/Salvatore