Re: [rtcweb] Consent alternative

[tim panton <[e-mail]>]

On 22 Nov 2013, at 10:28, Bernard Aboba <[e-mail]> 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.