Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]

[Harald Alvestrand <[e-mail]>]

On 09/23/11 09:21, Magnus Westerlund wrote:
> On 2011-09-22 18:51, Randell Jesup wrote:
>> I wonder: could we create a default reliable data channel in all
>> PeerConnections that's used (solely?) for a heartbeat/"consent freshness"?
>> In that case, we get to define the heartbeat and can mandate enough entropy.
>> (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.)
>>
> The short answer is Yes, you can. But the longer answer is that it might
> imply limitations on what deployments are possible.
>
> First of all, this is only in reality practical when you only have a
> single 5-tuple in use between the peers. If you don't multiplex all
> flows on a single 5-tuple then you will need both consent and keep-alive
> for each bi-directional flow the 5-tuple represents.
>
> Secondly, for any consent freshness / heartbeat you do need to transmit
> regularly. And considering common NAT timers for UDP we do need to have
> keep-alives no less often than every 15 seconds to try to ensure that
> the very aggressive timers of 30 seconds don't disconnect the session.
>
> Thirdly one are using resources both in establishing this reliable data
> channel, and then when using it for this function. Yes, you will spend
> some resources on heartbeat in all cases. But you might have to do it
> for multiple flow and then the reliable is an additional flow to
> keep-alive if it isn't used for anything else.
And fourthly, any spec that requires a heartbeat channel on the media 
path mandates a media path gateway in order to interoperate with 
non-RTCWEB devices.
> So I am not thrilled of establishing an additional flow just for consent
> freshness. In fact I am not thrilled by the PeerConnections default UDP
> unreliable channel and believe the transports should be only enabled
> upon demand from the application for such a transport.
We're removing it from the API spec. Whether or not it's mandated, 
that's not the right place to mandate it.
> I do see a simplicity in using ICE for keep-alive and consent freshness
> as this is likely applicable for all transport protocols that we need
> (as they will be over UDP) and aren't TCP to a relay or server.
>
> I do also notice that there are desire for alternative solutions.
>
> Lets keeps the discussion going.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>