RE: bandwidth mobility

["tim clifford" <tjc@lacunanet.net>]

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
> >   > >
> >   > >
> >
> >
>