Subject: [MMUSIC] ICE-10 Issue #6: What if Keepalives fail?

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Sep 2006 17:18:23 -0400

No version of ICE actually addressed this issue.

STUN-based keepalives are sent periodically after ICE completes, every 
15s, to keep nat bindings alive. It serves as a media and codec 
independent mechanism for binding keepalive.

The STUN checks also have the benefit that, should a keepalive fail, you 
can detect it. But - what do you do if a check should fail, or produce a 
new candidate, for example? The spec doesn't say.

There are several reasons a check might fail:

1. the remote peer has failed
2. an intermediate NAT has crashed and lost its bindings. This can cause 
a check to fail, or more oddly, to produce a new binding
3. network failure of some sort, like a partition
4. network congestion has caused loss of lots of media traffic, 
including stun keepalives

Several of these cases (1 and 3), there is nothing you can do but 
terminate the call. However, sending a BYE message is the wrong thing in 
cases 3 and 4. In case 4 its exactly the wrong thing, as it will only 
increase the load on the network.

ANother issue also is that 15s is a LONG time for a multimedia session, 
and likely a failure is detected much faster by a human user or even by 
RTCP than by the STUN keepalives.

The issue is really bigger than ICE, and it has to do with appropriate 
signaling and media behaviors in face of network failures. I'd rather 
treat that separately. For this reason, I am suggesting we stick with 
the current solution, and not say anything about this case.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 6 Sep 2006 13:29:28 +0200

Hi,

Chapter 10 says that the keepalive is performed no matter if a stream is
inactive, sendonly, recvonly or sendrecv.

Now, there is a chance that STUN requests sent on an incative stream
will never receive the remote host, and in that case a timeout is very
likely to occur. It's probably good to still send the keepalives, in
order to keep NAT bindings open, but maybe some text would be needed to
mention that a timeout in this case does not necessarily mean that
something has gone wrong.

Regards,

Christer

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 6. syyskuuta 2006 0:18
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-10 Issue #6: What if Keepalives fail?
> 
> STUN-based keepalives are sent periodically after ICE 
> completes, every 15s, to keep nat bindings alive. It serves 
> as a media and codec independent mechanism for binding keepalive.
> 
> The STUN checks also have the benefit that, should a 
> keepalive fail, you can detect it. But - what do you do if a 
> check should fail, or produce a new candidate, for example? 
> The spec doesn't say.
> 
> 2. an intermediate NAT has crashed and lost its bindings. 
> This can cause a check to fail, or more oddly, to produce a 
> new binding 3. network failure of some sort, like a partition 
> 4. network congestion has caused loss of lots of media 
> traffic, including stun keepalives
> 
> 
> Several of these cases (1 and 3), there is nothing you can do 
> but terminate the call. However, sending a BYE message is the 
> wrong thing in cases 3 and 4. In case 4 its exactly the wrong 
> thing, as it will only increase the load on the network.
> 
> ANother issue also is that 15s is a LONG time for a 
> multimedia session, and likely a failure is detected much 
> faster by a human user or even by RTCP than by the STUN keepalives.
> 
> The issue is really bigger than ICE, and it has to do with 
> appropriate signaling and media behaviors in face of network 
> failures. I'd rather treat that separately. For this reason, 
> I am suggesting we stick with the current solution, and not 
> say anything about this case.
> 
> -Jonathan R.
> 
> 
> --