Subject: RE: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 17 Oct 2001 11:45:41 +0200

Hello James

> General comment: There are many cases in the document
> in which prescriptive, normative statements are made
> about the protocol that are not phrased in RFC 2119
> language. For example, pg. 16, paragraph 3:
> 
> "...Therefore tunneling advertisements is only
> applicable where the TTL limitation of [1] can be
> relaxed. This should be the case for unicast
> messages."
> 
> Is the last "should" really a SHOULD? Or is it a MUST?
> There are many other examples. The language here needs
> to be tightened.

OK, I'll read it through to clarify these.

> 
> 1) pg. 3 end of paragraph 2, Appendix B. 
> Appendix B is very tentative and not very well tied to
> the protocol discussed. There may well be ways to do
> intertechnology handoff that do involve the protocol.
> For example, suppose the 2nd interface has no IP
> address, and the MN discovers the new AP/FA via either
> L2 information on the second interface, or via a
> capabilities discovery protocol through the configured
> interface (such as the Seamoby CAR discovery
> protocol). The MN could then issue a ProxyRtSol on the
> configured interface for the new FA, and when it
> received the ProxyRtAdv, it could tear down the home
> IP address on the old interface and transfer it to the
> new. This has nothing to do with low latency handoff,
> but it is a use of the protocol that would allow
> seamless handover to a new interface. Note that this
> would avoid having the MN solicit a regular FA Advert
> over multiple subnets.
> 
> I'm not sure how to address this issue. Perhaps
> folding the Appendix into the text with a discussion
> of about how the protocol could, in fact, support
> intertechnology handover would be appropriate.
> Alternatively, given the urgency of getting this
> document out, perhaps sectioning it off into a
> separate document would be better.

The Appendix used to be in the main text. It is only meant
to give an example of a simple way to do handoffs over
multiple interfaces. It does say that the low latency
method may be needed anyway, but provides a scenario
where it could be avoided (depending on coverage areas).
It is more to do with applicability of low latency in
general. I think it should stay somewhere in the doc.
Anyone have strong opinions regarding Appendix vs. main
text?

> 
> 2) pg. 4, definition of bi-directional edge tunneling-
> This still includes text implying that bicasting is
> required. I would suggest changing the first and
> second sentences to:
> 
> "A set of unidirectional tunnels established between
> two FAs for purposes of temporarily routing a MN's
> traffic to/from  it on a new subnet without requiring
> the MN to change CoA."

Missed that one. I'll change it.

> 
> 3) pg. 22, point 4c
> The requirements language needs tightening (specific
> case of general comment.) How about:
> 
> "c) When the MN receives the L2-LU, it MAY initiate
> the Mobile IP Registration process by soliciting an
> Agent Advertisement as described in [1]. If the
> Registration is successful, the nFA takes over the
> role of anchor FA (aFA) from the oFA. The MN MAY also
> choose to defer nCoA establishment, if real time
> traffic is occuring (see Section 4.4)."

We don't have any traffic considerations in the draft, but
apart from that it makes sense.

> 
> 4) pg. 24, Section 4.2, paragraph 1.
> The requirement level of MAY for HTT is too weak.
> There are some radio protocols where HTT is required,
> others where it may not be. It needs tightening. I
> would suggest the following wording:
> 
> "For radio L2 protocols in which it is possible for
> the MN to move so rapidly from one FA to another that
> that a probability exists that nCoA establishment on
> the initial nFA will not complete, HTT MUST be
> implemented. For other radio L2 protocols with
> sufficient L2 trigger support, HTT SHOULD be
> implemented as it provides the opportunity for the MN
> to optimize handover of real time traffic at the
> expense of a certain amount of header overhead on the
> backbone network."

MUST cannot be used in this way. From RFC 2119:

   MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Since HTT is only applicable in certain cases where the MN moves too fast,
it is not an absolute requirement of this spec. What I would propose is
just to use the first part of your text modified along these lines:

"For radio L2 protocols in which it is possible for the MN to move so rapidly
from one FA to another such that a probability exists that the Mobile IP
Registration with nFA will not complete before the MN moves on, HTT SHOULD be
implemented."

> 
> 5) pg. 30, Section 4.4, point 1)
> "...sending the an Agent Advertisement to the MN..."
> ->
> "...sending an Agent Advertisement to the MN"

OK.

> 
> 6) pg. 30, Section 4.4
> The discussion in this section is valuable and useful,
> but too restrictive IMHO and also does not consider a
> couple of other cases. First off, is the FA
> necessarily
> always the default router? Secondly, if not, then the
> FA registration, and, in addition, the HA registration
> need to be renewed as well. Thirdly, since the routing
> through the tunnel for POST-REG is already set up,
> what is the problem with simply renewing down the
> tunnel to the old default router and/or FA, and to the
> HA?

I think the assumption is that the FA is the default
router, but this can be changed if the WG thinks it is
too restrictive. If the FA is not the default router then
reverse tunneling MN traffic to oFA would be complex. Also,
renewing oFA as default router can be done only if the nFA
reverse tunnels traffic to oFA so it does not apply to all
POST-REG. If the FA as default router assumption is valid we could
add a few lines on the specific nFA to oFA reverse tunneling case
where oFA RAs are tunneled through nFA to the MN (in a similar
way to PRE-REG but in the opposite direction).

> 
> As a practical matter, I think most BETs will be
> terminated well before the 30 min. lifetime of the
> default router advert (phone calls reputedly last on
> the average about 3 minutes). But unless there are any
> specific issues affecting interoperability, I believe
> exactly when the network or MN should demand
> termination of the BET should be left up to the
> implementation. One such case obviously is if HTT is
> not implemented, in that case, the MN must terminate
> the BET after the first handoff.
> 

I also think that the 30 min. lifetime is not a major
limitation since MNs wouldn't delay registrations that long.

> 7) pg. 32, definition of Lifetime, pg. 33 definition
> of Lifetime:
> 0xffff should be defined as "good until canceled",
> not "infinite".

That is what is meant by "infinity". From RFC2002 on
Registration lifetime: "A value of 0xffff indicates infinity"
Of course the registration can be terminated using lifetime zero.

> 
> 8) pg. 36, Section 6, first paragraph
> This paragraph is trying to say that for particular
> radio protocols, deployment situations, and
> implementations, smoothing techniques may be required,
> but it is very ambiguous and hard to figure out what
> is being said, IMHO. The title of the section should
> be changed to "Handoff Smoothing Considerations" and
> the language should be tightened to address the issue
> directly. 

It's not only handoff smoothing this section considers,
it's also other issues related to the trigger and handoff
timing. I'll read through to see if I can clarify things.

> 
> 9) Appendix A, also reference [2]
> During IETF 51, there was some discussion about not
> wanting to put a reference in to the abstract L2
> triggers draft in order not to end up with a reference
> to a draft that was not close to RFC, to avoid slowing
> down the progress of low latency. Yet, here is a
> potential reference to exactly such a draft. How close
> to RFC is the regional registration draft? Would it
> make sense to remove the reference, since, while
> extremely useful in the global picture of optimizing
> MIP signalling, the relationship between regional
> registration and low latency handover is somewhat
> tenuous.

I think we should be safe in referring to Regional, but
the chairs can help with this one.
The relationship between PRE-REG and Regional is quite clear
so there is benefit in keeping it as an option since it reduces
latency. It is less useful to POST-REG. 

Rgds,
/Karim

---

From: James Kempf <[email-masked]>
Date: Wed, 17 Oct 2001 10:07:57 -0700 (PDT)

Hi Karim,

> Anyone have strong opinions regarding Appendix vs.

Well, to avoid thrash, let's keep it in the Appendix
then. I actually think there is need for another draft
that clearly specifies how to do intertechnology
handoff, for interoperability purposes, and that this
text would be a good start, but unless the chairs or
another WG member have other ideas, I think we can
send it to the IESG with the Appendix and see whether
or not they feel it is necessary.

> Since HTT is only applicable in certain cases where

I actually don't agree that this is the case. It is
also applicable to a low bandwidth radio protocol if
the MN wants to delay changing its CoA because it has
real time traffic and the MIP signaling would steal
bandwidth from the real time traffic.

> the MN to move so rapidly

I would prefer that the second part be included as
well. If you want, it could also be clarified:

"In addition, HTT SHOULD be implemented for low
bandwidth radio protocols in which MIP signaling may
cause a disruption in real time traffic, since it
allows the MN to seamlessly continue real time traffic
onto a third FA during handover without any MIP
signaling."

OK.

>limitation since MNs wouldn't delay registrations

Agree, but I would leave the actual time out of the
text.

In some respects, since the MN will have to do
signaling over the radio channel to renew its
registrations, it's a tossup whether it terminates use
of the old CoA or not, but I still think it should be
left open as a policy issue. The FA can always demand
termination of the BET if the MN's registration is
reaching the end of its lifetime.

>Of course the registration can be terminated using

If there is precedent for the terminology, then let's
leave it as is.

>timing. I'll read through to see if I can clarify

OK. I really couldn't figure it out, sorry.

>latency. It is less useful to POST-REG. 

Far as I can tell, the WG wants to fast track low
latency, so I think we need to be careful about what
we include in the references. I agree that there is a
clear relationship, and even benefit should Regional
get some deployment momentum, but I think we want to
limit our exposure to possible delays. We could send
it to the IESG with a specific question about whether
or not the reference to Regional should be kept.

Raj, Phil, what do you think?

                     jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com