Subject: [netlmm] Closing Issue #159

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 14:52:37 +0300

Jean-Mickael and all,

I believe issue #159 ("Application Abort upon PPP Re-establishment") can 
be closed.  Ashutosh has sent some feedback indicating that applications 
  are likely not to break upon PPP re-establishment.  I will therefore 
close this issue now.  If you, or somebody else, feels that closing this 
issue is pre-mature, please send a message why this is so.

   http://www3.tools.ietf.org/wg/netlmm/trac/ticket/159

Kind regards,
- Christian

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Oct 2007 14:02:35 +0200

Christian Vogt wrote:
> Jean-Mickael and all,
> 
> I believe issue #159 ("Application Abort upon PPP Re-establishment")
> can be closed.  Ashutosh has sent some feedback indicating that
> applications are likely not to break upon PPP re-establishment.  I
> will therefore close this issue now.  If you, or somebody else, feels
> that closing this issue is pre-mature, please send a message why this
> is so.
> 

Many applications _are_ likely to abort when ppp connection is
re-established.

The simplest file transfer applications will break when ppp is
re-established.

But it depends on how that application uses the socket connections and
how the ppp connection is re-established.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 15:14:45 +0300

> how the ppp connection is re-established.

Alex,

do you think those applications will fail when a mobile host makes 
handover between P-MIPv6 MAGs?

- Christian

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 04 Oct 2007 08:31:29 -0400

Christian,
           We are still working on this experiment using PMIPv6 over 
PPP. Things seem to work fine between WiFi networks using PMIPv6.

We have also tried CMIPv6 and Simple Mobility using SIP over PPPoE and 
things seem to work fine when we re-establish PPPoE after moving to new 
network.

Thus, in our case application was interrupted but not broken. But we 
need to try on other applications, we have tried on RTP/UDP based 
application for Simple IP case and both TCP/UDP application for CMIPv6 
case.

I also agree with Alex it depends upon how the application uses the 
socket connections and how PPP is started.

Thanks
Ashutosh

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Oct 2007 15:33:00 +0200

> handover between P-MIPv6 MAGs?

Most certainly yes.

If the MN uses PPP to attach to different MAGs then ppp will fail and 
have to restart, making socket structures disappear and reappear.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Oct 2007 15:39:21 +0200

Ashutosh Dutta wrote:
> Christian, We are still working on this experiment using PMIPv6 over

WiFi interface behaves differently than ppp0 interface.

WiFi interface will not disappear if you walk in a real tunnel, losing
coverage.   PPP interface yes.

> We have also tried CMIPv6 and Simple Mobility using SIP over PPPoE
> and things seem to work fine when we re-establish PPPoE after moving
> to new network.

SIP protocol only happens at the beginning of the conversation.  Ongoing
conversation happens with UDP.  UDP flows don't have re-transmission.
They resist well when traffic flow stops.  But still, depending on how
that UDP application is written, it may be that the app re-creates new
sockets when some sockets disappear.  Depends on the reliability of the app.

> application for Simple IP case and both TCP/UDP application for
> CMIPv6 case.

The problem of applications being broken is when the ppp interface
disappears.  To this there are several solutions, some of them involve
starting the ppp software with special flags such that the interface
doesn't disappear when its LCP fails.  Other solution is reliable
applications that re-create socket structures when interface disappears.

But by default, most applications don't resist this kind of brutal
interface shutdown.

It's strange to say that applications usually resist upon ppp handover -
they don't.

Alex

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 04 Oct 2007 10:11:14 -0400

Alex, please see the comments inline.

> sockets when some sockets disappear.  Depends on the reliability of the 

We actually tried SIP Re-INVITE to support mobility for  Simple IP over 
PPPoE when the mobile moved and IP address on the mobile changed. There 
was no PMIP or CMIP involved in that case. Our application (RTP/UDP) 
over PPP did not break even if we did restart PPP0. BTW ppp0 interface 
goes away and comes back, as we do the PPP teardown and PPP connect 
during the move.

> applications that re-create socket structures when interface disappears.

That is a good thing to know. We needed to do some work around to 
support CMIPv6 over PPPoE, as the PPP interface goes down and then comes 
up during mobile's connection to the new AP.

Thanks
Ashutosh

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Oct 2007 16:22:57 +0200

Ashutosh Dutta wrote:
>>> We have also tried CMIPv6 and Simple Mobility using SIP over 
>>> PPPoE and things seem to work fine when we re-establish PPPoE 
>>> after moving to new network.
>> 
>> SIP protocol only happens at the beginning of the conversation. 
>> Ongoing conversation happens with UDP.  UDP flows don't have 
>> re-transmission. They resist well when traffic flow stops.  But 
>> still, depending on how that UDP application is written, it may be 
>> that the app re-creates new sockets when some sockets disappear. 
>> Depends on the reliability of the app.
> 
> We actually tried SIP Re-INVITE to support mobility for  Simple IP 
> over PPPoE when the mobile moved and IP address on the mobile 
> changed. There was no PMIP or CMIP involved in that case.

That's wonderful if it worked.  It gives continuous VoIP calls without
MIP, without PMIP...

> Our application (RTP/UDP) over PPP did not break even if we did 
> restart PPP0. BTW ppp0 interface goes away and comes back, as we do 
> the PPP teardown and PPP connect during the move.

Who and how issued the RE-INVITE?  I think some VoIP apps don't issue
that RE-INVITE, especially not upon interface disappearing.  I think
Skype for PC (which is not SIP) relogs-in upon address change but the
ongoing conversation breaks.

If need is I can give names of a bunch of other SIP apps on PC or on
Windows PDA which don't resist address change, don't resist interface
up/down.

Alex

>>> Thus, in our case application was interrupted but not broken. But
>>>  we need to try on other applications, we have tried on RTP/UDP 
>>> based application for Simple IP case and both TCP/UDP application
>>>  for CMIPv6 case.
>> 
>>  disappears.  To this there are several solutions, some of them 
>> involve starting the ppp software with special flags such that the 
>> interface doesn't disappear when its LCP fails.  Other solution is 
>> reliable applications that re-create socket structures when 
>> interface disappears.
>> 
> 
> support CMIPv6 over PPPoE, as the PPP interface goes down and then 
> comes up during mobile's connection to the new AP.
> 
> Thanks Ashutosh
> 
> 
>> It's strange to say that applications usually resist upon ppp 
>> handover - they don't.
>> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: "SEITE Pierrick RD-RESA-REN" <[email-masked]>
Date: Thu, 4 Oct 2007 16:49:00 +0200

Hi Ashutosh,

Sorry for jumping into the discussion,

but I was wondering what is the delay to re-establish the session when managing mobility with SIP Re-INVITE. Did you assess such performance?

BR,
Pierrick

> -----Message d'origine-----
> De : Ashutosh Dutta [mailto:[email-masked]]
> Envoyé : jeudi 4 octobre 2007 16:11
> À : Alexandru Petrescu
> Cc : Christian Vogt; NetLMM Mailing List; [email-masked]
> Objet : Re: [netlmm] Closing Issue #159
>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 18:44:00 +0300

Ashutosh and Alex,

thanks a lot for your feedback.  This is valuable.

I have a meta-question, though.  Are the application failures something that
P-MIPv6 can do something about, or is this a problem with PPP in general?

It seems to me that the problem is PPP-specific, and that it will occur in
C-MIPv6 and other IP mobility protocols just as well as in P-MIPv6.  OTOH, due
to the per-mobile-host prefix model used in P-MIPv6, the dependency on PPP may
be stronger in P-MIPv6 than in other IP mobility protocols.

Your feedback is again appreciated...

Best,
- Christian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Oct 2007 22:56:51 +0200

> P-MIPv6 can do something about, or is this a problem with PPP in general?

Sure it can do, PMIPv6 should say first whether it works with MN-AR ppp 
interfaces or not.

If two MAGs make it look to MN as if its ppp LCP connection hasn't been 
dropped upon a handover then the MN won't have to re-LCP, thus its 
interface will stay up, with the address attached on it.

> Your feedback is again appreciated...

Thanks for following on this issue.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 4 Oct 2007 18:57:18 -0700

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 1:57 PM
> To: Christian Vogt
> Cc: [email-masked]; NetLMM Mailing List
> Subject: Re: [netlmm] Closing Issue #159
> 
> Christian Vogt wrote:
> > Ashutosh and Alex,
> > 

Hi Alex/Chrisitan,

PPP link re-establishment can also be done using context 
transfer, it can be part of the inter-MAG handoff procedures.
This will not require for the MN to teardown the PPP session
and applications should survive this handoff. I do not think,
PMIP6 is required to any thing here.

Sri

---

From: Ashutosh Dutta <[email-masked]>
Date: Fri, 05 Oct 2007 00:03:03 -0400

Pierrick,
           There is a tradeoff associated with SIP-based mobility. While 
SIP-based mobility does not need any additional mobility protocol, 
depending upon the implementation of SIP stack and RTP stack (e.g., 
Java, C++), completion of Re-Invite and media redirection would 
contribute to different amount of delay as it involves application layer 
interaction. In a pure SIP-based environment, SIP-based mobility (e.g., 
SIP Re-INVITE approach) could be considered as an alternative.

Thanks
Ashutosh

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 5 Oct 2007 14:29:16 +0900

Hi Alex,

This is totally depending on ppp implementation, isn't this!?
PPP has been implemented in several way and several layers, both  
userland and kernel.

> making socket structures disappear and reappear.

There are several ways to avoid this case.
For example, it is not always necessary for applications to bind to  
the ppp socket,
but to the other socket bound to the home address.

I don't think this is a problem of PMIP spec., but implementation  
issues.

regards,
ryuji

On 2007/10/04, at 22:33, Alexandru Petrescu wrote:

> If the MN uses PPP to attach to different MAGs then ppp will fail  
> and have to restart, making socket structures disappear and reappear.
>
> Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Oct 2007 10:50:48 +0200

Sri Gundavelli wrote:
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, October 04,
>> 2007 1:57 PM To: Christian Vogt Cc: [email-masked];
>> NetLMM Mailing List Subject: Re: [netlmm] Closing Issue #159
>> 
>> Christian Vogt wrote:
>>> Ashutosh and Alex,
>>> 
>> Sure it can do, PMIPv6 should say first whether it works with MN-AR
>> ppp interfaces or not.
>> 
> 
> Hi Alex/Chrisitan,
> 
> PPP link re-establishment can also be done using context transfer, it
> can be part of the inter-MAG handoff procedures. This will not
> require for the MN to teardown the PPP session and applications
> should survive this handoff. I do not think, PMIP6 is required to any
> thing here.

BRainstorming... I didn't mean context transfer... look at this:

     ----      ---      ----
  --|MAG1|----|LMA|----|MAG2|--
     ----      ---      ----

      \                     /
       \                   /
       MN  ---->         MN

Alex

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 5 Oct 2007 17:54:51 +0800

sorry for mine jumping in
I experienced as Alex said here when we did heterogenerous network MIP
handover before.
we know it is a LCP specific problem, but it really breaked our IP
mobility connection.

-Hui

---

From: Julien Laganier <[email-masked]>
Date: Mon, 8 Oct 2007 08:14:20 +0200

Christian,

On Thursday 04 October 2007, Christian Vogt wrote:
> I have a meta-question, though.  Are the application failures
> something that P-MIPv6 can do something about, or is this a problem
> with PPP in general?
>
> It seems to me that the problem is PPP-specific, and that it will
> occur in C-MIPv6 and other IP mobility protocols just as well as in
> P-MIPv6.  OTOH, due to the per-mobile-host prefix model used in
> P-MIPv6, the dependency on PPP may be stronger in P-MIPv6 than in
> other IP mobility protocols.
>

I agree that it is not a mobility-related issue. More generally,
it has to do with behavior of a network stack in face of L2 down/up 
events, hysteresis, etc.

If the stack reacts sensibly upon L2 events things are going
to be fine. 

If the stack reacts insanely applications will have a hard time
working in the presence of such L2 events, that's unrelated to
mobility although mobility will make things worse since such
events will happen more frequently. 

More specifically, either of these situations can occur:

- the stack does the right thing upon L2 down/up events 
(which might be DNA, or something else which is 
implementation specific like hiding the handover at L2 
or L3), or

- it does not to do the right thing upon L2 down/up, 
e.g. send error to all apps so that they fail, and 
after that tries to reconfigure the interface, and 
then seamlessness is screwed up and there's nothing we 
can do about it in that document.

In other words if a stack blindingly fails ULP 
communications based on L2 down/up event before it 
knows what happened at L3 (which is stupid!) then the 
stack has a problem, not NETLMM. That is BTW exactly why 
DNA work was chartered.

Something sensible has to be done, that might be DNA -- 
or something else, out of scope of the spec, since 1) we are
not chartered to reinvent a DNA mechanism, and 2) we suppose
no host change at the IP mobility level :)

Cheers,

--julien