Subject: Mandating Route Optimization

From: [email-masked]
Date: Wed, 29 May 2002 08:27:42 +0300

Hi Hesham,

> => 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.

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: Charlie Perkins <[email-masked]>
Date: Tue, 28 May 2002 22:53:07 -0700

Hello Hesham and John,

Your analysis about MUST/SHOULD would imply that hosts
SHOULD implement TCP's particular flow control mechanism,
whereas in fact they MUST, for the health of the Internet.
Thus, I do not believe that you have put forward the correct
basis for making the determination.  I think that we can mandate
this behavior on the basis that the future Internet will suffer to
the extent that we do not.  Maybe we have enough remote
bandwidth today to place delay bounds that people today
find acceptable, but there is not any assurance whatsoever
that this will be the case 10 years from now, nor even 2 years
from now if we solve the problems of really reliable interactive
voice and video within the nearer term future.  Yet, IPv6 is
supposed to last for many more years than that.

While I do not think that the case for mandating Route
Optimization is as strong as for mandating flow control
under TCP, I think it is very strong nonetheless, exactly
because noncompliant hosts will have distant and negative
effects on many other nodes in the Internet.  In fact, I would
say that the problems introduced by failure to implement
Route Optimization will motivate the introduction of kludgy
substitutes, much as the lack of address space for IPv4 has
motivated the introduction of NATs.

We have to do better.  I would say that the case for Route
Optimization is at least as strong as for IPsec and for
stateless address autoconfiguration, if not as strong as
the case for TCP.  And, none of these four examples
fit within the guidelines that are suggested by Hesham.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 28 May 2002 23:01:56 -0700

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.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 28, 2002 10:27 PM
Subject: Mandating Route Optimization

---

From: "James Kempf" <[email-masked]>
Date: Wed, 29 May 2002 00:50:35 -0700

Hi Charlie,

TCP flow control was implemented in response to congestion collapse in
the late '80s. If something like that happens as a result of widespread
Mobile IP implementation, you can be sure that it will become a MUST.
:-) But, for now, it is very easy to see the extra amount of work route
optimization would add to implementing an IPv6 stack, but very hard to
see what effect lack of route optimization would have on traffic flow in
the Internet when mobile nodes are widespread (though, of course,
everyone has an opinion). So making it a SHOULD seems like the best
tradeoff.

It is really too bad that there is not some kind of large scale,
supercomputer simulation of the Internet that we could tweak when these
kinds of questions come up. This would allow the IETF to base decisons
on some kind of data (though people do argue about simulations) rather
than just on intuition.

            jak

----- Original Message -----
From: "Charlie Perkins" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 28, 2002 10:53 PM
Subject: Re: Mandating Route Optimization

---

From: [email-masked]
Date: Wed, 29 May 2002 18:20:14 +0900

>fit within the guidelines that are suggested by Hesham.

	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.

itojun

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 29 May 2002 09:36:10 -0700

Hello Jim,

There are at least three kinds of inputs to this process:
	data, facts, and opinions.
I've lumped together "intuition" and "expertise" under
"opinions", and I point out that it is a mistake to
deprecate the latter in the way that some readers of
your note may tend to do.  With this in mind, I have
some comments on your message.

> Mobile IP implementation, you can be sure that it will become a MUST.

Presumably, you are not suggesting that we have to get burned first
before taking action.  Instead, you probably mean to suggest that
the threat is not assuredly imminent.

>    But, for now, it is very easy to see the extra amount of work route
> the Internet when mobile nodes are widespread

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.

Opinion:

The probability is very high that the future Internet will
be predominately composed of mobile devices.  If you think
otherwise, try counting your mobile Internet nodes versus
your stationary ones, and then lump in 1 billion mobile
telephones into the overall mix.

Opinion:

We should expect to see new applications related to messaging
and multimedia and data mining.  These new applications should
not be encumbered with a legacy (created by us right now) that
assures long delay paths crossing the Internet multiple times.

>                                               (though, of course,

I disagree with this.  It is about the same as saying that a device
can be IPv6 compliant even if the engineering budget and marketing
timetable for the vendor persuaded management to delete features
that did not harm the device itself, only other devices.

I believe this leads to the phenomenon called the "tragedy of
the commons".

Making it a SHOULD means you cannot fault any vendor for making
devices that continually cause extra work for numerous remote
Internet nodes.

> on some kind of data (though people do argue about simulations) rather

Well, I agree that it would be a lot better if we had this
information.  In the meantime, I guess the best we can do is
try to understand the problem, given the best factual basis
we have, and using the best expertise we can gather to improve
the future scalability of using mobile devices in the Internet --
that is, the scalability of almost the entire future Internet.

I'd be interested to find out which of my opinions (or facts!)
you think is leading me to the wrong conclusion...

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 29 May 2002 20:56:36 -0700

Hi Charlie,

> some comments on your message.

It was not the intent of my note to deprecate opinions.
The opinion of a knowledgable person is always valuable.

> the threat is not assuredly imminent.

Human nature being what it is, the hard task in front of of your nose
gets more attention than the vague threat somewhere in
the future, regrettably. Otherwise, we would have see strong measures
in place for solving global warming back in the mid 1990's.

> communicate with a local correspondent.

We are talking about adding the tunnel header, right?
If so and if you mean the relative volume of the data traffic
will be increased by a factor of 2, that, of course, depends on the
packet size. If the packet is a 40 byte VoIP packet, then I agree
with you. If it is a 1500 byte HTTP packet (most common size
on the Internet today, I'm told) then the relative increase won't be
nearly as large. People are more likely to look at the latter than the
former when they consider route optimization because most of the traffic
now is of that nature. This may be shortsighted, but it is
how practical-minded people (which means most engineers)
tend to think

> telephones into the overall mix.

My opinion is that, in the near future, again unfortunately,
most of these devices will likely be GPRS nodes (aside: this text
is coming to you courtesy of Docomo's wCDMA GPRS network).
And most of them won't be doing VoIP. So Mobile IP won't likely
play a big role immediately, though it will in the intermediate
term. VoIP (where, in my opinion, route optimization is
critical) probably will be important in the longer
term. But this is pretty crystal ball.

> that did not harm the device itself, only other devices.

I guess I don't follow your logic. RFC 2119 is fairly explicit about
what SHOULD and MUST mean, and, to me, the text on SHOULD
closely matches what route optimization provides. I think
we disagree here.

> you think is leading me to the wrong conclusion...

I don't think your conclusion is entirely wrong (and that is my
opinion). As I mentioned in the original  note, it is possible
that your opinion on the effect of lack of  route optimization may
happen.
Where we disagree, I think, is in the difficulty of judging how likely
it is
and when it might occur. It is necssary to balance that uncertainty
against
the certainty of imposing additional requirements on people's
IPv6 stacks. Since we are trying to get people to implement and
deploy IPv6, we need to try to minimize the number of requirements.
Of course, this leaves it up to the implementor's and deployer's
judgement about when to implement and deploy route optimization.

The view I have is that standards can always be updated. 3GPP
is unfortuantely much better at realizing this than we are, which
is perhaps why they are able to get their standards completed
more quickly. Making route optimization SHOULD establishes a
pretty strong stake in the ground about what the WG thinks is desirable.
All things considered, I think that should be enough for now.

            jak

---

From: Brett Pentland <[email-masked]>
Date: Thu, 30 May 2002 14:43:04 +1000

Hi,

Sorry if I'm butting in or completely off the mark but I got the
impression from Charles' email that when talking about a capactity
multiplier, he was referring to the number of links that packets have to
traverse to get to their destination, rather than the overhead imposed
by tunnelling headers.  For example, a route optimised VoIP stream might
use up 30 kb/s on, say, two links rather than on twenty.

Cheers,
Brett.

James Kempf wrote:
<snip>
> how practical-minded people (which means most engineers)
<snip>

-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Brett Pentland                  [email-masked]
 CTIE - Centre for Telecommunications and Information Engineering
 Department  of  Electrical  and   Computer  Systems  Engineering
 PO   Box   35,   Monash   University,   VIC,   3800,   Australia
 Phone : +61 3 9905-5245                    Fax : +61 3 9905-5358
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "James Kempf" <[email-masked]>
Date: Wed, 29 May 2002 22:00:25 -0700

Brett,

OK, thanx that wasn't clear to me. I agree that the number of links will
increase. Route optimization certainly will help, and I am not disputing
that.

            jak

----- Original Message -----
From: "Brett Pentland" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Charles E. Perkins" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, May 29, 2002 9:43 PM
Subject: Re: Mandating Route Optimization

> > > > optimization would add to implementing an IPv6 stack, but very
hard
> > to

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 30 May 2002 17:14:05 +0900 (JST)

I fully agree with James.

Even without supporting RO, the CN can communicate with any MNs using
a bidir-tunnel (which is your concern, though).

From an implementor's point of view, manating RO will pose noticeable
extra work to all IPv6 implementors.  It is not so easy to implement
RO (which means implementing the RR procedure and BCE management).

Can't we deploy RO gradually?  At the initial stage, the IPv6 nodes
which support RO may be restricted to some domains (such as an IP
telephone carrier).  But even in such an environment, we are able to
communicate with those nodes using our nodes which are not support RO.
If people want to communicate with moving nodes and want to comunicate
with nodes even when they are moving, more need for supporting RO is
raised.

Some time ago, the MIP6 draft said that all IPv6 nodes had to support
HAO.  Because of this, some implementations currently shipped process
HAO.  This is bad.  Bad because processing unverified HAO has threats
already discussed in mobile-ip WG.

We now have a option not to mandate HAO processing.  In this case, we
communicate with those not supporint RO using bidir-tunnel.  I think
more needs for mobility applications will make 'SHOLD' to 'MUST' in
fact, like the TCP flowcontrol.

Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>
--------------------------------------------------------------------
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: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 May 2002 10:13:47 -0700

> RO (which means implementing the RR procedure and BCE management).

from another implementor's point of view, this is nonsense. a lot 
of emphasis has been placed on the current MIPv6 internet draft to 
minimise the work the CN has to do. I can get you some code, if you 
think it is so difficult to implement.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 May 2002 22:04:08 +0300 (EEST)

> think it is so difficult to implement.

Please show.  Is it 50 lines, 100?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 May 2002 17:15:22 -0700

hi Keiichi,

sorry about the earlier mail. I realised it was rude and not 
called for. 

I will try to rephrase what I said. the CN implementation as it
is described in draft-17 is quite simple (IMO). a lot of care was
taken to make the CN as stateless as possible (at the cost of
extra work by the MN).

regards
Vijay

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 31 May 2002 10:53:41 +0900 (JST)

From: Pekka Savola <[email-masked]>

> Please show.  Is it 50 lines, 100?

I hope it  easy.

In my code (though I did not implemented any RR code yet),

a binding cache management requires 250 lines or over.
an extension header management requires 800 lines or over.
plus some header files.

I did not count any lines which was required to modify to support CN
functions on the existing code (such as ip_input/output,
nd_input/output, etc..).  The final code will be greater than this.
Again, I did not implemnted RR yet.  I don't have a concrete idea how
many lines do we need to implement RR.  It may be trivial or...

# of course, it depends on implementors if this number is big or small...

Best Regards,

---
Keiichi SHIMA