Subject: RE: Mandating Route Optimization

From: [email-masked]
Date: Wed, 29 May 2002 10:32:46 +0300

Hi James,

> Yes, that is correct. Something that is a MUST shouldn't just be an
> optimization, it should be necessary for correct, interoperable
> implementation.
> 
> This leaves open whether to make it MAY or SHOULD. By making
> it SHOULD, we make a strong statement that it is necessary for
> best operation. MAY leaves the case too weak, people will feel
> free to ignore it.

One thing that would be interesting would be to have some simulations
on how RO (& how lack of RO) would effect the Internet.  A better
case could be made for RO if simulations would point to a more
stable Internet if RO is mandated.  As Charlie pointed out,
this may be analagous to congestion control in TCP.

best regards,
John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 29 May 2002 09:23:47 +0200

Hi John, 

  > > => Not only, but there are also rules for MUSTs and SHOULDs.
  > > My understanding is that we only mandate things (MUST) if 
  > > not doing it will break communication. MIP was designed to
  > > make ensure that it works with or without RO. So according
  > > to my understanding of the use of keywords, it should not
  > > be a must. Of course it is an important feature and therefore
  > > SHOULD is appropriate IMHO.
  > 
  > That is my understanding.  However, I would like that the SHOULD
  > should have teeth to it.  What I mean is that we should make
  > a strong case on how RO will help hosts, lead to better operation,
  > etc.

=> Fully agree. 

Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 29 May 2002 08:45:07 -0500

Pros for the mandate:
--------------------
Although this may not, initially, seem to be a pro section, it really is.

Are these solutions "kludgy", in your opinion, because they are not end to
end :)? 

Is that what you mean by kludgy :)? 

What are these proposed substitutes and what WG are they being addressed in
:)? 

It does sound to me that some WG will need to take on such work to
facilitate multiple systems wishing to provide route optimization to their
clients. Operators have no control over whether route optimization is
deployed on correspondent nodes or not. 

It also seems to me that later end to end arguments against these alternate
solutions would seem to be ludicrous based upon the decision to NOT make an
end to end route optimization a ubiquitous part of IPv6. I.e. you
self-proclaimed end to enders had better speak up now or forever hold your
peace. 

I also find it a bit rediculous that people sell IPv6 saying that route
optimized mobility is "built-in" to IPv6 when it really is no better than
IPv4 in this regard. I.e. ubiquitous route optimization helps the IPv6
business case.

Making RO a must places control of low cost diversion/indirection
technologies with Operating System manufacturers. 

Cons:
----
I must also say that even if the end to end solution were ubiquitous and
mandated there may still be adequate reasons (location privacy, speed,
security, more optimizations with other IETF soft-state technologies) to use
the non end to end solutions.

Making RO a must places control of low cost diversion/indirection
technologies with Operating System manufacturers.

---------

I hope this helps people understand just exactly what is being decided here
:)

- Charlie Perkins wrote -
> Route Optimization will motivate the introduction of kludgy
> substitutes, much as the lack of address space for IPv4 has
> motivated the introduction of NATs.
>

---

From: [email-masked]
Date: Thu, 30 May 2002 07:18:50 +0300

Hi Itojun,

> 	please be aware of already-deployed IPv6 codebase. WinXP is shipping,
> 	MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC.
> 	even home address option (which is a MUST) is changing.
> 	i don't think it a good situation for implementers.

I think that this will not be a significant problem - I assume that
there will be more IPv6 implementations coming than what what
exists already.  Of course, the existing implementations may not
support Mobile IP and I think that will be something that we have
to live with.

John

---

From: [email-masked]
Date: Thu, 30 May 2002 07:30:04 +0300

Hi Glenn,

I support your analysis.  

John

-----Original Message-----
From: ext Glenn Morrow [mailto:[email-masked]]
Sent: 29 May, 2002 16:45
To: Perkins Charles (IPRG); Loughney John (NRC/Helsinki)
Cc: [email-masked]; Hippelainen Lassi (NET/Helsinki); [email-masked]
Subject: RE: Mandating Route Optimization

Pros for the mandate: 
-------------------- 
Although this may not, initially, seem to be a pro section, it really is. 
Are these solutions "kludgy", in your opinion, because they are not end to end :)? 
Is that what you mean by kludgy :)? 
What are these proposed substitutes and what WG are they being addressed in :)? 
It does sound to me that some WG will need to take on such work to facilitate multiple systems wishing to provide route optimization to their clients. Operators have no control over whether route optimization is deployed on correspondent nodes or not. 
It also seems to me that later end to end arguments against these alternate solutions would seem to be ludicrous based upon the decision to NOT make an end to end route optimization a ubiquitous part of IPv6. I.e. you self-proclaimed end to enders had better speak up now or forever hold your peace. 
I also find it a bit rediculous that people sell IPv6 saying that route optimized mobility is "built-in" to IPv6 when it really is no better than IPv4 in this regard. I.e. ubiquitous route optimization helps the IPv6 business case.
Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. 

Cons: 
---- 
I must also say that even if the end to end solution were ubiquitous and mandated there may still be adequate reasons (location privacy, speed, security, more optimizations with other IETF soft-state technologies) to use the non end to end solutions.
Making RO a must places control of low cost diversion/indirection technologies with Operating System manufacturers. 

--------- 
I hope this helps people understand just exactly what is being decided here :) 
- Charlie Perkins wrote -

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 30 May 2002 18:32:45 -0700 (PDT)

> Here are some facts:
> 
> A. A mobile device transmitting data to a correspondent node will
>    require forward and reverse tunneling through the home network
>    unless it can establish a binding cache entry at the correspondent
>    node.
> 
> B. This can increase the total capacity requirement for the
>    communications by an arbitrary amount, depending on the
>    layout with respect to the home network.  That could easily
>    mean a factor of "thousands".
> 
> Opinion:
> 
> A typical multiplier for (B) will be about 2.  The actual
> number depends on the relative placement of the nodes, and
> the multiplier will be higher whenever a mobile device needs to
> communicate with a local correspondent.
> 
> Thus, the scenario where people would expect the most
> responsive communications will offer counterintuitive
> behavior.
> 
> Solutions for this problem include:
> - restricted mobility
> - transient IP addresses
>   = subcase: EIDs to replace IP addresses as identifiers
> - reengineering human intuition
> - proxy agents
> 
> These are good for more startups and full employment (like
> NATs are), but most of them are bad for the Internet.
> 

Those are all good points. 

A correspndent node as a Server:

A correspondent node that serves a mobile node without route-optimization
is no different than any other IPv6 server. So what is the advantage
of using Mobile-IPv6 here other than using ipv6-addresses ?
Should not this promote more usage of NATs using existing MobileIPv4
protocol with private addresses ? What would be the advantage of
using MIPv6 rather than MIPV4 using co-located care-of-address with
reverse tunnel ?
 
One of the strong advantages of using MobileIPv6 is that route-optimization
is in-built in the protocol, if MobileIPv6 does not specify "Route Optimization"
as  MUST behavior for CNs, we would be sending wrong messages to the 
IPv6 node implementors, as we expect that a large number of mobile
devices will use MobileIPv6 in future.

Depending on the location of the server and the home-agent and the mobile
node the roundtrip time through the reverse tunnel could be much higher
compared to the roundtrip time between MN-CN if route-optimization is
used.

Correspondent Node as MNs:

In this case, imagine two MNs are visiting the same foreign network,
but since one of them does not support RO (since it's not mandatory),
they still communicate via their home-agent which is far away from
the foreign network. This situation will create un-necessary traffic
delay while mandatory route-optimization would have easily cut the
RTT short to a great length. If we transfer large amount of data, imagine
how compelling it would be to have the route-optimization feature in CN!

I believe, for successful deployment of MobileIPv6 and IPv6, route-optimization
should be MUST for all MIPv6 correspondent nodes and thus for all ipv6-nodes.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 30 May 2002 18:37:33 -0700 (PDT)

Thanks,
-Samita

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 31 May 2002 17:05:45 -0500

Alain, Bob and Robert,

You bring up some very good points in that it would be very good to detail
the case for long-lived addresses where the proposed end to end route
optimization provides the intended value. 

I see only three scenarios that make sense and I have reservations about the
proposed end to end solution with each:

1> a person does not wish to disclose their true location to any level of
granularity both to snooping parties and to communicating parties.

reservation:	It is very simple to dump the packets received at a
communicating party and use a traceroute on the mobile's COA. The proposed
solution gives up route optimization for this location privacy so the excuse
for the feature is mute. If a person does not require location privacy then
they can dynamically allocate an address from their  initial point of
attachment and anchored mobility can be used if they go off-domain. In this
case the optimization is not that big of an issue. It does save bandwidth
over skinny links back to the anchor, though.

2> a mobile router

reservation:	This just seems very odd to me to have communicating hosts
be told the location of every single node attached to such a device
especially since the police, defense and clandestine industry is a major
customer of such devices.

3> IP VPN	

reservation:	I'm not sure what admins are going to think about putting
the security of their networks in the hands of the employee's hosts. There
is currently little verbage in the draft about these scenarios. Also the
case where there might be a skinny link is this VPN case. So the bandwidth
saving argument for scenario 1 falls apart.  

4> Every Single Node ever connected to IPv6 has a long lived address or at
least a home prefix.

reservation:	This is a neat idea but due to Moore's law, devices get old
and chunked every two years if not sooner. This doesn't seem like a good
long term solution even with the expanded address space.

Does anyone know of any other cases that make sense short of the PGP
security model?

I do think route optimization of some sort of standardized and ubiquitous
would add significant value and not only in terms of mobility. I'm just not
sure if a completely end to end is the answer. I certainly woudn't get bent
out of shape if the current proposal was mandated though as I think the
ubiquity of the function could be used for other useful purposes than just
mobility.

Glenn

> From: Alain Durand [mailto:[email-masked]]
> Sent: Friday, May 31, 2002 3:31 PM
> To: Robert Elz
> Cc: Bob Hinden; IPng List
> Subject: Re: Mandating Route Optimization
> 
> 
> 
> On Friday, May 31, 2002, at 03:31 AM, Robert Elz wrote:
> 
> >     Date:        Thu, 30 May 2002 16:43:50 -0700
> >     From:        Bob Hinden <[email-masked]>
> >     Message-ID:  
> > <[email-masked]>
> >
> >   | It doesn't seem right to make them non-compliant (i.e., 
> make RO a 
> > MUST).
> >
> > Bob, that's completely bogus as an argument.   I don't know 
> enough about
> > the issues to comment on the substance, but if RO is 
> something that the
> > WG feels is important for all nodes to implement, then of 
> course MUST is
> > the right thing.
> 
> When a new technology solves a critical problem for the operation
> of the Internet, it make sense to make it a MUST, regardless of
> the installed base.
> 
> The issues here are to know if:
> 
> a) RO solves a critical problem to the operation of the Internet
> b) RO is the right approach to the problem.
> 
> If I can be convinced of a), b) is another story.
> Years ago, the Home Address option was defined and
> presented as _the_ thing that will solve _the_ problem.
> Then we discovered that there were security concerns,
> and a whole new approach, much more complex is now
> presented.
> How confident are we that this time, this is the right thing?
> Has it been tried in large scale environment? Are we
> sure it solves enough security concerns that another
> version of RO will not come next year to fix it?
> 
> As some said early, there are a number of implementations
> out there today. It is not that it is not possible to change anything
> at this point, it is that there is a need for a certain level of 
> confidence
> that RO, as defined today, is the right thing and will not change.
> 
> 	- Alain.
>