Subject: Re: [nemo] Vienna Agenda

From: Chan-Wah Ng <[email-masked]>
Date: 01 Jul 2003 13:12:00 +0800

Hello Thierry and T.J.,

I'll like to request a slot for discussion on multi-homing issues in the
Vienna Meeting.  

One more thing, I understand the basic solution will be the most
important agenda item.  Julien is actually finishing a multihoming
evaluation of the basic solution.  So I don't know if its okay for me to
talk about that within the slot in Vienna.  We have missed the I-D
publish deadline, but will make it available for public viewing via a
URL.

/rgds
/cwng

On Mon, 2003-06-02 at 16:56, Thierry Ernst wrote:
> Dear all,
> 
> The Vienna meeting is fast approaching and we need to set up an agenda.
> 
> Before we request a time slot, could you please let us know what items
> should be added on the agenda in addition to the ones below. Please
> motivate your request and let us know about drafts, if any, that the
> discussion would be based on.
> 
> # Definitely on the agenda
> o Terminology and Requirements
>   draft-ietf-nemo-requirements-01.txt
>   draft-ietf-nemo-terminology-00.txt
>   - comments
>   - what to do next
> 
> o Report from the Design Team
>   draft-ietf-nemo-?????
>   - status / consensus
>   - draft ?
> 
> # Might be good to speak about:
> - multihoming
>   Based on the active discussion on the mailing list, I guess a discussion
>   on multihoming would be useful. 
> 
> - Threat analysis    L
>   Let me remind you "threat analysis" is one of our milestones, is there
>   is any input regarding this ? That would be MORE than highly appreciated.
> 
> The chairs.
> 
> 
> 
> 
> 
>

---

From: Chan-Wah Ng <[email-masked]>
Date: 01 Jul 2003 13:12:00 +0800

Hello Thierry and T.J.,

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 01 Jul 2003 09:56:30 -0700

Chan-Wah Ng wrote:
> important agenda item.  

not really. we dont really have a lot of unresolved issues
with respect to the basic support. the draft is out. we
dont want a slot describing the solution in the draft. 
people can just read the draft. if there are significant 
issues raised (before the IETF meeting) then it might make 
sense discussing the issues. otherwise it doesnt need a slot.

> Julien is actually finishing a multihoming

it would be good to nail down what exactly NEMO is supposed
to support with respect to mutlihoming at this IETF. I have 
seen too many multihoming scenarios, some of which are not
practical at all (IMHO).

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 01 Jul 2003 09:56:30 -0700

Vijay

---

From: William D Ivancic <[email-masked]>
Date: Wed, 02 Jul 2003 13:55:46 -0400

Vijay

>seen too many multihoming scenarios, some of which are not

I work with mobile networks daily using Cisco's IPv4 implementation.  The 
multihoming we utilize is one router with multiple "roaming" interfaces 
connected to various links.  Some of those links may have foreign agents 
and others may use collocated-care-of-address (CC0A).  For example I have 
one mobile router that has an 802.11 interface (foreign agent); one 
satellite link using static CCOA and one G2.5 general packet radio service 
(GPRS) link using dynamic CCOA over PPP.  The mobile router is configured 
to choose links in the following order of 
preference:  1st  WiFi,  2nd  GPRS, 3rd Satellite.  Although all links may 
be active and register as available, only one link can be used at a 
time.  Although some may wish (or at least think they wish) to use multiple 
links or all links (as with the aeronautical community) the practicality of 
this is questionable.

The following are real measured numbers for some services we have used.

Link     Practical Data 
Rate      RTT  Delay                                                Cost
===========================================================================
WiFi            >1.0 Mbps              100 msec       Free after 
infrastructure or approximately equal to GPRS

GPRS           ~30 kbps        300 - 1000 msec    $30 - $70 per 
month  Unlimited Volume

Satellite          ~ 40 kbps          1 - 2 seconds    $1.00 per minute !!!!

Will Ivancic

---

From: William D Ivancic <[email-masked]>
Date: Wed, 02 Jul 2003 13:55:46 -0400

Vijay

Link     Practical Data 
Rate      RTT  Delay                                                Cost

Will Ivancic

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 04:16:22 +0200

William D Ivancic wrote:
> Vijay
> 
> 
>> it would be good to nail down what exactly NEMO is supposed to 
>> support with respect to mutlihoming at this IETF. I have seen too 
>> many multihoming scenarios, some of which are not practical at all 
>> (IMHO).
> 
> 
> I work with mobile networks daily using Cisco's IPv4 implementation. 
> The multihoming we utilize is one router with multiple "roaming" 
> interfaces connected to various links.  Some of those links may have 
> foreign agents and others may use collocated-care-of-address (CC0A). 
> For example I have one mobile router that has an 802.11 interface 
> (foreign agent); one satellite link using static CCOA and one G2.5 
> general packet radio service (GPRS) link using dynamic CCOA over PPP.
>  The mobile router is configured to choose links in the following 
> order of preference:  1st  WiFi,  2nd  GPRS, 3rd Satellite.  Although
>  all links may be active and register as available, only one link can
>  be used at a time.  Although some may wish (or at least think they 
> wish) to use multiple links or all links (as with the aeronautical 
> community) the practicality of this is questionable.

Thanks for the description, I'm happy to see these kinds of experiments
happen.  Just to show similarity, we call a "roaming" interface a
"mobile" interface.

We started with the same kind of idea for a mobile router prototype that
has several mobile interfaces connected to various access systems (but
behaviour was so difficult to maintain that we preferred to isolate ppp
connections on a "FrontBox").  For example, when a GPRS mobile interface
is used, and the mobile router enters a tunnel (a real tunnel like under
a river) then that PPP connection goes down, the corresponding interface
disappears, routing entries disappear.  When the mobile router exits
that tunnel, re-establishing the PPP connection involved relaunching
many other things.  So we considered designing "FrontBoxes" that would
isolate this behaviour from Mobile IPv6 software:

A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base
Station.  It also has a WLAN interface w1 on which it sends IPv6 RAs
towards MR.  If the PPP connection goes down, this can be repaired
locally withouth MR noticing it.  A WLAN FrontBox has two WLAN
interfaces, one of them attaching to a hotspot WLAN AP, and the other is
named w2.  (A third _potential_ DVB FrontBox would use a terestrial DVB
link as well as a return path on another GPRS phone, such as to still
provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the MR.)

Each FrontBox uses private IPv4 to connect to GPRS or to hotspots
respectively.  They also dynamically maintain IPv6-in-UDP/v4 tunnels
towards a special machine in the home network that has connectivity to
both IPv4 and IPv6 Internets.  Each FB provides IPv6-only bidirectional
connectivity to MR, each sending different RA's with unique prefixes.

A Mobile Router has only one WLAN "mobile" interface that switches
attachment between w1 and w2, as well as another WLAN interface towards
the mobile network link.  The Mobile Router and the nodes in the
mobile network exclusively run IPv6 with network mobility based on
Mobile IPv6 (no IPv4).  Mobile Router switches attachment by means of
a visual interface (GUI), with manual buttons.  When I see the hotspot
access point approaching I push the "WLAN" button; when I see it
in the rear view mirror I push "GPRS".  Of course, better can be done to
automate this with some preferences, as your experiments report.

In this way, all access technologies are separated (read deterministic
and controllable), from the Mobile IPv6 behaviour.

> Link     Practical Data Rate      RTT Delay Cost
> 
> GPRS           ~30 kbps        300 - 1000 msec    $30 - $70 per month
>  Unlimited Volume
> 

Confirms most of my expectations with respect to GPRS
rates/delays/dollar_cost.  I'm suprised though to see "satellite" being
40kb/s (I was thinking it would be much less(?).  Does the satellite
link have a sort of return path?  Could I imagine acquiring  sattelite
link somehow somewhere to make a FrontBox with it?

In our experiments, the data rates as shown by vic between LFN and a CN
placed in the home network varies between 11-45Kb/s (when GPRS) and
about 60kb/s (when WLAN).  Ping delays over GPRS are little over 1s.
The direct communication between WLAN FrontBox and hotspot AP is
standard 11mb/s. All relevant delays and latencies largely depend on the
higly variable number of many hops between MR and HA as well as between
CN and HA and CN and MR.

Billing was not taken into consideration since the billing scheme of the
access providers were themselves a moving ground (WLAN hotspots were
free but business model changing as we speak, including targetting a
"mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes
transferred, not the time length, not flat; to complicate things further
some GPRS operators make pay more if the given IPv4 address is publicly
routable non-NAT'ed, and less if NAT'ed).  Ask me for more information,
or the operators themselves.

There was not any form of multi-homing in our experiments, even if
several access systems were indeed used, or some other times in the
laboratory several Home Agents were used.  Only one connection was used
at a time, and I don't see exactly how a "one-size-fits-all" means to
reasonably use simultaneously these three access systems can be conceived.

And yes, I would very much appreciate if clarifications are sought at
the live meeting with respect to multi-homing requirements and the
practical scenarios in relation to network mobility.  Looking forward...

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Jul 2003 04:16:22 +0200

Alex
GBU

---

From: William D Ivancic <[email-masked]>
Date: Thu, 03 Jul 2003 09:27:26 -0400

>>Link     Practical Data Rate      RTT Delay Cost

We have used two systems to date, both Globalstar. One is an MCM-8 
communication system and the other an MDSS-16.  Both

The MCM-8 is eight 7 kbps channels multiplexed and provides 
bandwidth-on-demand from Globalstar and Sea Tel.  This is a client/server 
based system and require that the first call originate from the mobile 
unit.  If one is willing to pay, one can keep a single (or all) channel(s) 
up thereby keeping a VPN circuit up and allowing for remote users to 
initiate communications.   A single channel currently cost a minumum of 
$0.12 per minute.   Things get expensive FAST with satellites

We also have used an MDSS-16 from Qualcomm which multiplexes up to 16 
channels.   Currently, the MDSS-16 is not commerically 
available.  Currently it is full on bi-directional.  Thus, one is paying 
rough $2.00 per minute for approximately 110 kbps throughput.  The system 
was designed for aeronautical Internet applications.

I understand some people have also multiplexed Iridium channels 
together.  My understanding is that Iridium data channels are 2.4 
kbps.  Globalstar's are 9.6 kbps but really the usable data is 
approximately 7 kpbs.

The advantage of both Globalstar and Iriduim is that they are 
low-earth-orbiting (LEO) satellites and the ground antenna systems are 
omni-direcectional.  That means, there is no need to track the 
satellite.  Systems like INMARSAT swift 64 require tracking for a mobile 
(on-the-move) vehicle.  This is somewhat difficult for aircraft and boats, 
and is extremely difficult for land-mobile due to the rapid change in 
direction (90 degree turns, bouncing, off-road , etc...).

The surprising thing to me regarding the LEO satellites was the extremely 
long delay  of up to 2 or even 4 seconds.  I believe this is primarily due 
to the multiplexing of long thin pipes and buffering to accommodate 
reordering and remultiplexing.   In "theory", LEOs should have very short 
delays probably in the 100 msec range.

>or the operators themselves.

In my opinion, f one is using Satellites or G3 or WiFi, the services 
providers are going to have to realize that they need to bill as flat rate, 
not per packet.  If they do not bill flat rate, they will not realize 
nearly the market they could.  Do any of you pay per packet for Internet 
service be it Cable Modem, Dial-Up or DSL?  Why do the providers need to 
bill at flat-rate?   Corporations need to budget.  You cannot determine how 
many packets will be sent day-to-day, nor is it practical for a user to 
monitor and police their  traffic (amount of traffic).

Also,  NATs are NOT my friend.  They only cause pain and misery.  NATs also 
make true peer-to-peer communications difficult, if not 
impossible.  Unfortunately, there is little one can do today.

Will

---

From: William D Ivancic <[email-masked]>
Date: Thu, 03 Jul 2003 09:27:26 -0400

Will

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Jul 2003 14:37:52 -0700

William D Ivancic wrote:
> 
> The mobile router is configured

this is where I think we need to spend some time. nail 
down the scenarios first. see if the NEMO basic support
solution supports these scenarios. if not, make changes
to the basic support so that it doesnt prevent any 
particular multi-homing scenarios. the exact details
can be specified in a separate draft.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 03 Jul 2003 14:37:52 -0700

Vijay