Subject: RE: [seamoby] IRTF mm problem statement

From: Phil Roberts <[email-masked]>
Date: Tue, 1 May 2001 16:23:13 -0400

Hi,

    I didn't see any of this in the resultant mm problem statement and it
didn't come out in the discussions in Minneapolis.  Did it not get any
consensus in the seamoby design teams?  I would like to stay focused in this
request for the IRTF.  But it sounds like there is a possibility for more
work of a different sort.  Don't know where it should be discussed.

Phil

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 4:05 PM
> To: Phil Roberts; 'Arthur Ross'; [email-masked]
> Subject: Re: [seamoby] IRTF mm problem statement
> 
> 
> Hi Phil R./Arthur,
> 
> > One might think that a good chunk of this problem can be 
> abstracted without
> > any awareness of radio link characteristics.  The point of 
> this particular
> > piece of research has to do with updating reachability awareness and
> > forwarding tables within the routers the mobile attaches to 
> rather than how
> > to figure out which points the mobiles can reach and how 
> well they can reach
> > it.
> 
> I see this is where the disconnect is Phil R.  We HAD gone 
> much further in
> SeaMoby of our discussions of micro-mobility than your 
> current list of drafts.
> We entertained issues related to the mobile and its view of 
> the network.
> Also, most people were familiar with the OBAST paper which describes
> a method for macro/micro/local mobility where the air 
> interfaces properties
> of CDMA are socketed as Arthur has described (mainly because I recited
> enough times on the list) [even in the CRAPS BOF I had to make this
> argument]{See thwap thread a while back on SeaMoby list}.
> 
> >
> > It would be hard also to make too many assumptions about 
> what that radio
> > system could be.  You include that the architecture should 
> have a provision
> > for a diversity combiner but surely there are networks over 
> which something
> > like this would run on which there is no diversity combiner?
> 
> Also, Phil R., I had discussed many times on the SeaMoby list 
> that diversity
> combining is not just for CDMA.  When done over IP, other radios, even
> TDMA radios can take advantage of it in the outer-loop sense. 
>  I have several
> patents pending on how to do this with TDMA, and frequency hop radios,
> not just DSSS.  Of course those are Motorola's and don't do 
> us much good
> here in the IETF unless some other folks can come up with some stuff
> independently. :-)
> 
> > I wasn't privy
> > to all the discussions in the fast handover design teams in 
> MIP but there
> > was at least some effort put in to thinking about what 
> happens when this is
> > running over a fairly lossy medium.  Whether or not a 
> ping-pong effect
> > should be handled in these protocols was also discussed and highly
> > controversial.
> 
> Again we discussed this in the SeaMoby list and CRAPS list and OBAST
> list numerous times.  The TADD/TDROP timers as used in CDMA can
> work for any RF interface to reduce ping-pong if done in a 
> borrowed and
> abstract way over IP.
> 
> > Both of those can be characteristics of wireless systems
> > with multiple access points, and both may be quite 
> independent of whether it
> > is a TDMA or CDMA or whatever system running at 800MHz, 1800MHz, or
> > whatever.
> 
> In this sense I agree with you, but only so far as it can be 
> done in a common way.
> Macro-diversity selection can be done with almost any radio 
> type, and OBAST
> it is an option.  OBAST allows optionalk make-before-break 
> with any radio type.
> OBAST allows simultaneous and different link layers to be 
> active if they want to
> use it.
> >
> > There has been reluctance so far to design within the IETF a radio
> > technology specific subsystem.  I personally am not willing 
> to push for
> > that.  Perhaps you can get a discussion going on in the new wireless
> > interest list Phil N set up to organize an effort to 
> promote such.  It seems
> > that productive work along the path already specified in 
> the document can go
> > on and the possibilities for exploring ratholes by adding in radio
> > technology specific issues might be plentiful.
> 
> We don't need to explore a rathole here.  What we need to do 
> is ask ourselves
> what things can be made common for all RF L2s and be put over IP? This
> is the IMPORTANT question to ask yourself.  Really!  Of 
> course I sound like
> a broken record, but I think (I hope, Pat and James and Gary 
> and many others) are
> starting to think about this and understand it.  Perhaps not 
> in the same with
> the same zeal that I express. :-)  I am pretty confident that 
> Arthur is on the
> right track.  His arguments about radio physics can be hidden 
> with an OO
> like abstraction of putting macro-diversity over IP.  That is 
> the big first step
> to consider.
> 
> I will show deference to the draft author and chair.  If you 
> want this conversation
> moved over to the new list that is fine I will try and 
> summarize it and move
> it over.
> 
> Thanks,
> 
> Phil N.
> 
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 1 May 2001 16:38:56 -0500

Hi Phil,

I have some more comments.
----- Original Message -----
From: "Phil Roberts" <[email-masked]>
To: "'Phil Neumiller'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 01, 2001 3:23 PM
Subject: RE: [seamoby] IRTF mm problem statement

> work of a different sort.  Don't know where it should be discussed.

Ok here is a quote directly from the SeaMoby MM problem statement.

    *  Mobility maintaining the same routable IP address of a mobile
       node or mobile network.
    *  Handover between heterogeneous networks.  For example, 802.11,
       Bluetooth and 3G cellular.
    *  How to discover a new Access Link and the Access Router serving
       the new Access Link.
    *  How to discover the bandwidth, cost, error rate (and other
       properties) of candidate Access Links.
    *  Involving QoS characteristics as part of the handover process.
    *  Optimize the path for mobile-to-mobile communications.
    *  Enable plug and play capabilities for Mobile Devices, Access
       Routers/Access Links.
    *  Support for mobility of mobile hosts and mobile networks

I don't see the words "host routing" in there anywhere.  I do see lots of
physical issues related specifically to radio links.  What am I missing in
your comment?  This was the consensus???

Best regards,

Phil