Subject: [MMUSIC] ICE Issue: mid-session connectivity checks

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Oct 2004 08:46:16 -0400

Folks,

One of the big changes in the -02 ICE spec was the addition of 
mid-session connectivity checks. These checks served several purposes:

1. detection of a network failure that causes an interface to become 
unreachable

2. in the case of a failure of a nat in the middle of the network, if 
the nat recovers, or a backup takes its place, a new binding will get 
assigned, and it can be discovered

The particular motivating use case for 2 is an enterprise that is 
multihomed. It has a NAT on each of its two interfaces to its providers. 
The enterprise uses the address prefix provided from provider A, and 
advertises reachability to this prefix into provider B. A client within 
the enterprise makes a call. The NAT and/or connection to provider A 
fails. Routing now causes outbound UDP packets to go over the interface 
to provider B. So, outbound UDP packets from the client now go through 
this other NAT. It assigns a new binding. With mid-session checks, the 
new binding can be learned by the peer, and communications established 
using it.

Now, the trick is that, if we are interested in VoIP as a driving use 
case for this, the amount of time to discover this has to be relatively 
short. If it takes 30 seconds, the users in the call would have already 
hung up. That requires the connectivity checks to be sent at a rapid 
clip. Furthermore, in the case of such a failure, signaling would fail 
too in all likelihood (depending where the servers are), which would 
require some SIP operations.

So, the issue is, is it worth it? I have gotten a few complaints about 
the complexity introduced by the mid-session checks. Thus, we have three 
choices as I see it:

1. remove the checks completely

ICE runs only on setup, to do an initial check. RTCP would, for example, 
allow you to detect some of these failure situations mid-call. Recovery 
would require re-establishing the call.

2. keep the checks

THe draft stays as is

3. Allow for the usage of the checks to be negotiated

In case a client doesn't want to implement support for the mid-session 
checks, we make them optional and allow it to be signaled.

I'd prefer NOT to do 3, in the interest of avoiding protocol options. 
The argument in favor of 1 is primarily one of simplification, and that 
you will have to make these connectivity checks really fast in order to 
be responsive enough to really recover from a failure, which could be a 
problem.

As I constantly hear these days that "ICE is too complicated", in the 
interests of simplification, I'd be game to remove the feature. It could 
be added back in as an extension later if needed.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 21 Oct 2004 04:52:25 -0700

I would prefer to keep the checks - choice 2.

---

From: Jon Ringle <[email-masked]>
Date: Thu, 21 Oct 2004 09:15:17 -0400

Alternate suggestion inline.

> checks, we make them optional and allow it to be signaled.

I offer another suggestion:

Remove the STUN mid-call connectivity checks (or keep them to a minimum only 
to refresh bindings). A timer could be placed based on the reception of RTP 
packets (since ICE is demuxing STUN/RTP it is in a position to do this). If 
the timer fires due to no RTP packets received within a specified time (codec 
dependant), and the session has not been terminated yet, then this endpoint 
knows that there is a possible problem with the peer endpoint being able to 
reach this endpoint. This endpoint could then perform STUN connectivity 
checks. When the peer receives a STUN bind request mid-call, it can then 
assume that the reason it is receiving a STUN bind request is because it's 
RTP media is not reaching it's peer. The peer endpoint can then perform it's 
own connectivity checks again.

Jon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 22 Oct 2004 06:48:49 -0700

The reason why I think we should keep the checks, is that it can be useful 
to choose between different candidates with the same priority. An endpoint 
can allocate a port on more than one TURN server - on different countries 
or state. The checks can be used to measure the latency and the packet loss 
and so dynamically switch to a better route in the middle of a call.

Marc Petit-Huguenin wrote:
>> multihomed. It has a NAT on each of its two interfaces to its 
>> providers. The enterprise uses the address prefix provided from 
>> provider A, and advertises reachability to this prefix into provider 
>> B. A client within the enterprise makes a call. The NAT and/or 
>> connection to provider A fails. Routing now causes outbound UDP 
>> packets to go over the interface to provider B. So, outbound UDP 
>> packets from the client now go through this other NAT. It assigns a 
>> new binding. With mid-session checks, the new binding can be learned 
>> by the peer, and communications established using it.
>>
>> case for this, the amount of time to discover this has to be 
>> relatively short. If it takes 30 seconds, the users in the call would 
>> have already hung up. That requires the connectivity checks to be sent 
>> at a rapid clip. Furthermore, in the case of such a failure, signaling 
>> would fail too in all likelihood (depending where the servers are), 
>> which would require some SIP operations.
>>
>> the complexity introduced by the mid-session checks. Thus, we have 
>> three choices as I see it:
>>
>> ICE runs only on setup, to do an initial check. RTCP would, for 
>> example, allow you to detect some of these failure situations 
>> mid-call. Recovery would require re-establishing the call.
>>
>> 2. keep the checks
>>
>> THe draft stays as is
>>
>> The argument in favor of 1 is primarily one of simplification, and 
>> that you will have to make these connectivity checks really fast in 
>> order to be responsive enough to really recover from a failure, which 
>> could be a problem.
>>
>> interests of simplification, I'd be game to remove the feature. It 
>> could be added back in as an extension later if needed.
>>
>> Comments?
>>
>> -Jonathan R.
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Oct 2004 10:34:22 -0400

I agree with the direction Jon is suggesting here, but think it is part 
of a bigger activity.

Without some kind of recovery mechanism, what usually happens is that 
one or both parties on a call notice that something is wrong with the 
call - either the media malfunction in some way, or there is some 
indication that signaling isn't working properly. At that time, the 
users take remedial action - usually attempting to reestablish the call.

I think there should be an analogous process that the endpoints perform 
on their own, so that the users aren't required to do anything other 
than tolerate a potential glitch. If this were well specified it 
wouldn't suffer from the problem that often happen when users do it - 
such as glare resulting in both getting a busy signal.

To achieve this, something needs to monitor the session and identify 
when there may be a potential problem. A lot of this is monitoring media 
sessions. How this is done is inherently media specific.

For two way RTP based audio media this may, as Jon suggests, only 
require checking that packets are received periodically, and helping the 
other end by always sending packets periodically. For one way or idle 
media this may be a bit more tricky. Sending STUN packets is perhaps one 
answer, but maybe it is ok to send rtp idle packets (did those get 
approved?) if it is agreed they can be sent even on a RECVONLY or 
INACTIVE connection.

A similar approach would presumably work for video. Session mode IM will 
require something different, but the concept is the same.

Once there is a hint of a problem, testing and recovery can commence. 
Part of this is to test the signaling path. This can be any mid-dialog 
request, but could easily be a reinvite or update that does a new 
offer/answer. Exactly what kind of offer/answer to do isn't entirely 
clear. If I think there is a problem, but don't think I am at fault, the 
"obvious" thing for me to do is to again offer the same SDP I used last. 
However, that may well solicit an answer the same as last time, and 
result in absolutely no change in the media.

There really needs to be some kind of hint in the reinvite or the 
accompanying offer that there is a problem to be diagnosed or recovered 
from. Maybe this would be a Reason header in the reinvite, or something 
(new preconditions?) in the offer. This should either result in 
initiating diagnostic actions on one or more media streams, or 
replacement of resources (ports, relays, etc.) in the path of one or 
more media streams, or both.

There are of course lots of failure modes to consider. In some cases it 
may be the entire peer UA that has failed, but that has a backup, or it 
could be a turn server, msrp relay, or NAT that has failed. In any case, 
the problem extends beyond the scope of what ICE deals with.

If this kind of recovery process were supported by every endpoint, then 
it would be much easier to design and build redundant servers.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Oct 2004 01:36:01 -0400

Paul,

I've come around to this line of thinking too, and this is what is 
reflected in -03, now available at:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt

more inline.

> such as glare resulting in both getting a busy signal.

Right.

> sessions. How this is done is inherently media specific.

I agree.

> approved?) if it is agreed they can be sent even on a RECVONLY or 

If you want to monitor quality, I think RTCP does the job. I don't think 
you need to send additional packets to generate data to measure. In any 
case, determining that there has been a quality failure is definitely 
outside the scope of ICE.

In -03, STUN is now only used for the initial checks. mid-call 
keepalives are handled at the application layer, and there is text on 
doing that for RTP, which talks about this music-on-hold problem. That 
is differnt still from detecting failed media to do something about it, 
which is not addressed at all, beyond a hook I left.

The hook that's in there is the treatment of re-invites. If you get one, 
and nothing has changed, don't do anything. That is, a re-invite in and 
of itself does not trigger you to restart connectivity checks. But, if 
the re-invite adds a new candidate address that hasn't been seen before, 
connecitivyt checks are sent to it. "never seen before" is determined 
based on boht the transport address AND the username fragment. This 
means that a client can use a transport address, and then if it thinks 
there are problems, start up the stun server again, change the username, 
and do a reinvite to trigger a recheck.

> more media streams, or both.

Exactly what to do needs futher consideration. I've left just a hook for 
now.

> the problem extends beyond the scope of what ICE deals with.

Yup.

-Jonathan R.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Oct 2004 18:06:00 -0700

> http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt

[snip]

>> require checking that packets are received periodically, and helping 
>> the other end by always sending packets periodically. For one way or 
>> idle media this may be a bit more tricky. Sending STUN packets is 
>> perhaps one answer, but maybe it is ok to send rtp idle packets (did 
>> those get approved?) if it is agreed they can be sent even on a 
>> RECVONLY or INACTIVE connection.
> 
> 

Using RTCP to monitor the quality of the current best connection is OK, but 
what about the other routes? The advantage of the connectivity checks with 
STUN, is that it is possible to use them to measure dynamically the 
latency/packet lost in the middle of a media session, and so to eventually 
choose a different route. I understand that this is outside ICE scope, but 
having this connectivite checks had some interesting usages, and I do not 
see by what it is replaced.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2004 18:35:07 -0700

> Using RTCP to monitor the quality of the current best connection is
> OK, but what about the other routes?  The advantage of the
> connectivity checks with STUN, is that it is possible to use them to
> measure dynamically the latency/packet lost in the middle of a media
> session, and so to eventually choose a different route.  I understand
> that this is outside ICE scope, but having this connectivite checks
> had some interesting usages, and I do not see by what it is replaced.

An endpoint is still free to probe other paths if it wants to do so.

Changing the path during an active call results in out-of-order packet
delivery, the possibility of lost packets, and a high likelyhood that
the delay of the new path will be different than the delay of the
old path.  In may situations, these changes cause an adverse effect
on realtime, interactive media (audio or video).  As networks are
designed to reduce these very same adverse effects, it's not desirable
for a NAT optimization technique to continually probe and potentially
switch media paths during an active media session.

-d