[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bandwidth mobility
> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Tuesday, August 21, 2001 11:54 AM
> To: tjc@lacunanet.net; James.Kempf@Sun.COM; more@psg.com;
> E.Crane@motorola.com; dblair@cisco.com
> Subject: 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?
If by limited cases, they mean only use RSVP over links which
are congested, then I agree. Certainly a cellular data connection
can be congested because of its low bit rate.
What limited cases is the IEST referring to ?
thanks,
Dana
>
> 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
> >> > > >>> > > >
> >> > > >>> > > >
> >> > > >>> >
> >> > > >>> >
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
> >>
> >
>