Subject: RE: [seamoby] Single sentence problem statements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 2 Feb 2001 00:48:19 +0100

<Disclaimer> 
	I haven't been following every mail in the discussion. I've looked
	through the achives though, but I apologise if I'm bringing up comments
	that were already discussed. Having said that here are some questions 
	below. I'd appreciate your answers.

> Micro-mobility Problem Statement
> ======================================================================
> To avoid extraneous latency and signalling overhead caused by
> MIP, 
> 
	=> Signalling latency and overhead have essentially been reduced 
	by HMIPv6 for MIPv6 and regional registrations for MIPv4. 
	This is done by introducing local agents (MAP and GFA) to manage
	the MN's mobility within the MAP/GFA domain.
	I would refer to these drafts as part of MIP or extensions to it. Was your
	intention to separate them from MIP ? or do you not think that they 
	solve this problem ?

> a light weight micro-mobility protocol running on the edges
> of the global Internet is required for handovers that do not
> require an updated MIP COA.
> 
	=> Ok I'll talk about IPv6 because I just like it more :)
	If you're changing your L3 attachment point or default 
	router, then you are expected to get a new COA. If you're
	moving within one subnet, you are obviously keeping your
	COA. So IP mobility takes place when you change your
	COA. 
	Is this a proposal for nodes that do change their L3 attachment
	point but keep a topologically incorrect address ?
	or is it an attempt to manage mobility within "a" subnet ?

	I guess my question is: should we consider  handovers that
	do not require a change in COA IP handovers ?

	Thanks 
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 2 Feb 2001 01:24:17 +0100

Sorry if you receive multiple copies, the first mails seems to
have disappeared

---

From: "Hongyi Li" <[email-masked]>
Date: Fri, 2 Feb 2001 10:13:59 -0500

Hesham,

The issue here is not only "solving the problem" but also
"solving it in a right way".

-Hongyi

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 2 Feb 2001 16:22:39 +0100

> "solving it in a right way". 
	=> Agreed. .. fully, but what is wrong about the above ?
	Shouldn't this be part of the problem statement. Perhaps 
	it was discussed before ? I would appreciate a reference if it 
	was. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 18:15:09 +0100

Hello Phil, 

	Thanks for the detailed explanation. I hope you don't read
	too much criticism into my questions, I'm genuinely trying
	to understand the problem. 

	Having said that I have some more comments on your statements
	below.

> I think what you are getting at here is that you think that the SeaMoby MM
> work
> is
> completely redundant with MIP fast handoff work right?  
> 
	=> Not quite :) I'm curious to know what we missed in the fast
handoff
	work and I would gladly support a problem statement that shows
fundamental
	problems in the MIP work that can not be fixed.

> You may be absolutely
> correct in the long wrong.  Then again you could also be wrong.  Part of
> the
> exercise the SeaMoby WG has been given by the IESG is to determine IF a
> light weight micro-mobility protocol solves problems NOT solved by MIP or
> perhaps solves problems in a more efficient way than MIP++.  
> 
	=> Again I fully support this, but part of your problem statement 
	(signalling delays and number of signals over the air) are solved
	by MIP++, hence my question.

> I don't think it
> is safe to assume that all the SeaMoby micro-mobility design team members
> have done a detailed examination of all the current fast handoff MIP
> drafts.  It
> is my understanding that many of the people participating on the list have
> a
> cursory understanding of the fast handoff drafts (and if they don't, they
> should
> get one).  Some folks on the list have brought up some problems that the
> work in progress may have.  I will try to recall some of them here.
> 
> INT
> Dana,
> If your reading this thread, it might be nice to add a perceived problems
> with
> MIP(+fast handover) section to the problem statement draft.
> IRET
> 
> 1).  There is a concern that A GFA/FA in every AP may not scale or even
>        be desirable in extremely inexpensive access point devices.
> 
	=> Sure, but for V6 that would be a very simple and inexpensive
router. 
	There are products that support this already in cellular networks.

> 2).  There is a concern that putting an FA essentially everywhere would
>       add a lot of complication to what could be a relatively simple
> micro-
>       mobility handover.
> 
	=> Maybe, but so far this is V4 specific. I'm biased towards V6.

> 3).  There are some thoughts that micro-mobility could possibly be handled
>        completely my MNs (as I am sure have been discussed in MIP ad
>        nauseum in the past.
	=> Ok, worth investigating.

> Pat ,our chair, has a firm grasp on this issue, since one of his main
> chores as
> a WG chair is to avoid redundancy with other WGs.
> 
> Perhaps if you examined the MM draft you would see that what is being done
> in SeaMoby at this time is to articulate problems that MAY require
> micro-mobility.  It is not SeaMoby's current job to to examine existing,
> proposed,
> or dreamed up solutions.  I am not sure I could ascertain from you
> statements
> what it is you wanted added to the SeaMoby micro-mobility problem
> statement.
> I have included the brief problem that I believe caught your eye for
> reference.
> 
	=> Ok I'll read the draft. My main concern was that to be able to 
	articulate an accurate problem statement current solutions must be 
	examined carefully and their weaknesses have to be shown. Otherwise
	you get people like me asking questions. I'm not trying to say the 
	work is not needed, but I really can't understand how the first
statement
	is correct in light of the current MIP++ work. Perhaps you were
trying to
	make it short but it was too short for me to understand.

	One other concern I have is whether you are considering the impacts 
	of supporting more than on mobility management scheme in the 
	MN ? Perhaps I'll get some answers from the draft.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 18:15:09 +0100

Hello Phil,

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 18:29:31 +0100

> > 
> > Pat ,our chair, has a firm grasp on this issue, since one of his main chores
> > as a WG chair is to avoid redundancy with other WGs.
> 
> Correct, and one of the co-authors of the v4 fast handoff work, so I am quite
> familiar with the ongoing work :)
> 
> I believe that the MM folks have raised some interesting questions about
> MIPv6's reliance on IPSec, and the fact that a fast handoff will require an
> IKE exchange. So, minimizing such exchanges will in fact provide the perceived
> fast handoff :) Of course, the MM folks could explain what they are doing much
> better than I could (I am just an observer).
> 
	=> We most certainly do not want the handover to require a new IKE
	exchange and I don't understand how it would. I'm surprised these 
	concerns were raised. The concerns are not valid because MIPv6 
	mandates that the SA be established based on the Home address. 
	Hence, when moving no new SAs are required to update the HA and 
	CNs. As for updating the previous AR, yes an SA is required but there 
	are two solutions we investigated in MIP to solve this :

	1. If you're using a flat mobility management model (no MAP)
	   then we were counting on SEAMOBY to transfer the SA
	   from the old AR to the new one. I think this is a very valid
	   solution. 

	2. If a MAP exists, the MN establishes an SA only when moving
	    between two MAP domains. Therefore the SA establishment
	    will be very rare, depending on the size of the MAP domain. In 
	    other words, depending on how many ARs are advertising a MAP
	    option. 

	As for IKE and whether it's too heavy, spectrum inefficient ..etc
	please have a look at draft-soliman-mobileip-routeopt--mipv6-00.txt 
	which proposes an alternative.

	Hesham

---

From: [email-masked]
Date: Tue, 6 Feb 2001 09:07:28 +0200

Hi Hesham & Phil,

> => Again I fully support this, but part of your problem 
> statement (signalling delays and number of signals over the air) 
> are solved by MIP++, hence my question.

I'm  a little lost.  What is MIP++ (is it something to
be determined)?  

As I understand it (please correct me if I am wrong), MIP is
attempting to create a general mobility solution.  There are 
some enhancements, such as Hierarchical Mobile IP, Fast
Handovers, etc. that are part of the working group.  I am
sure that a large portion of the WG would like that seamlessness
was addressed in some fashion - but I don't think it is part
of the charter.

Anyhow, what I am getting at is that I believe a valuable 
problem for us (SeaMoby & MIP) would be a solution for
seamless handovers.  It could be very well that this
solution involves H-MIP + handovers + context transfers -
or it could be another solution (remember, we are still
just trying to capture the problem at this momement).

Anyhow, I'd like to have in a single document (with relevant
references, of course) a document which 'solves' this problem
and brings together the elements needed.  I'd hope we could
analyze the existing solutions, determine if they are sufficient
and bring together the right elements to provide a solution.

So, IMO, it is a worthwhile exercise to put together problem
statement(s) outlining what we think is the problem.  Afterwards,
we can apply the solutions to the problem and see where we are
at.  In keeping with this, perhaps it isn't useful to say
'protocol x with y & z solutions solves your problem, so
lets not talk about it anymore'. 

I'd really like to see some statements about what folks want
from a handover.  My very highlevel statement would be:

Mobility is and will be an increasingly useful aspect of the 
Internet.  Applications running on nodes which are mobile should 
not suffer adversely due to movement.  Packets should not be dropped 
(more than normal) or delayed dueto handoffs; nor should signaling 
induced by the handoffs adversely affect both the network and the 
users.

Comments?
John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 6 Feb 2001 11:27:52 +0100

> I'm  a little lost.  What is MIP++ (is it something to
	=> I was referring to MIP extensions like Regional for MIPv4
	and HMIPv6 for MIPv6.

> just trying to capture the problem at this momement).
	=> I'm not trying to discuss solutions or push any ideas 
	on the group. I was simply questioning the problem
	statement that Phil sent. Especially the first sentence
	which I believe is an inaccurate statement about 
	MIP. 
	So I hope this doesn't get misinterpreted as a push for 
	HMIPv6 or other solutions. 

> and bring together the right elements to provide a solution.
	=> Sure. All I want to emphasise is that to come up 
	with a problem statement, you MUST say what is wrong 
	with the existing solutions. Otherwise it is not clear what 
	the problem is.

> induced by the handoffs adversely affect both the network and the 
	=> Ok, but what is "normal" ? 
	In the fast handoffs work we were aiming to come close to 
	zero loss due to L3 handoff. How close ? well that's what the 
	investigation should say. 
	Of course losses due to L2 handoff were out of scope. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 8 Feb 2001 01:58:03 +0100

>  > > This is one area that I'd far prefer that if there
>  > > is a way to get this all to work in the usual way
>  > > (read: just recreating the SA), it should be 
>  > > considered.
>  > > 
>  > 	=> Not if you're moving fast within small subnets and 
>  > 	trying to save spectrum !
> 
>    Hopefully it doesn't come down to this kind of
>    tradeoff.
> 
	=> Which tradeoff, the fast mobility part or the small 
	coverage areas or saving spectrum. I don't want to be 
	the one delivering news to wireless operators that they
	will be wasting some of their billions of dollars on licences
	because of a problem that can be avoided. 

>  
>  > 	You ignored point #2 because you agree with it ?
> 
>    No, it's because I generally ignore all of this krufty 
>    back to back tunnel stuff since it's just PSTN access
>    tandems in IP clothes.
> 
	=> Hmmm ... PSTN huh. I guess I'll ignore that. 
	Not worth pursuing really. Either you don't know what PSTN
	is or you're talking about a different solution from the one 
	I mentioned. 

>  > > This is _simpler_ than IKE? Yikes. Also: it looks
>  > > like you've managed to recreate the cross realm
>  > > Kerberos wheel with about 15 years less deployment
>  > > experience.
>  > > 
>  > 	=> So Sending one message from the MN to establish an 
>  > 	SA is more complex than doing an IKE exchange in your opinion ?
>  > 	Apart from suffering the "Yikes", is there a technical argument
>  > 	against the draft ?
>  > 	Really, we'd like to get some technical feedback.
> 
>     Well, first of all the notion that CN has any
>     relationship with a AAA of any sort is highly
>     suspect, IMO. Whose AAA is my apache web
>     server supposed to be contacting?
> 
	=> When people are trying to get customers to 
	pay for their services on the Internet I guess they'll
	see the need for AAA. Even if they're offering services
	for free, they still need to keep the "trouble makers"
	away from their networks. AAA can do that. 

>     Second, if you want centralized key distribution in 
>     the manner you are describing, Kerberos is a far
>     better fit and has been around forever. Kerberos in
>     general has a lot of very appealing properties for
>     fast mobility and scaling.
> 
	=> I'm not trying to replace Kerberos or IKE for that matter 
	and never claimed this method is better than either one. 
	The idea was that since AAA will be widely deployed
	(at least in mobile networks) it can be taken advantage
	of in this manner. 

	Hesham

---

From: [email-masked]
Date: Thu, 8 Feb 2001 11:32:28 +0200

Hi Hesham,

> 	=> I was referring to MIP extensions like Regional for MIPv4

I kind of guessed, but just wanted to make sure :)

> 	HMIPv6 or other solutions. 

Not a problem, if & when it is time to discuss solutions,
I'd hope you'd state the case for HMIPv6.  

Also, MIP is somewhat of an amorphous beast - depending upon
what extensions you support, etc.  I think that people's
results will vary greatly, depending upon what extensions
are used, etc. 
 
> 	with the existing solutions. Otherwise it is not clear what 

Except it is hard to hit a moving target.  I think that the first
draft should attempt to be a more generic problem statement,
meaning what it is we want to solve.  The problem would be something
that isn't being mass deployed at the moment.  Again, if
the problem is solved with HMIPv6 + context transfer (for example), 
then documenting this is useful.  If another solution is needed,
then we still need a paper trail, IMO.

> 	Of course losses due to L2 handoff were out of scope. 

I'd say that we are talking about the same target.  Though, I have
a question - I thought that goal of the fast handover was 'fastness'
i.e. - accomplish the handover with minimal delay, therefor reduce
any latentcy due to the handover process.  Is seamlessness a goal 
as well?

thanks,
John

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 9 Feb 2001 11:31:52 +0100

>  > 	There is nothing we can do in IETF about L2 handover IMO. 
>  > 	So we can't guarantee zero packet loss in the intra-access 
>  > 	technology case. 
> 
>    I don't think that the last sentence follows from the first.
>    Fast handoff seems pretty applicable to both intra and inter
>    access technology. It may just be redundant and possibly 
>    less efficient than an intra-L2 solution.
> 
	=> Sorry, I should have clarified this a bit more. The Fast Handoff
	mechanism we have today is designed to allow the MN to
	anticipate its movement by getting the information about its
	"new" subnet from the current AR. the underlying assuption 
	here is that the MN is not simultaneously data-connected to 
	both ARs. That is why I see it as beneficial for intr-access 
	technology case. I believe MIPv6 can handle the inter-access
	case (where the MN has 2 interfaces and can receive data 
	on both). So while the design is not restricting it to intra-access
	(and it shouldn't) I see the intra-access case as the main
beneficiary. 

	Hesham