Subject: RE: [seamoby] micro, schmicro

From: Kulwinder Atwal <[email-masked]>
Date: Tue, 16 Jan 2001 20:12:07 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 7:08 PM
> To: Kulwinder Atwal
> Cc: [email-masked]
> Subject: RE: [seamoby] micro, schmicro
> 
> 
> 
> 
> 
> I think I disagree.  Why would the FAs necessarily find these routes?
> You could have situations like the following:
> 
>  FA1                    FA2
>   |                      |
> (net 1)---------------(net 2)
>   |                      |
> (net 3)---------------(net 4)
>   |                      |
> (AP 1)                (AP 2)
>   |
>  MN  --> handing over to ^
> 
> Here net 1 is a subnet of FA1, and net 3 is a subnet of
> net 1.  The OSPF or RIP path between AP 2 and FA 1, may
> be different that that between AP 1 and AP 2. which may
> have a mesh link between net 3 and net 4 that is unknown
> to FA1 and FA2 right?
> 

Making your diagram technology neutral:
 
  Big I			Big I
   |                      |
 (CR 3)------CRL1----- (CR 2)
   |                      |
 (OAR)-------ARL1-----  (NAR)
   |                      |
 (OAP)                  (NAP)
   |
  MN  --> handing over to ^> 

CR = Core Router

AR = Access Router 

OAR = Old Access Router

NAR = New Access Router

I think your model in encouraging bad real-time network design.  The ARs
should have the functionality to resolve MN moves through one link.  If ARs
agree on one link for passing all MN handover related messages in advance,
this will cut down on the amount of messaging needed for a handover as well.

Either staticly, or dynamically the Access Routers (OAR/NAR) need to agree
on one single path for MN moves in advance of the move.  This path may even
be set once by the Network Administor during network setup.

Further, placing the functionality required for the move that many layers
away from the MN will most likely not result in the real-time behaviour we
are looking for.

This is why I believe the better solution is to place the primary
functionality for the move in the ARs nearest the MN.   

Unlike the general Internet, Real-Time network design must consider
deterministic behaviour as a primary design objective.  

If the Network Designer wishes Real-Time behaviour to be a primary design
goal, then deterministic behaviour must be a primary design objective. 

If we want Real-Time hand-overs then at least:

 - we must place Real-time bounds on "Routed Clouds"
 - move decision making closer to the MN
 - limit handover messaging to one pre-determined path

Also, since the problem space encompasses mobile wireless we must provide
positive confirmation of every message between the MN and an AR.

- Kulwinder.

> 
> 
> Kulwinder Atwal <[email-masked]> on 01/16/2001 
> 05:46:42 PM
> 
> Sent by:  Kulwinder Atwal <[email-masked]>
> 
> 
> To:   Phil Neumiller/MW/US/3Com, [email-masked]
> cc:
> Subject:  RE: [seamoby] micro, schmicro
> 
> 
> 
> >
> >
> > Um, actually what subnet you are on has an intimate relationship to
> > what edge router you are using or what core router. The whole point
> > of having a router is to bridge two subnets, in subnet 
> based routing.
> >
> > James,
> >
> > I understand this.  However, it may be the case that useable
> > routes exist
> > between
> > an edge router pair that are unknown to the mobility agents
> > being used.
> 
> If the routes are IP routes then the IP mobility agents will be
> aware of them, and will find the shortest path.  Otherwise, 
> there is an
> error in the implementation.
> 
> If the routes are L2 routes then this is an L2 issue.
> 
> Unless you are getting at something else.
> 
> 
> 
> 
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jan 2001 17:54:23 -0800 (PST)

I think you are misunderstanding Phil's point
which I took to mean that the placement of the
foreign agent is not necessarily the same as the
placement of the AR. While I wonder whether that's
an especially wise idea from the standpoint of
needing to have a security relationship with both
the AR (aka NAS) and the FA (for BU's, say), I
think I probably disagree with your premise too.
I don't think that we can or should make any
assumption that the AR's will always know a priori
about one another. I think it's useful in many
cases to allow such topology knowledge to be used
for network based moves, but this is not
sufficient: it's a local optimization. The more
general case where the old AR doesn't know squat
about the new AR is also a perfectly valid case
that needs to be accounted for.

	   Mike

---

From: Jonathan Taz Mischo <[email-masked]>
Date: Sun, 21 Jan 2001 19:02:32 -0600

I know there is much discussion on this that has happened in the last
week...alas, I'm only caught up to here, so I must interject right now...please see my
comments below...(this is gonna hurt)

-Jon

> this will cut down on the amount of messaging needed for a handover as
well.

I almost died when I read this.  I think YOUR mental model for good design is
flawed.  I acknowledge that a lot of people are transitioning their thinking
from circuit switched to packet switched, and that there are good ideas for some
things, and bad for others.  However, in this case your logic is flawed. 
 
> be set once by the Network Administor during network setup.

No, no, NO!  Have you ever worked with a real-world IP network with QoS?  If
you have, you know that there are a lot of things going on, and failures occur
(often uni-directionally on a path), which is precisely why you DON'T do this. 
Why bother with packet switching if you're going to pretend to circuit switch?

> away from the MN will most likely not result in the real-time behaviour we

This is true...if you design your network poorly and without QoS, or when
things are severely broken in your network.  At all other times it's false if you
have network engineers/architects who know how to design a network.
 
> functionality for the move in the ARs nearest the MN.   

Why are you so attached to telling everyone how to design a network?  I can
guarantee I can design a network with 5 hops to the decision making body that
still makes the same window, and is more efficient.  Frankly, you are limiting
yourself by keeping this TOO CLOSE to the MN...you're not giving it enough
choices...see more on this below.
 
> deterministic behaviour as a primary design objective.  

Unlike circuit switching, real-time packet-switched networks must consider NOT
dropping connections when something nasty happens.  That's why good network
engineers and network architects, with years of experience, design networks that
can adapt to changes nearly instantly.  If you let someone tell the network how
to do its business, you break the network when a circuit goes critical.  I
promise you that if you design a network that relies on everything being "just so"
it will crash and burn the first time Joe Blow forgets to get a digging permit
for his backyard.

 
>  - we must place Real-time bounds on "Routed Clouds"

Wrong, we must use intelligent packet switched clouds (a LOT faster than
routing)

>  - move decision making closer to the MN

Bzzzt.  We want the MN to be able to choose from the APs around it...to do
this efficiently (and cost effectively), we want to move this a few hops from the
AP, so the network can experience some natural aggregation, thus eliminating
the need for every AP to be linked to every possible neighbor, and allowing a
link to die without impeding CT.  Also, we don't want everyone paying tens and
hundreds of thousands of dollars per month for extra bandwidth they don't really
need to be wasting when they decide they don't like this
single-option-only-forever model and the ARs have to act on the behalf of the MNs and query other
ARs.

>  - limit handover messaging to one pre-determined path

Ouch!  And die a miserable death when a backhoe misses?  If we supply multiple
paths (SCTP with very tight tolerances is perfect for this on a QoS bound
network), we can handle hiccups, if we only have one route, we die.  Period.
 
> positive confirmation of every message between the MN and an AR.

Ouch...again, painful.  This is an over-generalization.  See SCTP.  SCTP is
the perfect protocol for this stuff, since that's what it was designed for.  Why
confirm every single message and waste bandwidth and battery, when there's a
better method?

As Phil likes to say...I'm just stirring the pot.  This is not to say you're
not brilliant, Kulwinder, I'm just saying your assumptions are wrong.  FYI, my
background is in operational network engineering and network design, including
real-time packet switching.  I've designed networks that had to deal with these
issues before, and there's more than one way to skin a cat.

Sorry for any burns,
-Jon

-- 
Jonathan "Taz" Mischo                     ph: +1.847.632.4039
Lead Software Engineer                    mn: +1.815.302.3505
Advanced Systems Technology Department    fx: +1.847.435.9970
Network Sector                            em: [email-masked]
Motorola, Inc.                            hp: http://www.refcode.org/taz/