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

[Stefan Håkansson LK <[e-mail]>]

On 2011-09-23 11:33, Harald Alvestrand wrote:
> 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.

Right. But just for clarity, we're not removing the "default 
connection". Creating a PeerConnection will result in a connection 
(naturally the app in the other browser must also create a PC, and the 
signaling messages must be passed between them and so on for it to 
happen) being set up. My assumption has been that it is set up and kept 
alive using ICE, but I guess other methods are discussed.

> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb