[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bandwidth mobility
I think they mean basically "not across the Internet." We can
ask Allison for a clarification, QoS is her specialty area.
jak
>From: "Dana L. Blair" <dblair@cisco.com>
>To: "James Kempf" <James.Kempf@sun.com>, <tjc@lacunanet.net>, <more@psg.com>,
<E.Crane@motorola.com>
>Subject: RE: bandwidth mobility
>Date: Tue, 21 Aug 2001 12:06:46 -0400
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
>
>> -----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
>> >> > > >>> > > >
>> >> > > >>> > > >
>> >> > > >>> >
>> >> > > >>> >
>> >> > > >>>
>> >> > > >>
>> >> > > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>> >
>>
>