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

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 18 Oct 2001 10:44:35 +0200

Hi James,

I think there's only one issue left. Two of your
comments below say that a low bandwidth channel on
which there is real time traffic cannot be used by
a MN to send Mobile IP signalling without disrupting
its communication. This assumes a few things:

- that the MIP signalling takes up significant bandwidth
  and disrupts real time traffic
- that there is not enough extra bandwidth for the
  MIP signalling on that channel
- that there is no reserved signalling bandwidth or
  dedicated signalling channel.

Don't think these are assumptions we should rely on.
If we talk about real-time and channel access we need to
consider QoS, radio realisations etc. but this is
complex and varies between wireless systems. I'd prefer
if we kept low latency generic and left this work for
the radio network implementors.

Rgds
/Karim

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: den 17 oktober 2001 19:08
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [mobile-ip] Comments on
> draft-ietf-mobileip-lowlatency-handof fs-v4-02.txt
> 
> 
> Hi Karim,
> 
> > 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?
> > 
> 
> 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.
> 
> > 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,
> 
> 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.
> 
> > 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."
> > 
> 
> 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."
> 
> 
> >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).
> 
> 
> OK.
> 
> >I also think that the 30 min. lifetime is not a major
> >limitation since MNs wouldn't delay registrations
> >that long.
> 
> 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.
> 
> >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.
> 
> If there is precedent for the terminology, then let's
> leave it as is.
> 
> >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.
> 
> OK. I really couldn't figure it out, sorry.
> 
> >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. 
> 
> 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
>

---

From: James Kempf <[email-masked]>
Date: Thu, 18 Oct 2001 09:31:30 -0700 (PDT)

Hi Karim,

> its communication.

The comments were not meant to imply that such a
channel cannot be used for signalling, just that IF
such a situation exists, THEN HTT provides a solution
and SHOULD be implemented. It is the same situation as
with a radio protocol that allows fast movement.

> Don't think these are assumptions we should rely on.

Please see my posting earlier this year, in which
calculations for low bandwidth channels of the
overhead introduced by MIP signalling run upwards
of 100 ms or more. This would be enough to introduce a
noticable disruption in voice traffic. The assumptions
are based on calculated channel blocking times, and
are not completely groundless. I can repost the
numbers if you want, or you can check the archive for
yourself.

> the radio network implementors.

I don't think any of this is necessary. One simply has
to look at how big the signaling messages are, how
fast the channel is, and how long the L2 handover
latency is. If the sum of the latency due to L3
signaling and L2 handover exceeds user perception,
then there will be a glitch. QoS doesn't figure
because the channel is low bandwidth and cannot be
expanded, as is the case for 3GPP2 voice traffic I
believe, but the change in the spec I sent in the
previous message was explicitly limited to such
situations. As for radio realizations, I agree that
will have an effect, but, again, the text was
explicitly limited to cases where the radio protocol
required it, just as for the case where fast movement
would require HTT.

So I still maintain that there needs to be a sentence
saying that a radio protocol with a fixed low
bandwidth SHOULD implement HTT if it wants to maintain
good quality multimedia traffic.

                    jak