Re: [Wish] How to detect a crashed client?

[Christer Holmberg <[e-mail]>]

Hi,

>> The main purpose of ICE consent freshness is not to detect crashed endpoints. For that ICE keepalives are enough.
>
> While it is true that the purpose of ICE consent is not to detect crashes, it does allow to detect that is no longer useful to waste bandwidth by sending data to an endpoint which isn’t listening any more for what ever reason. 
> Which I guess in case of Wish would mean only the client would implement ICE consent to detect that the server is no longer receiving the data.
>
> But at least in the browser WebRTC world ICE consent simply has replaced ICE keepalives. Mostly because ICE keepalives worn’t working really well. So I would recommend to stay away from ICE keepalives for Wish.

Sure, but I just think it needs to be clear that, as far as the standard is concerned, ICE consent is not required for making sure the peer is alive. But, if you are anyway going to do ICE consent, you can of course also use it for check-that-the-peer-is-alive purpose.

However, it was also suggested that the server would use ICE consent towards the client. That sounds a little weird to me, as there will be no media in that direction to begin with.

Regards,

Christer


 
From: Wish <mailto:[e-mail]> On Behalf Of Sergio Garcia Murillo
Sent: perjantai 10. syyskuuta 2021 23.53
To: Nils Ohlmeier <mailto:[e-mail]>
Cc: WISH List <mailto:[e-mail]>; Juliusz Chroboczek <mailto:[e-mail]>
Subject: Re: [Wish] How to detect a crashed client?
 
 
El vie., 10 sept. 2021 22:42, Nils Ohlmeier <mailto:[e-mail]> escribió:
 
On Sep 9, 2021, at 13:10, Sergio Garcia Murillo <mailto:[e-mail]> wrote:
El jue, 9 sept 2021 a las 19:52, Nils Ohlmeier (<mailto:[e-mail]>) escribió:
[With my individual contributor hat on]

I think Sergios description above is actually not fully correct.

With ICE consent the client and the server both run their own independent ICE consent checks.
So the client sends consent requests and server answers them. And the server sends consent requests which the client has to answer.
If the client crashes, the servers consent checks will get no responses and then after 30 seconds can delete the PeerConnection.
 
That's true in case of full ice servers, but servers may be ice lite which shouldn't send ice requests.
 
Good point. Although I want to highlight for folks not that familiar with ICE specs that technically nothing forbids an implementer from claiming his server is an ice-lite implementation, but then to send out consent requests once the connection is established. I would argue that this still makes your implementation considerably easier compared to a full ICE stack.
 
that's exactly what I have implemented in my media server, I call it ICE lite+ 🤣



 

But yes if the server then would delete the PeerConnection right after consent timed out I assume it would make it hard to execute an ICE restart if the client requests that N seconds later. This is different from the browser case, where the ICE consent timeout only changes the ICE connection state, but does not directly affect the lifetime of the PeerConnection itself.

I would suggest that instead of messing with the timers for ICE consent on the two different sides of the connection - BTW for browser endpoints the JS client can’t change the ICE consent timeout value - the spec should mandate that server endpoints need to keep the PeerConnection around for another N seconds after ICE consent timed out.
 
I am not sure if we should mandate it in the spec, setting a timeout grace period once the ice timer has expired could be implementation specific. The client has no way of knowing the exact timeout on the server side, so it would have the same effect to raise the timeout server side, or have a grace period deleting the session server side.
 
Also, in case of ice restart the behaviour would be the same, the whip client would have to try an ice restart, and if the session is not found, do a full restart (based reconnection policies on client side).
 
IMHO, doing an ice restart after 30s or 40s of disconnection does not offer any benefit over full restart, but others may not think alike. 
 
I fully agree on the 30s here.
So maybe the easiest is then to let the client side decide when to give up with ICE consent. And it needs to be prepared to handle a 404 on it’s ICE restart request, to then do a full restart of the connection.
 
Completely agree.
 
Best regards 
Sergio