Subject: [MMUSIC] ICE Mobility

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Jul 2012 17:19:51 -0700

MMUSIC,

Losing or acquiring an interface often happens with mobile devices, such as
when a device gets within WiFi range or leaves 3G range.  Today the industry
generally relies on techniques below layer 3 to hide the IP address change
from the remote endpoint (e.g., LISP, Mobile IP).  These existing techniques
have some drawbacks, such as requiring support in the network
infrastructure.

ICE Mobility explores how to accomplish a similar function for ICE-initiated
flows without needing support in the endpoint or in the network.  Instead,
the mobility support is provided at the ICE layer (such as RTP, SRTP, or
RTCWEB's data channel (SRTP over UDP)).  The document discusses how two
approaches:  (a) when both endpoints support ICE Mobility, and (b) when only
one endpoint supports ICE Mobility, which uses a TURN server -- a different
sort of network infrastructure.

http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility

We are unlikely to get time in MMUSIC to present this draft, but are
interested in feedback.

-d

---

From: Lishitao <[email-masked]>
Date: Wed, 25 Jul 2012 03:43:24 +0000

Hi Dan 

I read this draft, and I think the idea of this draft is useful. Regarding the two methods mentioned in the draft, I think the TURN one is better than the ICE one, 

especially if the TURN server has the cache capability, the data lose will be quite small. 

For the mobility using ICE I got some comments,
1), in section 3.1, I believe the procedure described here is all about the endpoint who meet the mobility situation, so in step 6, the ICE connectivity check is only done by this side, do you need to wait the ICE connectivity check finished by another side (probably the procedure in section 3.2 ) before you nominate the check result?

2), in section 3.2, it said that "A STUN Binding Request containing the MOBILITY-EVENT attribute MAY be received by an ICE endpoint. "  why is MAY be here? And when     does this MOBILITY-EVENT attribute need?

3) ,  what do you mean by this words " If this is received before the endpoint is in the ICE Concluded state, it should be silently discarded. " ?

4), section 3.3, losing an interface, it recommends that not to send the SDP to remove the lost interface, instead it is better to maintain it active. For my understanding, when the mobile device switch from one interface to another(for example, wifi to 3G), the gateway and NAT before the device will change too, how can it maintain the previous interface active? The only way, I can consider is that the previous interface is not totally lost, it still active on the device, that means the two interfaces all exist at the same time, but the device can choose to use the new one because its signal is better than the previous one. 

Regards
Shitao

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Dan Wing
发送时间: 2012年7月25日 8:20
收件人: [email-masked]
抄送: 'Prashanth Patil (praspati)'; 'Tirumaleswar Reddy (tireddy)'
主题: [MMUSIC] ICE Mobility

MMUSIC,

-d

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

---

From: [email-masked]
Date: Thu, 26 Jul 2012 19:58:59 +0800

Hi,Dan

 Have simultaneous mobility been considered in this draft? 

Regards~~~

-Sujing Zhou

"Dan Wing" <[email-masked]> 
发件人:  [email-masked]
2012-07-25 08:19

收件人
<[email-masked]>
抄送
"'Prashanth Patil \(praspati\)'" <[email-masked]>, "'Tirumaleswar 
Reddy \(tireddy\)'" <[email-masked]>
主题
[MMUSIC] ICE Mobility

MMUSIC,

Losing or acquiring an interface often happens with mobile devices, such 
as
when a device gets within WiFi range or leaves 3G range.  Today the 
industry
generally relies on techniques below layer 3 to hide the IP address change
from the remote endpoint (e.g., LISP, Mobile IP).  These existing 
techniques
have some drawbacks, such as requiring support in the network
infrastructure.

ICE Mobility explores how to accomplish a similar function for 
ICE-initiated
flows without needing support in the endpoint or in the network.  Instead,
the mobility support is provided at the ICE layer (such as RTP, SRTP, or
RTCWEB's data channel (SRTP over UDP)).  The document discusses how two
approaches:  (a) when both endpoints support ICE Mobility, and (b) when 
only
one endpoint supports ICE Mobility, which uses a TURN server -- a 
different
sort of network infrastructure.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jul 2012 10:16:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 26, 2012 4:59 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'Prashanth Patil
> (praspati)'; 'Tirumaleswar Reddy (tireddy)'
> Subject: 答复: [MMUSIC] ICE Mobility
> 
> 
> Hi,Dan
> 

No.

A TURN server would be safe if both endpoints are losing IP address at the
same time, so that the TURN server can be the stable address.  But that is
not yet discussed in the draft.  Transitioning from TURN to p2p, during a
mobility event, is something we plan to add to the document.  First we
wanted to discuss TURN (and the new attributes) and discuss ICE (and the new
attributes).  Combining the two, into the most complex scenario where both
endpoints experience loss of IP interface at the same time, is what we
wanted to describe last after the easier scenarios are clearer.

-d

> 2012-07-25 08:19 收件人