Subject: Re: [mobile-ip] Draft on Mobile IP Architecture and Reorg

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 3 Mar 2003 11:43:22 +0900

Dear Xiaoming

Here are some of my comments. 

> > It's the "flexibility" that I'm worried about (putting my service
> > provider hat
> > on).
> >
> > It certainly is possible to tune MAP placement such that the
> > number of packets
> > dropped achieves some optimal value for some number, say 95%, of
> > the MNs. But
> > the other, say 5%, will experience suboptimal performance because
> > the actual
> > handover time is probabilistic.
> >
> > Handling the problem locally at the access router by tunneling
> > packets, like
> > FMIPv6 does, is easier. That's local route repair. There's no
> > need for tuning,
> 
> I don't agree.
> 
> > no additional agent required (reducing cost and operational
> > complexity), and all
> > MNs are covered up to the capacity of the two access routers to handle the
> > tunnels.
> 
> Local route repair is not a panacea for all possible situations. For
> example, two geographically adjacent access routers are separated with
> several hops away and with considerable delay. In this situation, local
> route will experience performance degrade, while regional mobility will
> achieve better performance.

I don't think we can say that regional mobility performs better in this case. 
You evaluate the performance exclusively based on 'delay' only. But 'delay' is not 
the only factor to determine the performance. We should consider 'Packet Loss' too. 
Even in the above case, local router repair can be better with respect to 'Packet Loss'. 

> From above we can conclude that these two solutions both have their own
> locks that they are good at openning. For regional mobility, it happens well
> before the packet arrives the destination link and is suitable for the
> situation I stated above. For local route repair, it takes effect immdiately
> after the packet arrives the destination link and is suitable for the
> situation that previous and next access routers are not far in topology from
> each other.

I can't say it's absolutely impossible that 'two access routers are so far away 
(in hop counts) that the propagation delay between them degrades the performance.' 
But it doesn't seem common to me, especially considering the delay between source 
and access router. And we may solve that problem more easily by simply deploying 
access routers not far from each other (in hop count).

---

From: "Xiaoming Wang" <[email-masked]>
Date: Mon, 3 Mar 2003 15:28:18 +0900

Hi, JinHyeock,
Please find my inline comments.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of JinHyeock Choi
> Sent: Monday, March 03, 2003 11:43
> To: Xiaoming Wang; James Kempf; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mobile-ip] Draft on Mobile IP Architecture and Reorg
>
>
> Dear Xiaoming
>

That's why we need both of them, which is concluded below.

> access routers not far from each other (in hop count).

I think experience from service providers is needed to evaluate your point
here. Moreover, I'd like to point out the situations in which it is
impossible or difficult to deploying access routers near from each other
topologically: access routers from multiple service providers and large
access network. For access routers from multiple service providers, ISP's
policy makes it impossible to deploy access routers at one party's will. For
large access network, it is better to design it as a hierarchical one than a
flat one, and thus it is unavoidable that two geographically adjacent access
routers are far away from each other.

xioaming

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Mar 2003 10:32:17 -0800

Xiaoming,

> routers are far away from each other.

There are a lot of issues involved in handover between multiple service
providers, and I think we would probably do best to concentrate on the single
service provider situation until we've got a better understanding of it. For
example, a handover to another service provider will probably require a
reauthentication sequence with the network from scratch to admit the host into
the new service provider's network. Currently, with my iPass RADIUS client, it
takes about 5 - 13 seconds to admit on a dialup, wired connection, much too slow
for fast handover to be of any benefit. I don't see any technologies in the
pipeline in IETF that are going to change this, though I think it would be a
valid topic for some work.

Regarding hierarchical routing and large topologies, I believe you have a point,
but I don't see the HMIP design as being an exclusive solution. One could
equally well utilize the aggregation router in FMIP and have it take care of
switching the tunnel between various access routers. Alan O'Neill and I wrote a
draft last summer that briefly discusses this issue, but it is now expired. So
the tunnel would run between an aggregation router and a new access router,
removing the need to traverse the T1 line between the old access router and the
aggregation router twice.

What I am concerned about is tying HMIP too closely to handover. As I mentioned
in my response to Hesham, Japanese regulatory policy requires location privacy,
and currently HMIP is the only solution I see for Mobile IPv6. I would therefore
prefer any specification of HMIP for handover to remain outside of the base
draft. To me, this indicates a certain degree of flexibility and broad coverage
in the protocol, tying it exclusively to handover would invalidate this benefit.

                                   jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Mar 2003 09:28:30 -0800

Hi Alex,

> Speaking of which.  My mobile device connects to the IPv4 GPRS network
> in about 1-2 seconds with non-Radius authentication included (which is
> good); but then it takes about 10 seconds for SecurID-based IPsec, or
> VPN for that matter, tunnel setup to Corporate network.  This 10
> seconds is something that can be optimized, entirely at IP level.
> This might hopefully give a shorter sequence tunnel-down/tunnel-up,
> shorter than 10+10 seconds.
>

Do you know what is contributing to this? I presume the VPN tunnel setup is
using ISAKMP and IKE?

I haven't explicitly timed my VPN tunnel setup, but it is required on top of the
5-15 sec for the RADIUS authentication.

> Now, can this scheme of fast VPN down/up be considered as Fast
> Handovers?  It certainly does not involve the first hop AR's, like
> between oAR and nAR.  But it is still a desirable feature.  Maybe it
> would fit better in the Mobile IP/VPN-NAT traversal realm.  On which
> side of the line would Mobile IP/VPN-NAT traversal realm fit?
>

I would classify this as "seamless interdomain handover".

            jak