[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: bandwidth mobility



My understanding of the camp stove analogy is that available wireless bandwidth per user will always be RELATIVELY scarce (by about two orders of magnitude) compared to available wired bandwidth per user. Therefore, whatever happens to bandwidth in the future, applications designed to operate near the limits of the "wired" internet will ALWAYS be disadvantaged when running over wireless links.

However, for some applications, good is good enough. You can do a lot in 128kbps - 2Mbps of personal bandwidth. Just not as much as you can do in 2Mbps - 100Mbps of personal bandwidth.

Chris Burke
Motorola Internet Software and Content Group

-----Original Message-----
From: tim clifford [mailto:tjc@lacunanet.net]
Sent: Friday, August 17, 2001 12:20 PM
To: Dana L. Blair; Crane Eric-ATCM39; more@psg.com
Subject: RE: bandwidth mobility


i've been wanting to address the turkey on a camp stove thing, and now the
rsvp comments

first i'm not sure what you mean by a low bw appliance, sure a mobile phone
with a few lines of b&w text is a low bandwidth appliance but that seems to
be only part of the story.  a phone may never be a great high bw appliance
but a few thoughts change that notion
- the phone may act as the equivalent of a modem to a high bw appliance
- the ability to deliver high bw to mobile devices will change the phone, or
the appliance
- the applications will emerge to demand high bw over camp stoves.

i really don't want to start dreaming about applications but i don't think
its hard to start dreaming up applications that would use a small screen
(i.e., mobile phone) and more bw. i'd love to be able to get live streaming
traffic cameras while i'm driving and i honestly believe the millions of
people dreaming up applications will come up with better stuff.

so i don't understand the camp stove analogy, unless you're trying to say
that today's mobile phones don't need high bw, to which i of course agree.

as for rsvp, a question.  conventional knowledge that i understand says that
its difficult to manage rsvp to scale.  do you have any ideas about how well
an rsvp-based mechanism would scale to the populations anticipated?

tim

> -----Original Message-----
> From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
> Of Dana L. Blair
> Sent: Monday, August 13, 2001 11:30 AM
> To: Crane Eric-ATCM39; more@psg.com
> Subject: RE: bandwidth mobility
>
>
> >   -----Original Message-----
> >   From: owner-more@ops.ietf.org
> [mailto:owner-more@ops.ietf.org]On Behalf
> >   Of Crane Eric-ATCM39
> >   Sent: Wednesday, August 01, 2001 2:18 PM
> >   To: more@psg.com
> >   Subject: RE: bandwidth mobility
> >
> >
> >   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.
>
> Most "high" bandwidth applications used today (video for example)
> can accomodate low or high bandwidth connections.  Most video
> websites today allow the user to tell the application via
> a mouse click what kind of connection they have.
>
> So, even without wireless, Video applications run across
> varying bandwidth capabilities.
>
> The problem that exists for wired and wireless is how can
> an application programmatically discover the bandwidth capability
> of a network.  The RSVP protocol standardized by the IETF
> can accomplish this since it allows an application to request
> a certain bandwidth, if it is denied then it can request
> a lower bandwidth.  No more Modem, DSL, Ethernet widgets
> on the web page for the user to click.
>
> >
> >   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.
>
> Mobile IP allows this today.
>
> >
> >   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.
>
> RSVP allows an application to select hot or cold.
>
> Dana
>
> >
> >
> >   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
> >   > >
> >   > >
> >
> >
>