[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bandwidth mobility
Dana,
My understanding from talking with IESG members is that use of RSVP is being
discouraged except for limited cases. Have you heard anything to
this effect?
jak
>From: "Dana L. Blair" <dblair@cisco.com>
>To: "tim clifford" <tjc@lacunanet.net>, "James Kempf" <James.Kempf@Sun.COM>,
<more@psg.com>, <E.Crane@motorola.com>
>Subject: RE: bandwidth mobility
>Date: Tue, 21 Aug 2001 07:16:53 -0400
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
>Importance: Normal
>
>> -----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
>> > > >>> > > >
>> > > >>> > > >
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > > >>
>> > > >>
>> > >
>> > >
>> >
>>
>>
>