Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] protection messages




This is an interesting and cute discussion.  However, I thought that one of
the reasons that 802.17 got chartered was that these other protocols were
not able to guarantee timely delivery!  Jim Mollenauer is right on when he
states that the exponential backoff provides stability, rather than assuring
timeliness.  I believe that Anoop has a serious question that deserves a
thoughtful answer.  In fact, I believe we need to thoughtfully and seriously
consider all questions and concerns raised if we are to make real progress
in developing a superior standard that will be highly successful in the
market.

Best regards,

Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle     Raleigh, NC 27615
Phone: 919 848-6773       Mobile: 919 810-7816
email: rdlove@xxxxxxxx          Fax: 208 978-1187
----- Original Message -----
From: "Jim Mollenauer" <jmollenauer@xxxxxxxxxxxxxxxxxxxxx>
To: "Mike Takefman" <tak@xxxxxxxxx>
Cc: "Anoop Ghanwani" <anoop@xxxxxxxxxxxxxx>; "'Daniel Zhu'"
<dzhu@xxxxxxxxx>; "'Necdet Uzun'" <nuzun@xxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Friday, May 24, 2002 10:51 PM
Subject: Re: [RPRWG] protection messages


>
> Not to mention 802.11, the real ether net.  It does CSMA but not CD.
> Exponential backoff is there in both cases to provide stability under high
> offered load rather than to assure timeliness.
>
> Jim
>
> Mike Takefman wrote:
>
> > CSMA-CD comes to mind.
> >
> > he he he,
> >
> > mike
> >
> > Anoop Ghanwani wrote:
> > >
> > > Daniel,
> > >
> > > The exponential backoff is what I don't like.  I would
> > > rather see it sent at a steady rate, or just transmitted
> > > reliably so that there is no constant refresh.
> > >
> > > Are there any protocols that use a similar exponential
> > > backoff to guarantee timely delivery?
> > >
> > > -Anoop
> > >
> > > > -----Original Message-----
> > > > From: Daniel Zhu [mailto:dzhu@xxxxxxxxx]
> > > > Sent: Friday, May 24, 2002 11:19 AM
> > > > To: Anoop Ghanwani
> > > > Cc: 'Necdet Uzun'; 'stds-802-17@xxxxxxxx'
> > > > Subject: Re: [RPRWG] protection messages
> > > >
> > > >
> > > > Anoop,
> > > >
> > > > I believe, in the current RPR draft, protection message will
> > > > be broadcast periodically every 1 second in steady state.
> > > > During period of changes, protection message will be sent
> > > > much more frequently with a back off scheme up to 1 second.
> > > >
> > > > Is there something missing here?
> > > >
> > > > Daniel
> > > >
> > > > Anoop Ghanwani wrote:
> > > >
> > > > > Necdet,
> > > > >
> > > > > Thanks for pointing this out.  Per the current draft,
> > > > > Type B's aren't sent that often (1/10-th the rate of
> > > > > Type A's) and so it's possible that they can be
> > > > > sourced in software.
> > > > >
> > > > > Anyway, let's assume for now that we absolutely had
> > > > > to keep protection and fairness separate.  How would
> > > > > you recommend that we address the issue of timely
> > > > > delivery of the protection notification message?
> > > > >
> > > > > I see only 2 possibilties:
> > > > >
> > > > > - Periodic link status broadcasts (regardless of whether
> > > > >   the link is up or not).
> > > > >
> > > > > - Hop-by-hop reliable broadcast when the link status
> > > > >   changes.
> > > > >
> > > > > I'm OK with either.  Can you think of any other ways
> > > > > to do this?
> > > > >
> > > > > -Anoop
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> > > > > > Sent: Thursday, May 23, 2002 7:13 PM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: 'stds-802-17@xxxxxxxx'
> > > > > > Subject: Re: [RPRWG] protection messages
> > > > > >
> > > > > >
> > > > > > Anoop,
> > > > > >
> > > > > > Type B fairness message is generated by Fairness Control Unit
(in
> > > > > > hardware) and sent to client, whereas protection messages are
> > > > > > generated
> > > > > > MAC control unit (which is implemented in software) and
> > > > multicast to
> > > > > > other MACs' control units. Combining them is the worst
> > > > that can happen
> > > > > > (HW vs SW, microsecond time frame vs millisecond time frame
etc.)
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Necdet
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > > I had a comment that expressed concern about the delivery
> > > > > > > of protection notification messages.
> > > > > > >
> > > > > > > The way things are defined in D0.2, the messages are
> > > > > > > neither reliable nor periodic.  There are no
> > > > > > > acknowledgments, so we are never sure that all nodes
> > > > > > > have seen the protection notification message.
> > > > > > > Sending special protection messages periodically
> > > > > > > increases the overhead (but even that is not specified).
> > > > > > > Why can't we piggyback the protection notification
> > > > > > > onto Type B fairness messages since they are required
> > > > > > > to be sent frequently in any case (typically more
> > > > > > > frequently than 1 msec)?
> > > > > > >
> > > > > > > The ad hoc's response to my comment says that Type B's
> > > > > > > are optional.  This is not true.  Sending of both Type A
> > > > > > > and Type B messages is mandatory per D0.2 and there have
> > > > > > > been no comments to change that behavior.
> > > > > > >
> > > > > > > -Anoop
> > > > > > > --
> > > > > > > Anoop Ghanwani - Lantern Communications - 408-521-6707
> > > > > >
> > > >
> >
> > --
> > Michael Takefman              tak@xxxxxxxxx
> > Manager of Engineering,       Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-254-3399       fax: 613-254-4867
>