[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 tim clifford
> Sent: Monday, August 20, 2001 11:28 PM
> To: Dana L. Blair; James Kempf; more@psg.com; E.Crane@motorola.com
> Subject: RE: bandwidth mobility
>
>
> all
> ok, now i think i've finally lost the thread of where the
> requirement lies.
> as a quick, high level statement (i'll try to do a better job or please
> someone save me ;-)
> 1. at some general level the "system" (subscriber, mobile device, access
> net, mobile core, peer networks and applications) must have a
> way of being
> aware of available bandwidth for a subscriber at any time.
> 2. the elements of the system should have a way of exchanging
> this status
> information
> 3. the elements of the system should have a way of reacting to available
> bandwidth and changes in what's available
> 4. we probably need to define other metrics beyond bandwidth
> (e.g., delay,
> jitter, loss?)
Implementation of the RSVP protocol between network elements satisfies the
requirements you have just stated.
Applications should use an RSVP API provided by the host
operating system whether client or server. So the source
of RSVP requests are hosts. Windows supports RSVP API. I don't
know about other OS's.
Switches and Routers within the network react to the requests
to (a) authorize an application to access the network with
a certain QoS capability, and (b) manage bandwidth over congested
links by either (b.1) avoiding congestion or (b.2) prioritizing
packets over the congested link.
Avoiding congestion can be done by over-provisioning the network
or denying RSVP requests that would congest the network.
Prioritizing traffic can be done with queuing out the output
interfaces of hosts, switches, and routers.
thanks,
Dana
>
> a few observations
> 1. much of this is implied in the architectures out there, at
> least in mwif
> there are policy managers, resource managers, etc. that seem to have
> bandwidth mobility in mind as one type of capability to
> support. however,
> its not clear to me that the architectures necessarily support the many
> ramifications of 1-4 above
> 2. Operators may want to think about what this really means to
> them. i'm
> not sure the subscriber or web site, for example, care about
> the intervening
> services a great deal, they might just measure actual goodput and react
> accordingly
> 3. this discussion of cookstoves is interesting but i'm not sure how it
> affects the requirement. if in fact i can't cook a turkey on a
> camp stove
> then various participants need to recognize the change and react
> accordingly - maybe terminate the session and influence the bill
> accordingly.
> 4. finally, i can't resist, imho the point of mobility is that available
> wireless bandwidth per user will often be INFINITE compared to available
> wired bandwidth per user, i.e., i'm mobile and don't have the option of
> stopping, waiting for that brilliantly architected (;-)
> operating system,
> windows, to boot up, and connecting to a higher speed wlan or
> wired port.
> so the ratio of some available bw to none is infinity last time
> i checked
>
> > -----Original Message-----
> > From: owner-more@ops.ietf.org
> [mailto:owner-more@ops.ietf.org]On Behalf
> > Of Dana L. Blair
> > Sent: Monday, August 20, 2001 7:13 PM
> > To: James Kempf; more@psg.com; E.Crane@motorola.com
> > Subject: 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
> > > >>> > > >
> > > >>> > > >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
>
>