Subject: Re: [mobile-ip] Low Latency Issue: Should HTT be MUST, SHOULD, or MAY?

From: Pete McCann <[email-masked]>
Date: Tue, 4 Sep 2001 13:21:48 -0500

In my opinion, HTT should be a natural consequence of the low-latency
mechanism.  That is, it should naturally be a part of the way that
neighboring FAs "compose" in that they support tunneling to/from a
neighbor FA (and to/from a previous FA); a local registration may or
may not be initiated at any time, in a manner orthogonal to the edge
tunnels.  I guess this means HTT is a MUST but it should fall out as a
natural consequence of the way BETH is specified.

-Pete

Sebastian Thalanany writes:
 > Hello James,
 > 
 >                             Perhaps the following paragraph, indicating
 > the context in which HTT is
 > applied, may support the use of "MUST".
 > 
 >                             "In case the link layer triggers, which are
 > required by the post-registration scheme,
 > to support the movement of the wireless end of the BET, are available,
 > then the HTT scheme
 > MUST be applied to avoid a context transfer from the aFA to the nFA for
 > delay-sensitive information."
 > 
 > Regards,
 >      Sebastian
 > 
 > James Kempf wrote:
 > 
 > > At IETF 51 in London, it was agreed to add the Handoff To Third (HTT)
 > > to the POST-REGISTRATION part of the MIPv4 low latency handoff design.
 > > The HTT allows a MN that is already receiving traffic via a tunnel
 > > from an anchor FA to move to a new FA without receiving a new CoA.
 > > It is necessary because the current design provides no support for
 > > the case where a MN is moving so rapidly that it does not complete
 > > L3 handover by the time it moves to a new FA.
 > >
 > > The authors of the draft have discussed this, and are not in agreement
 > > about what level to incorporate HTT. In particular, should HTT be
 > > MUST, SHOULD, or MAY?
 > >
 > > In favor of MAY: We should keep the protocol as simple as possible.
 > > This message is only required in certain restricted circumstances
 > > that will not occur for every radio link protocol, and therefore
 > > it should not be required unless the radio link protocol supports
 > > rapid movement to a new FA.
 > >
 > > In favor of MUST: In addition to fixing the abovementioned bug,
 > > HTT also provides a new capability that is not available in
 > > RFC 2002 nor with PRE-REGISTRATION, namely the ability of the MN
 > > to choose when it should obtain a CoA based upon its traffic.
 > > If the MN is receiving real time traffic, it may choose to
 > > forgo L3 handoff until the real time stream is done, thereby
 > > avoiding the radio link traffic involved in MIP signalling. This
 > > is similar to the BETH proposal for IPv6, which the WG agreed
 > > to incorporate into the FMIPv6 draft.
 > >
 > > The authors need working group guidance on this issue.
 > >
 > >                 jak
 >

---

From: James Kempf <[email-masked]>
Date: Wed, 5 Sep 2001 09:51:49 -0700 (PDT)

I'd like to make a proposal which I think will address Pete's and Sebastian's
concerns. 

First off, there is an issue with regard to whether the mobile node should
perform movement detection or not. When a mobile node,
capable of delaying L3 handoff until real time traffic slows, moves into a 
domain where BETH is supported and registers with an FA, how will it
know not to issue a ProxyRtSol (if mobile initiated low latency
handoff is happening) or to issue a RtSol (if RFC2002bis handoff is
happening)? If network initiated handoff is happening, how will
the mobile node know not to perform a registration when it receives
the Link Up L2 trigger on the new FA?

I'd like to suggest that we add a bit to the Agent Advertisement:

  S - Mobile node can suppress movement detection and handoff at L3 if
      desired. FAs will make sure the mobile node's packets are properly
      routed until a registration for a new care of address is made.
      
This will inform a BETH-capable mobile node that it can calibrate
L3 handoff to its movement pattern and real time traffic volume.

Secondly, I'd like to suggest that we make HTT a MUST, in order
to simplify interoperability. As Pete pointed out, HTT is fundamental
to providing the high performance benefits of BETH, in addition to supporting
quick movement between FAs before the care of address is established. 
If it is not a MUST, problems could arise in deployment.

As a simple example of what could happen if HTT is a MAY or SHOULD,
suppose a small wireless ISP decides that they don't want to support
high performance real time services, so they buy a brand of FA that
does not support HTT. 3 years later they have grown big enough and
that their customers are beginning to request high performance
real time service. Now, they are in the position of having to go
through and replace all their FAs with another brand. If HTT was
a MUST, they could just turn on the bit in the Agent Advertisement
and configure for proper tunneling. 

With regard to the implementation complexity issue, we are currently
working on an implementation of low latency, and so far it really
does not look like a problem.

Comments?

		jak

---

From: chuah <[email-masked]>
Date: Wed, 5 Sep 2001 13:17:30 -0400 (EDT)

James,
sorry, I didn't read multiple emails.  what is HTT?

Mooi Choo

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 6 Sep 2001 13:28:09 +0200

> handoff is happening) 
	=> Because MN initiated handovers will happen in different scenarios
	where BETH can not be used (like WLAN). 

> or to issue a RtSol (if RFC2002bis handoff is
	=> I thought that the whole point was to run vanilla MIP in the MN ?
	Why do we want to inform the MN about BETH or any handover
	mechanism that does not involve the MN ? The MN is automatically
	not doing movemement detection because it doesn't receive
	any indication that it did move. If the MN solicits then you have to
	reply. Let's not change the entire architecture when there is no 
	clear gain. As you said in London BETH is not applicable to all access
	technologies (in fact it is designed with a particular system in mind
	based on the assumptions in the draft), so people designing hosts 
	for the specifc systems will design them with the handover mechanism 
	in mind. 

	So to conclude I don't see any benefit in doing this. Let's 
	minimise the changes now to get this draft out. 

	Hesham

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Thu, 6 Sep 2001 08:49:59 -0500

>	mechanism that does not involve the MN ?

James, I thought one of the advantages of BETH was that since it is a
network initiated (and Network only) handoff protocol, the MN is not
involved in the handoff process. So I agree with Hesham that the MN
does not need indications of what is occuring in the network.

>	Hesham

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 13:10:00 -0700 (PDT)

Raj/All,

OK, then how about the following for what the MN should do:

	If a MN receives an Link Up trigger in which the FA L2
	address does not match the L2 address of its current FA
	and the MN is capable of deferring L3 handover based
	on traffic and movement patterns, the MN SHOULD use
	this capability to optimize the timing of L3 handover
	so as not to impact ongoing traffic. If the MN is incapable
	of deferring L3 handover, the MN MUST issue a SolRtAdv to
	the new FA to begin the process of L3 handover. 

		jak

>content-class: urn:content-classes:message
>Subject: RE: [mobile-ip] Low Latency Issue: Should HTT be MUST, SHOULD, or MAY?
>Date: Thu, 6 Sep 2001 08:49:59 -0500
>X-MS-Has-Attach: 
>X-MS-TNEF-Correlator: 
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>Thread-Topic: [mobile-ip] Low Latency Issue: Should HTT be MUST, SHOULD, or 
MAY?
>Thread-Index: AcE2zFCzQb+4I6K8EdWpVgBQi2kYTQADpp/A
>From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
>To: <[email-masked]>
>X-OriginalArrivalTime: 06 Sep 2001 13:49:59.0528 (UTC) 
FILETIME=[D1E4AE80:01C136DA]
>X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id 
f86DnpIQ024095