Re: [rtcweb] Consent alternative

tim panton <tim@phonefromhere.com> Fri, 22 November 2013 18:41 UTC

Return-Path: <tim@phonefromhere.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 8CD2E1AE1C7 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 10:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DU01vITeG-w6 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 10:41:52 -0800 (PST)
Received: from smtp001.apm-internet.net (smtp001.apm-internet.net [85.119.248.220]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6C1AE206 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 10:41:51 -0800 (PST)
Received: (qmail 8690 invoked from network); 22 Nov 2013 18:41:43 -0000
X-AV-Scan: clean
X-APM-Authkey: 83769 11343
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 22 Nov 2013 18:41:43 -0000
Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CB02C18A046C; Fri, 22 Nov 2013 18:41:43 +0000 (GMT)
Received: from [10.10.5.18] (205.158.164.101.ptr.us.xo.net [205.158.164.101]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 05BC318A0461; Fri, 22 Nov 2013 18:41:36 +0000 (GMT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: tim panton <tim@phonefromhere.com>
In-Reply-To: <BLU169-W84AAFA395B7844922F472C93E00@phx.gbl>
Date: Fri, 22 Nov 2013 10:41:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ACE36C2-EE49-4EBB-999A-71F92430F8E3@phonefromhere.com>
References: <CABkgnnVNnT8uoWM8T=TqbTmy11CGTeHLP=_7z5KSMSpAsp9SyQ@mail.gmail.com>, <9E5D7D59-0536-469E-8CB7-440FF27F0B41@phonefromhere.com> <BLU169-W84AAFA395B7844922F472C93E00@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Consent alternative
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: Fri, 22 Nov 2013 18:41:53 -0000

On 22 Nov 2013, at 10:28, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> > This proposal seems (at first glance) to make them intertwine in a quite complex way 
> 
> [BA] Might I point out that we already have two mechanisms that affect a sender's ability to continue to send to a given receiver: consent and circuit breakers.  So the complexity you speak of is already there.  For example, the studies we have seen so far raise questions about whether circuit breakers are very likely to fire prior to consent loss, potentially shutting off the packet flow even in situations where consent would be provided.   In those situations, the ICE consent mechanism serves merely to add overhead while providing little or no additional protection.

I need to think about that some more, but my first feeling is that the proposal deepens the interdependency because it means each sender has to notify a central timer to indicate that a consent-requesting packet has been sent and kill the deadman’s handle on the DTLS keep-alive. The ICE mechanism is clearer - you send the packets anyway with no dependency on whatever else has been sent.

I also need to think about how RTCP plays into this (which isn’t mentioned in the draft, and probably should be).

This whole discussion makes me yearn for a cleaner non-layered protocol - like RFC 5456 - but if we are to have layers we should keep them apart as far as possible.

T.