Subject: [dispatch] Migrating SIP to IPv6 Media Without Connectivity Checks

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Aug 2010 14:09:51 -0700

At IETF78 we had a Bar BoF discussing why folks don't like ICE for doing
connectivity checks for dual-stack hosts.  The outcome of this Bar BoF was
an idea that Andrew and I wrote up,

Abstract:
   During the migration from IPv4 to IPv6, it is anticipated that an
   IPv6 path might be broken for a variety of reasons, causing endpoints
   to not receive RTP data.  Connectivity checks would detect and avoid
   the user noticing such a problem, but there is industry reluctance to
   implement connectivity checks.

   This document describes a mechanism allowing dual-stack SIP endpoints
   to attempt communications over IPv6 and fall back to IPv4 if the IPv6
   path is not working.  The mechanism does not require connectivity
   checks.

http://tools.ietf.org/html/draft-wing-dispatch-v6-migration

I didn't know where to best send this (MMUSIC did ICE, BEHAVE did ICE's
connectivity checking protocols), so I'm trying DISPATCH because this is
mostly about how dual-stack SIP endpoints can avoid IPv6 network breakage.

Comments welcome.
-d

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 27 Aug 2010 17:46:05 -0400

>   path is not working.  The mechanism does not require connectivity

Possibly dumb question: Isn't trying IPv6 and falling back to IPv4  
effectively a connectivity check?

--Richard

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Aug 2010 17:15:46 -0700

> effectively a connectivity check?

"Connectivity check" is what ICE does, with a STUN request/response
exchange.  This does something less.  I call it "not a connectivity
check"; if there is a better term, I'm game to change the terminology.

-d

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sat, 28 Aug 2010 10:19:58 -0400

Ok, I get that "connectivity check" is a reserved word for ICE.  But  
I'm still not understanding how you're going to do thing more  
efficiently.  Looking at Figure 3 in RFC 5245, it looks like a  
connectivity check on a candidate pair (i.e., the peers IPv6  
addresses) is four packets, two request/response pairs.  Are people  
really complaining about one RTT of latency, or is there something  
extra I'm missing here?

Now that I've read the draft, a couple of specific comments:

-- It seems like you're just trading bandwidth for latency.  Are the  
people complaining about a 1 RTT delay going to tolerate a doubling of  
bandwidth or a risk of loss (in the sharing scheme)?

-- Your technique covers the case where IPv6 works but not IPv4, but  
the narrative text doesn't mention it (there are really 16 cases: 2  
peers x 2 directions x 2 protocols x 2 states -- 15 if you ignore the  
case where nothing works :) )

--Richard

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 29 Aug 2010 21:39:20 -0700

> -----Original Message-----
> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Saturday, August 28, 2010 7:20 AM
> To: Dan Wing
> Cc: 'DISPATCH list'; 'Andrew Yourtchenko'
> Subject: Re: [dispatch] Migrating SIP to IPv6 Media Without
> Connectivity Checks
> 

At the Bar BoF in Masstrict, nobody mentioned the round trip.  The
round trip isn't a problem, anyway -- due to how calls are set up
and when ICE messages are sent, the connectivity round trip can be 
performed without delaying call setup or delaying ringing.

The complaints, as I heard them, were as described in the I-D:

  "However, ICE is
   considered overkill for the problem of migrating to IPv6 because of
   the overhead of timers, interaction with existing media state
   machines, and CPU impact of SHA1 on large devices processing many
   sessions and on small devices."

The purpose of the I-D is not to bash ICE, nor to agree with the
reasons ICE has not (yet) enjoyed significant deployment.

Rather, the world is running out of IPv4 addresses, and a lot of
networks are transitioning to IPv6.  It is important that, during that
transition, we don't cause a worse user experience with dual-stack
endpoints compared to IPv4-only endpoints.  Otherwise users will
blame their failed calls on IPv6 when they notice an IPv4-only
endpoint (on the same network) working fine.  

> bandwidth or a risk of loss (in the sharing scheme)?

I don't know.  

That's why I wrote this I-D -- to initiate discussion.

There is a "Note:" in the draft that mentions another technique that
does not double bandwidth, in which nn% of packets are sent over 
IPvX and the others are sent over IPvY.

> case where nothing works :) )

We can make things more complex and deal with RTP, RTCP, IPv4 failing
(but IPv6 working), and so on.  But keeping the initial draft simple
so everyone can get their heads around it seemed most critical when
I wrote it.   And the combinations grow even faster when considering
audio+video, or audio+video+screensharing.

-d

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 30 Aug 2010 08:22:39 -0500

> mostly about how dual-stack SIP endpoints can avoid IPv6 network breakage.

For SIP servers that are controlling media gateway devices, this could
be rather hard to implement. When media gateway devices are upgraded to
support IPv6, they'll be dual-stack like the controlling entity, which
is adequate to be able to send and receive media streams over IPv6.

However, in my experience dealing with media gateways, they generally do
*not* have the ability to direct a media stream to two destinations
simultaneously unless a conference bridge of some sort is involved...
and that will result in the two streams being independent (thus having
different sequence numbers and timestamps).

It's already going to be hard enough to get STUN support implemented in
gateways so that SIP servers can use them to do ICE connectivity checks;
this seems like it would be even more work for gateway implementors to
build, not less.

I can sympathize with the desire to have a simpler mechanism for doing
*only* v4/v6 path selection, but since either method will require
implementors of media endpoints to develop the required support, I'd
rather push them towards implementing STUN. The SHA-1 overhead for a few
packets at the beginning of a session seems (to me, anyway) to be far
less CPU burden than the low bitrate codec (or modem) that the gateway
will eventually be operating on that channel anyway.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org