RE: bandwidth mobility

[Crane Eric-ATCM39 <E.Crane@motorola.com>]

You cannot cook a turkey on a camp stove (at least not very easily.)
Similarly, you cannot run high bandwidth applications on low bandwidth
appliances.  So mobility of high bandwidth applications across varying
bandwidth capabilities doesn't really make sense in this context.

However, I can boil water on a camp stove.  So I think the practical
mobility problem is how to be able to boil water on any ol' stove.  Things
like pages, notifications, chat groups, stock tickers, etc. should be able
to flow over any ol' bandwidth.

One more thing about portable devices, just like camp stoves, they have
limited fuel.  You can boil water, but not much.  So some things you may
choose to eat cold to save fuel.  A key capability of a portable device may
be to define what you want to eat HOT.


Eric K. Crane 
Motorola Global Telecom Solutions Sector 
Advanced Technology 
1501 W. Shure Dr., Arlington Heights, IL, 60004, USA 
847-632-2855 
e.crane@motorola.com 
Pager: 1338881@skytel.com 


-----Original Message-----
From: tim clifford [mailto:tjc@lacunanet.net] 
Sent: Wednesday, August 01, 2001 11:07 AM
To: Baba S; more@psg.com
Subject: RE: 

actually i think you're right on point.

i suspect that the operator's don't yet know how they'll deal with a
possibly growing community of independent isp's, or possibly a smaller
community of clearinghouses/service providers like wayport, hereuare,
megabeam, mobilestar, gric and ipass (the latter two when they start
offering wireless lan access).  its a great opportunity but also possibly
the worst nightmare.

so i'm not sure we'll get a requirement but we might try to generalize
mobility between domains and see where we go.

a random thought is that it would seem we'll have a more severe transition
issue when one moves from a 11 Mbps lan/probably connected to DSL or cable
or high bw facilities and then move to some lower speed mobile operator
provided service.  it would seem that lots of applications would want to
adjust.  effectively this is a migration from fixed to mobile, not just one
mobile to another.

tim

> -----Original Message-----
> From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
> Of Baba S
> Sent: Wednesday, August 01, 2001 11:56 AM
> To: more@psg.com
> Subject: Re:
>
>
> Tim,
>
> Though I may be apart from your original points,
> I'm also interested in Operator's view about for user to cross
> (or handoff) between administrative domain in more general sense,
> that is even in case of using the same terminal.
>
> I guess it can be OK if the movement occurs among operators which
> have a contract with the same "broker" or clearing house.
> And I think this scenario could be happen soon, since
> an operator/WISP which has only one 802.11AP inside of his/her
> coffee shop and needs a help of cellular service provider to
> support roaming PDA is appearing.
>
> Operator's requirement on this may still be "quick and secure
> handoff"?
>
> Regards,
>
> baba//
>
>
> From: "tim clifford" <tjc@lacunanet.net>
> Subject: RE:
> Date: Wed, 1 Aug 2001 10:56:26 -0400
>
> > agreed, actually i think you're on to an interesting requirement about
> > awareness of network status, current connection and user authorization.
> > however its something i think we need to tease out a bit
> > - its not clear this is an operator requirement or at least not
> exclusively.
> > - it seems one would almost certainly be jumping between administrative
> > domains, it would be interesting to hear about how operators
> would see such
> > a need as it carries interesting competitive issues
> > - i'm always a bit quesy about videophone requirements, its just never
> > panned out as anything more than a novelty.
> > - it would be interesting to restate this scenario in a generalized way,
> > i.e., not audio to video but low bit rate, low packet loss...,
> to high bit
> > rate, higher packet loss, etc. and see if we can create a
> broader model for
> > this "mobility across network and administrative boundaries"
> requirement.
> > has it already been defined?  seems to me MWIF has an implicit
> assumption
> > for such a scenario but i'm not sure we've ever gone throught
> the mechanics
> >
> > tim
> >
> >