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

Martin Thomson <> Thu, 28 February 2013 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 056FE21F8855 for <>; Thu, 28 Feb 2013 10:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.455
X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=-2.856, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iw7zy8HImkAS for <>; Thu, 28 Feb 2013 10:32:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4258221F8771 for <>; Thu, 28 Feb 2013 10:32:47 -0800 (PST)
Received: by with SMTP id fn15so1767768wgb.32 for <>; Thu, 28 Feb 2013 10:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1wK7xpmt4tlFswdkqq8yopasUrJRxTdeoI/WMiPIOJc=; b=XY1ykih6I9NhU4bCIJCF4HUyYca8DQVM1Y4L+X5XwrvqFwVn58VnXYzjsyMdHd2g3i 5gjWv4xhrGhRfb74F/zBCPr/ePQ1wliV2dZmQST6kVHpgGY2+Eamwuk52ij0SvMG9Zy0 kRIY92RwbhQEobE3EmpovHI+bLozgQyZ0R3h2Q0grfQh7x74Yb6vbt7TQjim2X+1/D7H SyucomvD+ftYcNN9Qn2frHgHM4f4gbw8aeByUDJhjNKqfXbj5brX7e9bm+/qJp7b/6az zQ7EEpRNPR3/NE6HnMEe+TJ5x7TRhoEABB1W3GVGjTPFaT/SUvLpdOhnnXgbIfhvj8s2 IaZg==
MIME-Version: 1.0
X-Received: by with SMTP id s9mr12992465wjs.5.1362076366491; Thu, 28 Feb 2013 10:32:46 -0800 (PST)
Received: by with HTTP; Thu, 28 Feb 2013 10:32:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 28 Feb 2013 10:32:46 -0800
Message-ID: <>
From: Martin Thomson <>
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Feb 2013 18:32:48 -0000

On 28 February 2013 09:45, Muthu Arul Mozhi Perumal (mperumal)
<> 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.

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