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

Martin Thomson <> Wed, 27 February 2013 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 702CC21F8830 for <>; Wed, 27 Feb 2013 11:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.828
X-Spam-Status: No, score=-6.828 tagged_above=-999 required=5 tests=[AWL=-3.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oSBnhPhN0v7m for <>; Wed, 27 Feb 2013 11:43:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8CFF521F87EE for <>; Wed, 27 Feb 2013 11:43:50 -0800 (PST)
Received: by with SMTP id fn15so815353wgb.32 for <>; Wed, 27 Feb 2013 11:43:49 -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:content-transfer-encoding; bh=rUEAU/AIIOD6VP3djaWenfFqAfTM0uIV9Qt1TmpZMvw=; b=q5b4Cx2s55b4eITBP68r1QoTqT7G4+cIo3SOU+u4v60PQ4ypGhq3d4CGsF+CsfzrVQ lDxdPMPjFrNdsZuIJhqObsp3hOLf0RiTZ2FYDYadrDSqxsL3nH/DetFAmE7Dixkg2mb2 1IzzZukx78anWSB8xVMMQ/0jh6mF1U3wNui3Itj+ELe0fJWPsnenxTuSZnZ/IaPit2Gx 1XDbZEm7lQf4F4b5mcq7jDOedHATMa1KgQy2JHNnRL2dbWXLOKoRq/zDzjlTlJJIVkFf lHw2AwAftIi7MBQGS7jJacU8TBwdvS82GOOmCFSJr6mRhik4SgPJwjStPHibRn8nOk+B J+rA==
MIME-Version: 1.0
X-Received: by with SMTP id o3mr28870972wix.9.1361994229731; Wed, 27 Feb 2013 11:43:49 -0800 (PST)
Received: by with HTTP; Wed, 27 Feb 2013 11:43:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 27 Feb 2013 11:43:49 -0800
Message-ID: <>
From: Martin Thomson <>
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 27 Feb 2013 19:43:51 -0000

> In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the requests are retransmitted until a response is received, or until a total of 7 requests have been sent (assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently guarded against transitory network failures.

That's far too much.  And the backoff is designed for completely
different situations.

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?  Keep in mind that the latter
choice means that you aren't really sending a check every second any
more, despite agreeing to do so.

> However, with the default 500 ms RTO recommended in RFC5389, it would take 39.5 sec for the transaction to timeout -- this was considered too long to declare a consent freshness failure.

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

> One option could be to define a new STUN transaction that doesn't do the exponential backoff for retransmission, but instead retransmits at periodic intervals and declare failure if there is no response after sending a bunch of them, as you are suggesting. But, I am not sure at this point how that would be both superior compared to the transaction defined in RFC5389 and sufficiently guard against transitory network failures.

I think that the document only needs to talk in terms of "checks" or
Binding requests rather than transactions.