Subject: [RRG] Mobility in the future

From: Robin Whittle <[email-masked]>
Date: Thu, 06 Dec 2007 14:03:02 +1100

I am replying to Russ White's message 716 (Thoughts on the
RRG/Routing Space Problem) regarding mobility.

Hi Russ,

You wrote, in part, quoting Scott Brim:

>> - Routing and addressing are more fundamental than mobility.
>> Mobility can adapt to R&A but not vice versa.
>
> In other words, mobility is a secondary requirement for IP
> transport. Either it is a small part of the traffic, and will not
> grow, so there is no need to address it (?).... Or, it's not a
> problem that needs to be addressed through routing, it should be
> handled elsewhere. IE, IP == POTS.
>
> That "stuff" folks are running over our transport are fine, just
> solve your own problems, and don't ask me to do it for you. IMHO,
> this is shortsighted.

I agree.  An ITR-ETR scheme with mapping updates which take a few
seconds to be implemented in all ITRs provides a whole new global
system for highly optimised mobility - for both IPv4 and IPv6, with
few new host requirements.

The mobile host needs one or more care-of addresses and a tunnel
from an ETR.  It also needs a tunnel to an ITR, if it can't send
packets out the way it likes from its care-of address.  Ivip
combines ETR, ITR and two-way tunneling into a "Translating Tunnel
Router", as described in this and subsequent messages on the RAM
list around 17 to 18 June:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01547.html

If something slow like LISP was built - slow global query system for
pull (CONS and ALT), or slow push (NERD) - then people would soon be
wanting to make it go much faster to support mobility.

The high speed push Ivip intends to implement isn't just there for
mobility support.  It enables the end-user to implement their own
multihoming service restoration system, with whatever reachability
detection system they like, whatever logic, algorithms, manual
controls etc.  This is much more flexible and modular than forcing
all end-users to rely on whatever logic is built into the ITR, by
the RFC and the restricted nature of the mapping data.

The fast push system also relieves the ITRs of the difficult job of
deciding which of multiple ETRs to send packets too - with many such
ITRs trying to figure out the same stuff on their own.

Another major reason for the fast mapping updates is that it greatly
simplifies the mapping data: just a micronet's starting address, its
length and a single address for the ETR.  This, in turn, enables the
mapping system to work faster than if each item of mapping
information contained a bunch of ETR addresses, priorities etc.

(However, the non-Ivip ITR-ETR schemes which use such complex
mapping data and demand so much of their ITRs have an advantage over
Ivip in terms of load-sharing Traffic Engineering.  Ivip can only
split traffic over multiple ETRs by splitting a range of addresses
into smaller micronets, and having one or more micronet go to one
ETR and the others go to other ETRs.  So Ivip can't split the load
of traffic directed to one destination host.)

>> - In the real world mobile users are rather
>> provider-aggregated, and even if we use the currently conceived
>> route optimization mechanisms, the need for new map lookups
>> will be less than one would think.
>
> Today. Again, I believe it's wrong to base an architecture on
> today's traffic patterns. Part of the job of the IETF isn't to
> solve today's problems, it's to solve tomorrow's problems in a
> way that doesn't impact today's services.

Yes!

IP mobility today is like cellphones in the late 1970s.  We can only
vaguely imagine what it might do, how useful it might be and how
widely it will be adopted.

The ITR-ETR scheme needs to be built anyway, to solve the routing
scalability problem.  Done right, it can be the basis for a new form
of mobility with far surpasses the efficiency and usefulness of
current approaches.

Maybe we can get the cashed up mobile folk to pay for most of the
costs of the ITR-ETR scheme.  Hundreds of millions of people pay
very high rates for cellphone services.

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 09:27:07 -0500

> few new host requirements.

But.... A few seconds is probably too long for it to be useful in a
mobile environment.

:-)

Russ

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Dec 2007 06:55:46 -0800

> But.... A few seconds is probably too long for it to be useful in a

A few seconds is more than sufficient to deal with a number of  
portability and migration use cases.  In particular, anything that is  
quick enough so that TCP connections don't break is extremely  
interesting.

This isn't to say that this type of delay is acceptable for all  
mobility use cases.  You'd probably be pretty upset if your cell  
phone cut out for two seconds at the edge of every cell.  However,  
for cases where your laptop transitions from WiFi to wired Ethernet,  
a few seconds to transition seems eminently doable and beneficial.

Tony

---

From: [email-masked]
Date: Thu, 6 Dec 2007 10:26:18 -0500

I imagine there will be a lot of real-time (interactive) video over IP
or broadcast IPTV applications as well reaching out
to mobile devices (laptops, iphones, etc.).
For such applications a few seconds delay would not be acceptable
when the connection requires seamless mobility from one Wi-MAX cell to another
or from Wi-MAX to WLAN, etc. 

Sriram
http://www.antd.nist.gov/~ksriram/

---

From: Tony Li <[email-masked]>
Date: Thu, 6 Dec 2007 07:44:42 -0800

> or from Wi-MAX to WLAN, etc.

Certainly.  The point isn't to address all mobility issues in the  
routing layer.  Higher frequency mobility will always require more  
mechanisms (e.g., make before break, application interaction).  The  
whole point is to get the low hanging fruit that we can.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Dec 2007 08:32:49 -0800

Robin,

> of mobility with far surpasses the efficiency and usefulness of

Maybe, maybe not. You are skipping over a lot of significant detail.
What type of mobility are you trying to solve? Networks moving around?
Hosts moving around? The implications for what the global routing system
must know about the moving entities are big. Also, what are the
requirements for speed of updates? The type of mobility that is
requested in today's networks goes all the way to up to the speed that
is capable of avoid interruptions in VoIP calls. This may be possible to
do in the routing system, too, but the requirements are very different
from merely supporting, say, site multihoming.

Jari

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 13:31:09 -0500

> This isn't to say that this type of delay is acceptable for all mobility
> use cases.  You'd probably be pretty upset if your cell phone cut out
> for two seconds at the edge of every cell.  However, for cases where
> your laptop transitions from WiFi to wired Ethernet, a few seconds to
> transition seems eminently doable and beneficial.

Except, of course, when you're using the wifi for a phone call, and you
transition to the cell, or to another hot spot with a different address
space, or some such. Most of the mobility applications I've seen only
really become interesting with audio or video feeds involved.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone