Subject: [mobile-ip] comments on low latency handoff draft

From: Phil Roberts <[email-masked]>
Date: Sun, 29 Jul 2001 21:54:27 -0400

Hi,

    here are some more general comments on the draft.

    The draft assumes that the L2 will be able to provide information that
says a handoff is about
to occur, but no concrete information about when it has occured.  I find
this a little odd.  Are there
some concrete examples of L2 technology someone could point to like this?  A
lot of what's in this draft
seems to rest on this second assumption.  It justifies the need for
bicasting in the POST REG method.

    On page 5, it says that "[t]he registration process takes some non-zero
time to complete as the Registration Requests propagate through the network.
During this period of time the MN is not able to send or receive IP
packets."  I don't follow this.  It should be able to send if it is
connected and possibly receive though not at its home address.

    In table 1 is it useful to include a trigger for a link down status?
(IE. I just told the mobile to go somewhere else so you can't reach it via
this link anymore).

    On page 9 "no dependence on a wireless L2 technology,"  should probably
be clarified in the light of the presence of various L2 triggers the
protocols make use of.

    On page 10 (pedantic) s/order to not delay/order not to delay/

    On page 11.  I don't understand what's being said in paragraph 3.  "The
MN performs movement detection upon receipt of either a solicited or
unsolicited RA,...."  By movement detection I gather from the rest of the
explanation that it is "possible upcoming movement detection?"  How does a
mobile node MIP client know it has actually moved?

    On page 15.  "the trigger timing SHOULD be arranged such that a full L3
...."  Hmmm.  This seems like a curious requirement.  This seems more like
an assumption about the underlying technology.  How can we specify in *this*
document how an L2 should be engineered?

    On page 17  "... are also useful to support ping-ponging." should
probably be reworded.  Perhaps "... are also useful to support proper L3
operation in the presence of ping-pong behavior at L2?"

    On page 23 Perhaps it would be possible to elaborate on some of the
specifics to smooth the behavior in the presence of ping-ponging?  I'm
assuming the nFA gets some traffic and finds out somehow that the mobile is
back on the oFA and starts sending it back?

    On page 23 s/egress/ingress/

    On page 26  "The MN MAY ... establish a link-layer connection with the
MN."  I suspect one of these MNs should be something else.  

    On page 26  "The oFA SHOULD stop bicasting ...."  Why SHOULD rather than
MUST?

    On page 31  would it be helpful to have a reference in the IMSI
extension to where one could get info on IMSIs and connection ids.  Does the
length of this extension include the subtype field as in the other
extensions?

    Anybody got any patents that they need to tell us about?

Phil

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 30 Jul 2001 16:58:36 +0200

Hello

Thanks for the comments. Some replies below.

> bicasting in the POST REG method.

POST-REG doesn't need bicasting for the reason that there is no
information of when the handoff has occurred. It's just that
you won't be told "handoff will happen in precisely xxx.xxx msecs".
In any case, the draft also supports triggers saying "handoff has
occurred". A trigger could be a message from L2 identifying that the
handoff is being requested/initiated. That's an example of the "about
to occur" case. There are also "network handoff complete" and "mobile
handoff complete" triggers (as reported in Table 1) which communicate
that the handoff event has occurred. Both types of trigger are used.

> connected and possibly receive though not at its home address.

Until the FA has made sure that the user is authorised to use the
network it should not give service to the MN. That means that the FA
must wait for the reply. So the MN should neither receive nor be able
to transmit. Am I missing something?

> (IE. I just told the mobile to go somewhere else so you can't 

That could be another trigger. What would it be applied to?

> be clarified in the light of the presence of various L2 triggers the

I thought the point of having triggers was to be independent of a
particular wireless standard. By this I mean that the "about to
handoff" trigger comes from different nodes in different wireless
standards but is presented as a single logical trigger to the
receiving entity. Of course not all wireless systems will have
all the triggers. But if the trigger is available it'll be generic.
What were you suggesting?

>     On page 10 (pedantic) s/order to not delay/order not to delay/

OK.

> mobile node MIP client know it has actually moved?

I'm not sure I understand your question.
Are you saying that the MN must know when it actually moves?
What does the MIP client need to do when it finds it has actually
moved?

> document how an L2 should be engineered?

We don't. What we specify is the anticipation of the L3 handoff.
The implementors then need to make sure that the anticipation
time is appropriate for their L2 system.

> operation in the presence of ping-pong behavior at L2?"

OK, but I guess the meaning is clear isn't it? (defined ping-pong
in terminology).

> back on the oFA and starts sending it back?

It's basically that the ping-pong will cause continuous triggers
and therefore continuous tunnel setups between oFA and nFA.
So yes, traffic gets sent back and forth or just dropped if there
is not enough time to setup the tunnel.

>     On page 23 s/egress/ingress/

OK.

> MN."  I suspect one of these MNs should be something else.  

Yes thanks, the first is FA.

>     On page 26  "The oFA SHOULD stop bicasting ...."  Why 

I think that is a MUST.
 
> length of this extension include the subtype field as in the other

yes.
This may need some more clarification. I believe that this IMSI
coding was aimed at CDMA2000, but it would be good to make sure
it works in other cases too.

>     Anybody got any patents that they need to tell us about?

Not that I know of.

/Karim

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Jul 2001 11:34:52 -0400

Hi,

> to transmit. Am I missing something?

No, I'd just make what you stated clear in the draft.

> That could be another trigger. What would it be applied to?

packet forwarding from the old FA/AR for smoothing.

> What were you suggesting?

Just that (some of?) the layer 2 triggers themselves while abstracted the
way you
suggest are needed for the methods in this draft.

> What does the MIP client need to do when it finds it has actually

Hey, I'm asking the questions here!!!

Seriously, I didn't understand the text and was trying to figure out why it
was there.
Now that I've gone back and read it more closely I understand what it's
saying.  Disregard
this question.

> time is appropriate for their L2 system.

Well, the document uses a SHOULD to specify something that is implemented
elsewhere rather than in the entities that are making this part of it work.
I suppose this is ok, but it strikes me as a little strange.  Stating it
as an assumption about how the underlying technology has to be engineered
for
this to work would be another way of doing it.

> OK, but I guess the meaning is clear isn't it? (defined ping-pong

You and I know what ping-pong is, or what it is in this context, but I'm not
sure all readers or reviewers will.

> is not enough time to setup the tunnel.

Can you incorporate this explanation, then?

> /Karim

Good, thanks,
Phil

---

From: James Kempf <[email-masked]>
Date: Mon, 30 Jul 2001 10:53:01 -0700 (PDT)

Phil/Karim,

Maybe we can remove the section on L2 triggers and instead make
reference to draft-manyfolks-mobilereq-l2-00.txt? Seems better
to have this information in one place, makes it easier to update.
We would, of course, still need to edit to reflect how
the triggers are used (e.g. using a "Link Down" trigger to
signal that handoff did, in fact, occur as opposed to that
handoff is anticipated).

		jak
>From: Phil Roberts <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] comments on low latency handoff draft
>Date: Mon, 30 Jul 2001 11:34:52 -0400
>
>Hi,
>
>
>> 
>> >

---

From: Phil Roberts <[email-masked]>
Date: Mon, 30 Jul 2001 14:29:31 -0400

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 1:53 PM
> To: [email-masked]

> signal that handoff did, in fact, occur as opposed to that

I didn't see the 2 triggers in opposition, but complementary.

---

From: James Kempf <[email-masked]>
Date: Mon, 30 Jul 2001 11:38:41 -0700 (PDT)

>I didn't see the 2 triggers in opposition, but complementary.

Right, that's what I meant. The low latency draft currently contains
a somewhat outdated list of triggers, that doesn't reflect the
more recent thinking in draft-manyfolks-mobilereq-l2-00.txt. Link Down
is not mentioned. This is one of the reasons I would like to
consolodate discussion of L2 triggers there, with references in
other drafts as ncessary.