Subject: RE: [seamoby] L2/L3 Paging

From: "Martin, David P" <[email-masked]>
Date: Mon, 2 Apr 2001 10:05:34 -0400

> 
> Mobile left town, battery died, ... all fall under the catagory: link
> failure.
> 
> It can be resolved with an implementation specific Link 
> Timeout Timer, where
> if no packets are transferred for Link Timeout seconds link failure is
> assumed.  Link reliability is an L2 issue.
> 
> - Kulwinder.

Yes that is one solution, but how should the timer be set?  Different link
protocols, different applications, different RF conditions, etc would affect
what the optimum timeout should be ...

---

From: "Martin, David P" <[email-masked]>
Date: Mon, 2 Apr 2001 08:58:01 -0400

>>  One problem is which interface(s) to deliver
>>  packets to, the other problem is what to do if the mobile 
>>  doesn't respond in a timely fashion.
> 
>    I believe that any paging protocol needs to face
>    this possibility though.

Agree, but I know of only one solution (timer), however, since we are in the
requirements stage I will withold judgement until we have consensus on the
requirements.

>> The second problem of what to do if the mobile is not 
>> reachable is a separate issue.  I feel that it probably *is*
>> a worthwhile problem to solve.

>    I dunno. Nothing extrordinary happens when my
>    DSL line goes down right now. Do we really need
>    to figure out a way backhaul my annoyance
>    dotted with four letter words when that
>    happens? :-)

In wireless, being unreachable is sometimes a transient event (lasting from
milliseconds to days).  So mechanisms could be invented that address the
transient nature of these *some* of these outages.  My concern is where do
you draw the line between which outages are addressed and which are not.

<snip>
> 
>    Hmm. Application by application usually sets
>    of the boil-the-ocean klaxon in my head. Would
>    it be sufficient to set up an access control
>    list on the access router to block all but, 
>    say, SIP and whatever other protocols you
>    wanted to listen for while you're dormant?
> 

When I say "application by application" I mean it in the same context as
QoS, which also will vary by application.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 2 Apr 2001 10:20:19 -0700 (PDT)

> Martin, David P writes:
>  > I'm trying to understand which non-reachability problems we will attempt
> to
>  > address.  If the only problem we are trying to solve is reaching a dormant
>  > mode, I am in full agreement with the problem statement.  
> 
>    As far as I know, this is all we're trying to
>    address.
>  
>  > However, if we want a protocol that we deal with *all* non-reachability
>  > issues (link failures, mobile left town, battery died, etc) then I think
>  > that is two distinct problems.  One problem is which interface(s) to
> deliver
>  > packets to, the other problem is what to do if the mobile doesn't respond
> in
>  > a timely fashion.
> 

We cannot add arbitrary items to the charter, and we are only chartered for
the first case. Having said that, I am not quite sure who the network would
know whether silence is the result of the first or second case. So paging
request failures (or timeouts?) have to be supported.

PatC