[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bandwidth mobility
> -----Original Message-----
> From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
> Of James Kempf
> Sent: Monday, August 20, 2001 1:08 PM
> To: James.Kempf@sun.com; more@psg.com; E.Crane@motorola.com
> Subject: RE: bandwidth mobility
>
>
> Eric,
>
> I agree that the low end will always be attractive to someone. What
> I was trying to say is that I think there are possibilities for
> bandwidth management that are not there right now because of a lack
> of mechanism for intertechnology handover and a lack of support
Just want to point out that inter-technology handover is achievable
for Best Effort data with current Mobile IP standard, rfc2002.
Dana
> in the mobiles. Whether or not software defined radios ever pan
> out is an open question. Intertechnology handover is an easier
> problem to solve I think, but there are still issues. What I'm
> trying to say is that I don't think we should structure the
> requrirements based on an assumption that bandwidth is always
> cheap and limitless, or that it is always constrained and expensive.
> If the currently "hot" 802.11 provider scenerios play out, bandwidth
> will be lots cheaper and more available in certain cases, but
> still limited in others.
>
> jak
>
> >From: Crane Eric-ATCM39 <E.Crane@motorola.com>
> >To: "'James Kempf'" <James.Kempf@sun.com>, more@psg.com
> >Subject: RE: bandwidth mobility
> >Date: Mon, 20 Aug 2001 12:00:46 -0500
> >
> >James,
> >I like your ideas for automated maximum bandwidth. I can
> foresee a user
> >simply defining throughput, latency and cost requirements and
> "leaving the
> >driving to us".
> >
> >But I don't think we can ignore the scenarios when high
> bandwidth simply is
> >not available when and where it is wanted.
> >
> >Please don't forget the other critical resource when mobile -
> battery life.
> >(Other than in a fossil-fueled automobile, of course.) The
> faster bit-rates
> >use up much more power, and the farther you are from a cell
> site, the more
> >power required to maintain your bit rate. For example, my cellphone's
> >battery dies relatively quickly when it is forced to analog mode.
> >
> >So the user must now deal with two dimensions of cost: money and power.
> >(Why does everything always come to money and power?) (o;)
> >
> >I don't think we can design services applications for the best
> any longer.
> >Consider this analogy: Apple Computer designed for the best,
> and dictated
> >the entire computer design. Microsoft was stuck with a computer design
> >implemented by the lowest bidder. Microsoft had to start
> abstracting the
> >design immediately, but in so doing, became excellent
> architects (business
> >practices aside).
> >
> >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: James Kempf [mailto:James.Kempf@Sun.COM]
> >Sent: Monday, August 20, 2001 10:40 AM
> >To: tjc@lacunanet.net; dblair@cisco.com; E.Crane;
> more@psg.com; Chris.Burke
> >Subject: RE: bandwidth mobility
> >
> >Chris,
> >
> >I think this really depends on the wireless radio protocol. People
> >are talking about 50 Mbps for 802.11 and 100 Mbps for 802.16
> (Hyperlan).
> >There are tradeoffs, viz speed of movement and number of mobile
> >nodes per cell, but I don't think it necessarily follows that wireless
> >bandwidth will be limited all the time. One could imagine a smooth
> >intertechnology handover mechanism that allowed more bandwidth
> >on additional radio protocols as the user slowed down or fewer
> >mobile nodes were in the cell. Combined with a software defined
> >radio, so that the intertechnology handover did not require separate
> >physical interfaces in the mobile device, the result would scale
> >bandwidth to availability and user movement.
> >
> > jak
> >
> >>From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
> >>To: "'tim clifford'" <tjc@lacunanet.net>, "Dana L. Blair"
> ><dblair@cisco.com>,
> >Crane Eric-ATCM39 <E.Crane@motorola.com>, more@psg.com
> >>Subject: RE: bandwidth mobility
> >>Date: Mon, 20 Aug 2001 00:13:15 -0500
> >>
> >>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
> >>> > > >
> >>> > > >
> >>> >
> >>> >
> >>>
> >>
> >>
>
>