Subject: [mobile-ip] some comments on draft-ietf-mobileip-fast-mipv6-00.txt

From: "Phil Neumiller" <[email-masked]>
Date: Sun, 1 Apr 2001 12:11:20 -0500

Hello MIPv6rs,

I know these comments are REALLY late.  Sorry about that,
just catching up on life lately.  

0).  Who is the intended audience for MIPv6?  I might be 
       nice to state that in the draft like "MIPv6 solves the
       problem of fast handoff for ___intended recipient____.

1).  In the abstract the term "more quickly" is vague.  The
      SeaMoby micro-mobility work was moved to the IRTF
      largely because it could not quantify its boundaries with
      MIP, and to be fair the MIP WG has not done its 
      homework here either.  I hope that the first thing the IRTF
      looks at with respect to SeaMoby micro-mobility is 
      what the MIP limitations are, i.e..a. how fast is "fast" handover
      in the general, average, worse case work load models, and 
      how "local" is local mobility exactly?

2).  In the abstract the same vagueness applies to "minimize the time"?

2.1).  I guess this is related to question 0.  Is this work targeted
      at sytems that will use CDMA link layers?  I know that MIP 
      try's to be L2 agnostic but then again there is a matter of maturing
      too,  is it targeted directly at  i.e. 3GPP, 3GPP2?  If it is then 
      the rest of my comments questions below apply.  If not, they can
      be pretty much ignored.

3).  In section 1 paragraph 4 of the introduction I quote the following:
   
        "Situations where the mobile node would be expected to acquire this 
        information from advertisements from the new access router while 
        still maintaining layer-2 connectivity with the previous access 
        router are excluded from consideration in this specification."

     I find this quite puzzling.  Wouldn't this very situation allow for
     the fastest of all possible handovers,  make-before-break,
     i.e..a. soft-handover, which will be endemic to all 3GPP and 3GPP2
     systems?
   
4).  In section 2, I quote the first paragraph

      "The aim of this protocol is to enable the MN to configure a newCOA 
      before it moves to a newAR in a way that can use this newCOA 
      immediately at connection with newAR."

      I find this quite puzzling also.  If we are assuming 3GPP, or 3GPP2
      the handset will have many handoff candidates and many active 
      ARs at any moment (depending on how you do things [of course
      I dropped out of those standards so long ago that I  need to be
      updated]).  At least in theory, the mobile should be able to
      prepare a new home in several different newAR homes
      i.e. analogous to the CDMA candidate list, recall that a CDMA 
      mobile has pilot searchers running all the time and remains in
      active connectivity with several cells.  This is where OBAST, and
      my CNP work came from which leads to being "clueful" about 
      where to hand-off to.  You don't just want to pick any old AR.

      The MN probably has been tracking stats on several pilots for awhile
      and these ARs have been "watching the MN" with smart antennas
      trained on it etc, there is cell breathing, load shedding all kinds
      of stuff the AR/AP knows that MN doesn't know .  This is why
      its important for an "anchor" concept to exist but I am getting off
      on a rant, and you can read the paper if your interested in July 2000
      ACM SIGMOBILE MCCR.

5). In section 2, "mimal interuption" suffers from vagueness too.
     What packets get dropped and why and under what circumstances?

6). In section 2,  the MN initiates the fast handover with sol for proxy.
     The details on this are sketchy.  I think some requirements are needed.
     In CDMA this an area that is incredibly complexity since TADD, TDROP
     timers are used to avoid ping-ponging on the seam and adjust power control
     etc.  Is the idea that when the link layer has handled the incredible complexity
     of establishing a wireless link on a seam (debounced it and whatnot) that only
     then a subnet boundary cross is checked?  Also, it is quite likely in 3G
     that soft-handovers across subnet boundaries will be common.  When
     you look at the Nextel system people can drive up and down the
     coast doing MIPv4 handoffs while downloading mp3 files the whole time
     with gnutella.

7). The network determined handover case would in theory not be
      needed as often (and this in general a good idea to move intelligence
      out to the edge if possible) if the mobile simply had more handover
      choices.  This gets back to my arguments on the SeaMoby list
      about context transfer being coupled with HO request messages
      being sent to a whole set of HO candidates rather than blindly
      sending the HO request to one candidate. For CDMA in
      3G, the MN *will* have knowledge of several handoff targets,
      its time for MIPv6 to take advantages of this, and 

      A).  perform make-before break handovers becuse they 
             are infinitely *FAST*
      B).  perform "enlightened" handovers (not blind faith)
             (i.e. use contract bids to select best candidate and perform
              context transport simultaneously (not over the air but
              over the big I when desirable)
      C).  read the OBAST paper :-)  :-) sorry for the ad.. :-)

8).  Another problem I have with this whole draft is the dreaded SDU.
      Yes we need to bring it up.  The selection distribution unit.
       Perhaps you guys that are engrossed in the 3GPP, 3GPP2 
       standards can say what it is called these days.  I am quite
       mist still be one.   

       The fast handover technique in this draft does not work and 
       has completely non-deterministic behavior when the SDU
       functionallity and location/latency is not factored in.
       If you have an SDU way up stream some where in
       some operators farm, the fast handover latency is going
       to be determined by the round trip latency through that box.
       BTW, that is another reason Peter, Randy I put the SDU (along
       with the RNC) in the BTS in OBAST (works great for 
       MANETs too Charlie!) [peer-to-peer SDUs?  peer-to-peer
       RNCs?  Naaww, it'll never work].  :-) :-)

Best regards,

Phil