RE: New issue 16: No packets from other end?

Hi Pasi,

Situations where traffic being sent expects a response
from the other end in a reasonable time, can give some
indication of network/path failures, though not an 
absolute indication. But just saying that "No packets 
from the other end in some amount of time" is an indicative
of network/path failure may not be a correct statement.

We will have to explicitly say, that if certain part of the
protocol, say an IKE message does not get response in a
certain amount of time, we initiate change of address. 
Another possibility could be the keepalives, which shall be
needed for the NAT case anyway, could be used as an indication
of network/path failures. Lack of keepalive could be a
trigger for MOBIKE change of address notification.

I agree we should try to recover from as many failures/changes
as possible without making the protocol unreasonably complex. I
think use of keepalives, which are needed anyway, for this purpose
should not make the protocol any more complex than it already is.

>From the title of the issue, it seemed we are trying to proactively
solve network failure recovery.

I think we are in agreement. This sounds reasonable to me. I 
guess, then we will have to understand Francis' objection to 
such failure recovery.

Best,
Atul

> -----Original Message-----
> From: Eronen Pasi (Nokia-NRC/Helsinki) 
> Sent: Monday, August 16, 2004 9:42 AM
> To: Sharma Atul (Nokia-ES/Boston); [email protected]
> Subject: RE: [Mobike] New issue 16: No packets from other end?
> 
> 
> Hi Atul,
> 
> My impression was that the main reason we are adding 
> multihoming support to IKEv2 is to recover from failures 
> (since load balancing is explicitly beyond the scope). 
> 
> I think that restricting ourselves to those network failures 
> where we get an explicit "link down" signal will seriously 
> limit the usefulness of the protocol's multihoming features.
> (For instance, the multihoming features of SCTP don't
> have that kind of restriction.)
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: [email protected]
> > Sent: Monday, August 16, 2004 3:33 PM
> > To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]
> > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > 
> > 
> > Thanks Passi,
> > 
> > ....for the explanation. I think in that case you are trying
> > to solve network failure recovery inside the MOBIKE protocol.
> > 
> > I think Francis and someone else on the list commented such
> > functionality should probably be outside the MOBIKE protocol
> > specification.
> > 
> > MOBIKE's mandate, in my opinion, is to notify the "other end"
> > of the change in address or plurality of addresses due to 
> > mobility or multihoming using IKE mechanism (information 
> > exchange). Trying to solve a general problem within MOBIKE,
> > may complicate MOBIKE protocol unnecessarily. Network failure
> > recovery (without notifications) should be solved elsewhere
> > IMHO.
> > 
> > Best,
> > Atul
> > 
> > > -----Original Message-----
> > > From: Eronen Pasi (Nokia-NRC/Helsinki) 
> > > Sent: Monday, August 16, 2004 7:38 AM
> > > To: Sharma Atul (Nokia-ES/Boston); [email protected]
> > > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > > 
> > > 
> > > 
> > > Hi Atul,
> > > 
> > > The other end could be a mobile host or SGW, depending 
> > > on your point of view.
> > > 
> > > The issue is what to do if we have not received a "link 
> > > down" signal from layer 2 (or somewhere), but we don't 
> > > get any responses (to IKEv2 requests) from the other end 
> > > either. In this situation,  should we just close the 
> > > connection, or "somehow" trigger MOBIKE to change to 
> > > some other address(es)? 
> > > 
> > > (Some details of the "somehow" part will be beyond 
> > > the scope of the MOBIKE specification, but probably  
> > > something needs to be said to ensure interoperability.)
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > Sent: Friday, August 13, 2004 5:40 PM
> > > > To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]
> > > > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > > > 
> > > > I needed some clarifications from MOBIKE veterans, before 
> > > > expressing an opinion:
> > > > 
> > > > What is the "other end" here? The mobile host? or the 
> > > > multihoming SGW?
> > > > 
> > > > Who initiates the MOBIKE protocol? I would guess:
> > > >    (1) a mobile host after the move, needs to notify the 
> > > >        remote SGW of its new address.
> > > >    (2) a multihoming SGW, upon detecting that one of its 
> > > >        interfaces (which was used to contact the mobile host)
> > > >        is down and it needs to notify the mobile host of its
> > > >        new interface address to be used.
> > > > 
> > > > Are there any other scenarios of how MOBIKE can be initiated? 
> > > > When would we use the information that there is "lack 
> of packets 
> > > > from the other end", to initiate the MOBIKE protocol?
> > > > 
> > > > Thanks,
> > > > Atul
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email protected] 
> > > > > [mailto:[email protected]]On
> > > > > Behalf Of ext 
> > > > > Sent: Thursday, August 12, 2004 9:01 AM
> > > > > To: [email protected]
> > > > > Subject: [Mobike] New issue 16: No packets from other end?
> > > > > 
> > > > > 
> > > > > I've created a new issue in the issue list:
> > > > > 
> > > > >    "Can the protocol recover from situations where the only 
> > > > >    sign of problems is lack of packets from the other end?"
> > > > > 
> > > > >    (http://www.vpnc.org/ietf-mobike/issues.html)
> > > > > 
> > > > > Many people at the WG meeting expressed opinions that this 
> > > > > should be handled somehow (in addition to handling e.g. 
> > > > > link-down triggers from layer 2, or something similar).
> > > > > 
> > > > > So far, I do not remember anyone saying that the protocol
> > > > > does not need to handle this situation. But comments
> > > > > are welcome.
> > > > > 
> > > > > Best regards,
> > > > > Pasi
> > > 
> > _______________________________________________
> > Mobike mailing list
> > [email protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
>