Subject: RE: [Pana] Issue 114: Clarify liveness test

From: [email-masked]
Date: Mon, 20 Dec 2004 17:17:25 +0200

Ok, paging can be handled like this.. but I took that as an
example. How about the situation where PaC puts for example WLAN (or
any other radio interface) interface to sleep (no paging) for battery
saving purposes and schedules a wake up of the interface latest at
when the PANA session is about to expire to re-authenticate to the
WLAN access network? 

An application wanting to use the WLAN interface can wake-up the
interface earlier of course. The advantage would be that PANA session
is still open. The only problem is that PAA may have sent
PANA-Ping-Request and PaC has lost it --> PAA has closed the session,
but PaC thinks that it is still open. States in PaC and PAA are
different.

What then happens is that PAA may trigger PANA authentication when PaC
next time tries to use the network. Thus, PaC should be able to handle
this situation. Right?

Br,
- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 20 December, 2004 07:15
> To: Forsberg Dan (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Pana] Issue 114: Clarify liveness test
> 
> 
> On Mon, Dec 20, 2004 at 11:13:16AM +0200, 
> [email-masked] wrote:
> > I don't want to be troublesome, but let me try to give an example in
> > the scope of mobile devices and paging.
> > 
> > With the current liveness test approach PaC needs to be 
> awake all the
> > time. This means that PaC can't trust the lifetime given by the PAA
> > and put the interface to sleep mode if it is not needed. It may be
> > that the interface wakes up, when the PANA-Ping-Reuqest arrives from
> > the PAA, but on some cases it may not. So, in this case the PANA
> > protocol is not deterministic enough IMHO and should be fixed. Any
> > solutions to this problem?
> 
> The solutions would be similar to several proposals in the
> discontinued IP paging work in the Seamoby WG.  If the paging protocol
> is coupled with PANA liveness test, a paging registration operation
> performed before the PaC enters a dormant mode can be a trigger for
> the PAA to reduce the frequency of PANA-Ping exchange.  Also, the
> dormant mode PaC will need to be paged before a PANA-Ping-Request
> arrives.  In this case, the PANA-Ping-Request sent by the PAA will
> become a trigger to page the dormant PaC.  The paging protocol and
> PANA protocol can interwork this way with minimum dependency.
> 
> Yoshihiro Ohba
> 
> > 
> > I also think that PAA/PaC retransmission timers should not depend on
> > the link layer, because PANA is link layer agnostic.
> 
> 
> > 
> > Br,
> > - Dan
> > 
> > > -----Original Message-----
> > > From: ext Yoshihiro Ohba [mailto:[email-masked]]
> > > Sent: 17 December, 2004 15:26
> > > To: Alper Yegin
> > > Cc: 'Yoshihiro Ohba'; Forsberg Dan (Nokia-NRC/Helsinki); 
> [email-masked]
> > > Subject: Re: [Pana] Issue 114: Clarify liveness test
> > > 
> > > 
> > > On Fri, Dec 17, 2004 at 03:44:45PM -0800, Alper Yegin wrote:
> > > > > > > If we can specify the maximum values for the 
> retransmission
> > > > parameters
> > > > > > > (e.g., defining the maximum value for "Max Request timeout
> > > > value"), I
> > > > > > > think we can deal with the out-of-synch problem to 
> > > some extent.
> > > > > >
> > > > > > We already have that. Please see MRC, MRT, and MRD values.
> > > > > 
> > > > > But those maximum values are configurable *variables" and 
> > > there is no
> > > > > *constant* upper-limit for those maximum values.
> > > > 
> > > > How can there be? Do you want to prevent people using PANA in
> > > > super-high-latency inter-galactic networks? ;-) 
> > > 
> > > I don't know how large the latency in such networks is.. :)
> > > 
> > > > 
> > > > Even if we had a limit on that, I cannot understand how 
> this helps.
> > > > Still it is a configurable parameter and an impatient PAA 
> > > may blow away
> > > > PaC's session sooner than such a MAX timeout.
> > > 
> > > I'd say that state synchronization loss period can be bound to the
> > > extent determined by the upper-limits for those maximum 
> values.  If
> > > the upper-limits are too large it won't help.  I don't 
> have a strong
> > > opinion on having upper-limits for those maximum values.
> > > 	
> > > Yoshihiro Ohba
> > > 
> > > 
> > > 
> > > > 
> > > > Alper
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
> 

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 Dec 2004 11:34:53 -0800

Dan,

I remember discussing these before.

If a host has such behavior, the burden is on the architectures that
allow such hosts to handle the consequences. PANA is not the only
protocol that needs to be considered here. What happens when your host
sleeps and some other host performs a DAD on your sleeping host's IP
address? There may be other asynchronous events that affect host and
network state. Solving PANA-only side is not going to solve all of them.
The right solution would be some architectural design that
coordinates/schedules sleepy hosts. 

Alper

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 20, 2004 7:17 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Pana] Issue 114: Clarify liveness test
>