Subject: RE: [seamoby] To page, or not to page

From: James Kempf <[email-masked]>
Date: Fri, 30 Mar 2001 08:32:47 -0800 (PST)

Alessio,

>But there is a disconnect here: if the mobile goes dormant, no way you can
>do
>a L3 thing, whatever you could do is a L2/L3 coordination. as such, this
>becomes
>a technology dependent work. 
>

There are a number of ways to handle this. The mobile node could
explicitly signal at L3 when it goes dormant. A timer in the network
could go off if the mobile doesn't periodically report, and send
an L3 message to the tracking agent. Neither of these involve
dependence on explicit L2, though they may involve an abstract L2
trigger (for example, a trigger on the mobile node that it is about
to go dormant).

>The requirement should be: the IP location update protocol
>shall be efficient with respect to mobile Power use.
>

We can get into splitting hairs here about what we call it, but
I think there is broad concensus in the working group to call it paging.

>That is acceptable, but I dont see the need for a paging protocol. Just send
>data.
>the APs where the MN is not attached, will drop packet, and you are set.
>

So you want to handle a defect in the routing protocol by falling
back on TCP retransmission, or, if TCP isn't used, whatever application
specific UDP retransmit protocol happens to be there? IHMO, it is
poor design practice to depend on error mechanisms to handle the
a defect in the routing design.

>This is a seamoby centric view of the world... No matter what,
>you will do what the L2 is expected to work. More acceptable statement
>would be " the protocol location update protocol shall work withhout
>requiring
>L2 operation changes" Or something along the lines of this.
>

Well, Alissio, this *does* happen to be the Seamoby working group,
at least last time I checked. We cannot, in any event, expect any
changes in L2, through we can recommend how to make future L2s
more friendly to IP. The intent here is, as with the fast handoff
work, to figure out some abstract properties of L2 paging that
are shared with a broad variety of implementations. Like paging
areas, for example. And we can then design the L3 protocol such
that, if such support is available, it gets used. 

IPv6 does this with minimum frame size. There is a minimum specified
frame size for L2 in IPv6. If L2 doesn't support it, the driver writer
must write a shim layer that does segmentation and reassembly.

>The requirement on the paging protocol I have are Non existent, consistently
>with the fact that I do not recognize the need for such protocol.
>That req document is not really a requirement document, it is a document
>saying "we require paging, and here is why". However it steers clear from
>defining
>what paging is... Not much agreeable. It is a metarequirement documet on
>some
>Yet to be defined or conceived thing. 
>

May I quote from Section 2.0 of 
draft-ietf-seamoby-paging-problem-statement-02.txt:

      Paging - As a consequence of a mobile-bound packet destined for a
      mobile currently in dormant mode, signaling by the network through
      radio access points directed to locating the mobile and
      establishing a last hop connection. This messaging is in addition
      to simply delivering the packet to the mobile, i.e. last hop
      routing of packets is NOT considered to be paging.
      
This is our definition of paging. I suggest, if you want to throw bombs,
you take it up with the IESG.  

>In my opinon, paging is over the air, the rest is call set-up or
>session managenet, or user traffic...

Position noted. Now, let's get on with the business of defining
requirements.

		jak

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 31 Mar 2001 02:39:14 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Kempf
> Sent: Friday, March 30, 2001 11:33 AM
> To: [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [seamoby] To page, or not to page
>
[snip] 
> >That is acceptable, but I dont see the need for a paging 
> protocol. Just 
> >send data. the APs where the MN is not attached, will drop 
> packet, and 
> >you are set.
> >
> 
> So you want to handle a defect in the routing protocol by 
> falling back on TCP retransmission, or, if TCP isn't used, 
> whatever application specific UDP retransmit protocol happens 
> to be there? IHMO, it is poor design practice to depend on 
> error mechanisms to handle the a defect in the routing design.
>
Hmmm, I believe it's called "the end-to-end principle", as opposed to
"poor design practice".

(couldn't resist, sorry. Your argument smacks of folks who over the
years believed you had to have deterministically loop-free routing and
that routing protocols which permitted transient loops were hopelessly
broken). 

Dave.

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 31 Mar 2001 02:22:47 -0800

Hello Dave,

Since I fall into the camp that believes that routing protocols should
take stringent measures to avoid routing loops, I wonder if you could
characterize the times when such are acceptable.  I would not say
that a routing protocol is "hopelessly broken" if it had transient loops,
but I would say that improvements would be desirable if they didn't
cause some horrid other downside.

Regards,
Charlie P.

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 31 Mar 2001 08:48:42 -0500

> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Saturday, March 31, 2001 5:23 AM
> To: David R. Oran
> Subject: Re: [seamoby] To page, or not to page
> 
> 
> 
> Hello Dave,
> 
> Since I fall into the camp that believes that routing 
> protocols should take stringent measures to avoid routing 
> loops, I wonder if you could characterize the times when such 
> are acceptable.  I would not say that a routing protocol is 
> "hopelessly broken" if it had transient loops, but I would 
> say that improvements would be desirable if they didn't cause 
> some horrid other downside.
>
None of the deployed, operational, and very successful routing protocols
in the internet prohibit transient loops during topology changes. ISIS,
OSPF, RIP2, etc. all have this characteristic. 

The protocols that deterministically prevent loops tend to be much more
complex and bug-prone (e.g. Dual, Jaffe-Moss, etc.)  and have
considerably slower convergence in the presence of any lost control
packets. Some have "hidden" failure modes in which loops can still form
(e.g. Jaffe-Moss) under pathological conditions, like freeze timers
expiring.

Dave.

> [mailto:[email-masked]] 
> > > On Behalf Of James 
> Kempf
> > > To: [email-masked]; [email-masked]; 
> > > [email-masked]
> > > back on TCP retransmission, or, if TCP isn't used, whatever 
> > > application specific UDP retransmit protocol happens to be there? 
> > > IHMO, it is poor design practice to depend on error mechanisms to 
> > > handle the a defect in the routing design.
> > >