Re: [RPRWG] protection messages
Devendra,
handled by the MAC means different things to different people
in particular standard component vendors.
It is not obvious to me that everything that an RPR MAC needs
to implement to be fully compliant resides in a single piece
of silicon.
mike
Devendra Tripathi wrote:
>
> Mike,
>
> I would presume that the protection message would be handles by MAC (even
> though CPU may construct it) and only upon detection of abnormality CPU
> would be interrepted.
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions (India) Pvt Ltd.
> (Subsidiary of CoVisible Solutions Inc.)
> Pune, India
> Tel: +91-20-433-1362
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Mike Takefman
> Sent: Tuesday, May 28, 2002 6:40 AM
> To: David V. James
> Cc: Leon Bruckman; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] protection messages
>
> Gentlemen,
>
> IMO, the issue with 10ms messages is not the overhead on the media
> but the overhead on the local processor in receiving the
> interrupts.
>
> Recall the presentations from Denny Gentry when discussing
> large frames the big issue with efficiency was not about
> efficiency on the network (which is a bit of an issue) but
> more the efficency for hosts who have to process the interrupts
> on the receipt of the messages.
>
> cheers,
>
> mike
>
> "David V. James" wrote:
> >
> > Leon,
> >
> > I disagree with Daniel, in that re-transmitting a protection message
> > at a 10ms rate seems like a fine idea. My rough estimate seems to indicate
> > that this is a .1% overhead, which is insignificant waste of bandwidth.
> >
> > Too many engineers get this idea that any waste is an unnecessary waste,
> > and thus unnecessarily complicate the protocols in the name of efficiency.
> >
> > If you are REALLY concerned about a .1% overhead, then I can show you a
> > way of using SSID and DSID (without MAC addresses) for router-to-router
> > communications. That savings is much more, with a lessor impact on
> > robustness.
> >
> > DVJ
> >
> > David V. James, PhD
> > Chief Architect
> > Network Processing Solutions
> > Data Communications Division
> > Cypress Semiconductor, Bldg #3
> > 3901 North First Street
> > San Jose, CA 95134-1599
> > Work: +1.408.545.7560
> > Cell: +1.650.954.6906
> > Fax: +1.408.456.1962
> > Work: djz@xxxxxxxxxxx
> > Base: dvj@xxxxxxxxxxxx
> >
> > >>-----Original Message-----
> > >>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > >>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Leon Bruckman
> > >>Sent: Monday, May 27, 2002 11:03 AM
> > >>To: 'stds-802-17@xxxxxxxx'
> > >>Subject: RE: [RPRWG] protection messages
> > >>
> > >>
> > >>
> > >>I agree with Daniel, continuously re-transmitting the protection message
> > >>every 10 msec (or less !) doesn't seem to be a good strategy, it is just
> a
> > >>waste of bandwidth to deal with a low probability case. I don't know a
> > >>packet transport technology that uses such a scheme.
> > >>
> > >>RPR must be able to protect even if a protection message is lost while
> > >>passing through the ring, but does it have to do it within 50
> > >>msec ? if the
> > >>answer is a strong yes, then what if two protection messages are
> > >>lost ? For
> > >>a 2000Km ring the RTT is ~10msec, so after loosing 3 protection
> > >>messages (10
> > >>msec each) the protection time will violate the 50 msec requirement, so
> no
> > >>point in sending more than 3-4 messages anyway.
> > >>
> > >>My point is that we must set a boundary and make the RPR standard meet
> the
> > >>50 msec requirement while within the defined conditions, with minimum
> > >>bandwidth waste.
> > >>The backoff strategy seems a good technical compromise. With the values
> > >>defined in the Draft it can support 50msec protection for a 2000Km ring,
> > >>even if the first and second protection message are lost, and if more
> > >>protection messages are lost it can still provide protection but in this
> > >>case in more than 50msec.
> > >>
> > >>Leon
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Daniel Zhu [mailto:dzhu@xxxxxxxxx]
> > >>Sent: Monday, May 27, 2002 4:47 PM
> > >>To: Anoop Ghanwani
> > >>Cc: 'stds-802-17@xxxxxxxx'
> > >>Subject: Re: [RPRWG] protection messages
> > >>
> > >>
> > >>
> > >>I do agree that we should try to find any way possible to
> > >>improve the reliability and timeliness of the delivery of
> > >>protection status change notification. That is why, for
> > >>example, protection message has (or at least used to has)
> > >>a separate mode value 4 so that it can get priority
> > >>treatment by the RPR MAC over other control packet
> > >>types. One of the goals of RPR protection protocol is to
> > >>provide reliable mechanisms for sub-50ms protection
> > >>switching. That requires the delivery of protection status
> > >>change notification to all nodes on the ring within 50ms.
> > >>However, re-transmitting protection message at such
> > >>high rate all the time (in particular, beyond 50ms after
> > >>protection status changes) will not help to achieve this
> > >>goal, and just adds extra overhead to the protocol.
> > >>
> > >>Thanks,
> > >>
> > >>Daniel
> > >>
> > >>Anoop Ghanwani wrote:
> > >>
> > >>> Daniel,
> > >>>
> > >>> I'd say 10 msec or less.
> > >>>
> > >>> -Anoop
> > >>>
> > >>> > -----Original Message-----
> > >>> > From: Daniel Zhu [mailto:dzhu@xxxxxxxxx]
> > >>> > Sent: Friday, May 24, 2002 3:43 PM
> > >>> > To: Anoop Ghanwani
> > >>> > Cc: 'Necdet Uzun'; 'stds-802-17@xxxxxxxx'
> > >>> > Subject: Re: [RPRWG] protection messages
> > >>> >
> > >>> >
> > >>> > Anoop,
> > >>> >
> > >>> > I don't think hop-by-hop relay of protection message is
> > >>> > any more reliable than broadcast. Packet could potentially
> > >>> > be lost at any of the hops. How often do you recommend
> > >>> > to re-broadcast protection message?
> > >>> >
> > >>> > Daniel
> > >>> >
> > >>> > 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
--
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