RE: [RPRWG] RE: Evaluation of timeToLive alternatives
Necdet,
> We do have a do not wrap bit in the packet header.
I believe that Anoop was refering to the bit called
"Wrap eligible", "Wrap eligibility" and "WE"
within the same three inches of text. Given that
the specification itself uses many _formal_ names,
its not surprizing that Annop casually used an
informal name for the bit.
> If a packet is bridged packet it should set
> the WE bit right (i.e., do not WRAP).
Members of BAH/flooding felt the flooding bridge
should set WE=1 (e.g., do wrap).
Otherwise, the system will be forced to do a
flush before steering can be invoked, and that
flush has a major performanced impact.
What was the rationale that led you to believe
that WE should be set? If its related to a buggy
duplicate deletion system, isn't it better
to fix the bug than to suggest a workaround?
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: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> Sent: Thursday, June 27, 2002 4:34 PM
> To: Anoop Ghanwani
> Cc: 'Mike Takefman'; David V. James; stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] RE: Evaluation of timeToLive alternatives
>
>
> Anoop,
>
> We do have a do not wrap bit in the packet header. If a packet is bridged
> packet it should set the WE bit right (i.e., do not WRAP).
>
> Thanks.
>
> Necdet
>
> Anoop Ghanwani wrote:
>
> > Mike,
> >
> > Based on the flooding analysis that was presented
> > at the last meeting, source stripping is required
> > regardless of whether one does basic or enhanced
> > bridging.
> >
> > Consider the following bridging example. Without
> > source-stripping, if we're doing wrapping, and a node
> > on the ring dies, the packet will be able to make its
> > way back to the source with a valid TTL (because one
> > of the nodes that would have decremented TTL has
> > disappeared). If we don't have the source address
> > (or some other way to identify the source) in the
> > frame, then the source will pick up that frame as a
> > regular bridged frame, and will learn the source
> > address of the frame as being on the ring, which is
> > incorrect.
> >
> > If we're serious about any kind of bridging, I think
> > we will need a way to explicitly identify at least
> > the source node (even if we don't care about
> > explicitly identifying the destination node).
> >
> > -Anoop
> >
> > > -----Original Message-----
> > > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > > Sent: Thursday, June 27, 2002 1:09 PM
> > > To: David V. James
> > > Cc: Anoop Ghanwani; stds-802-17@xxxxxxxx
> > > Subject: Re: Evaluation of timeToLive alternatives
> > >
> > >
> > > David,
> > >
> > > I hate to give a legalistic response, but here it goes.
> > >
> > > You are assuming facts not in evidence, specifically
> > > that enhanced bridging and not basic bridging is
> > > supported. I am a proponent of basic bridging.
> > >
> > > This algorithm does not work for basic bridging
> > > and hence is flawed. To be clear, the reason it
> > > does not work is that the the SA of a basic bridge
> > > is not present in the frame.
> > >
> > > That being said, I will look at the algorithms
> > > intent and evaluate it once the WG makes a decision
> > > to support enhanced bridging.
> > >
> > > As a side note: Its the Canada Day Long weekend coming
> > > up, so reponse times will be even slower, and the
> > > US long weekend is following so we might have to discuss
> > > futher in a restaurant in Vancouver.
> > >
> > > cheers,
> > >
> > > mike
> > >
> > > "David V. James" wrote:
> > > >
> > > > Mike,
> > > >
> > > > I can see two ways of performing timeToLive timeouts,
> > > > listed below:
> > > > 1) Source-specified.
> > > > a) Before being sent, the source sets:
> > > > frame.timeToLive=dataBase.hopsToDestination
> > > > b) Special frame-dependent/topology-dependent
> > > > stuff happens at the wrap point to prevent
> > > > the estimate in (a) from becoming incorrect.
> > > > c) Potential multidrop endpoints check and
> > > > discardframes based on:
> > > > frame.timeToLive==1
> > > > No error is logged.
> > > > d) Potential duplicates are discarded based on:
> > > > frame.timeToLive==0
> > > > An error is logged.
> > > > 2) Destination-specified.
> > > > a) Before being sent, the source sets:
> > > > frame.timeToLive=255
> > > > b) Potential multidrop endpoints check and
> > > > discard frames based on:
> > > > frame.DSID=myState.DSID
> > > > c) Potential duplicates are discarded based on:
> > > > frame.timeToLive>database.hopsfFromSource&&
> > > > frame.timeToLive!=
> > > > database.hopsFromSource+database.stationsOnRing
> > > >
> > > > I believe that the option (2) has several benefits:
> > > > i) The timeToLive field is processed in all frames.
> > > > ii) The timeToLive always means distance-from-source.
> > > > iii) Error logs are accurate, since timeToLive frames
> > > > are never discarded during steady-state operations.
> > > >
> > > > Can you comments on your perception of these conclusions?
> > > >
> > > > 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
> > > Mike Takefman
> > > > >>Sent: Monday, June 24, 2002 8:17 PM
> > > > >>To: djz@xxxxxxxxxxx
> > > > >>Cc: Anoop Ghanwani; stds-802-17@xxxxxxxx
> > > > >>Subject: Re: [RPRWG] control TTL (the 255-station and
> > > 2000-km issue)
> > > > >>
> > > > >>
> > > > >>
> > > > >>That is a fair request David, and I will do
> > > > >>my best to accomdate it.
> > > > >>
> > > > >>Consider instead a host on your ring. Are you
> > > > >>suggesting that hosts have to behave as
> > > > >>bridges do in terms of learning the mappings
> > > > >>of MAC addresses to bridge IDs?
> > > > >>
> > > > >>If so, I believe you are placing an overly
> > > > >>large burden on hosts, one that no other 802
> > > > >>standard has done.
> > > > >>
> > > > >>Either way, the scenario I pointed out for bridges
> > > > >>(that you deflected by pointing out that I was
> > > > >>assuming a different scenario (which is fair
> > > > >>on your part)) is back. A bridge flooding a non local
> > > > >>packet for the first time, a host inserting a packet
> > > > >>that is off ring, but does not know which bridge
> > > > >>it exits (which in my world happens for every host
> > > > >>packet). If that station goes off the ring, ttl
> > > > >>will be the only mechanism to stop the double
> > > > >>delivery.
> > > > >>
> > > > >>Don't get me wrong, I do like your slick trick,
> > > > >>but your solution is to change the frame format
> > > > >>and add new features, whereas I am working to
> > > > >>fix the currently approved text.
> > > > >>
> > > > >>cheers,
> > > > >>
> > > > >>mike
> > > > >>
> > > > >>
> > > > >>
> > > > >>David James wrote:
> > > > >>>
> > > > >>> Mike,
> > > > >>>
> > > > >>> I believe part of the problem is that you claiming
> > > > >>> something that is not documented does not fail.
> > > > >>> Its hard to argue, as the definition can change
> > > > >>> whenever a failure is illustrated.
> > > > >>>
> > > > >>> Perhaps you should document the TTL stripping
> > > > >>> protocols with some background text and illustrations?
> > > > >>> And, clearly define the synchronizatoin points
> > > > >>> with Discovery, that are often implied.
> > > > >>>
> > > > >>> In my comments to D0.3 I have done this for DSID scoping.
> > > > >>> While this was much easier (since it doesn't have
> > > > >>> all of TTL stripping exceptions and problems), I believe
> > > > >>> its only fair to ask for you to do the same.
> > > > >>>
> > > > >>> Then, we will be able to analysize a problem,
> > > > >>> without the problem statement constantly changing.
> > > > >>>
> > > > >>> Even after that, there is the basic problem that:
> > > > >>> 1) Bidirectional flooding is required for performance.
> > > > >>> 2) A single-stations failure of (1) generates a duplicate
> > > > >>> 3) An multi-station failure of DSID stripping
> > > > >>> generates no duplicates.
> > > > >>>
> > > > >>> Remember, 2/3 is the failure scenario you mentioned
> > > > >>> in previous email. Having agreed, I'm a bit surprized
> > > > >>> this no longer appears to be a concern to you, just
> > > > >>> because the repercussions of that statement changed...
> > > > >>>
> > > > >>> 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
> > > > >>Mike Takefman
> > > > >>> > Sent: Monday, June 24, 2002 1:31 PM
> > > > >>> > To: Anoop Ghanwani
> > > > >>> > Cc: 'djz@xxxxxxxxxxx '; 'stds-802-17@xxxxxxxx '
> > > > >>> > Subject: Re: [RPRWG] control TTL (the 255-station and
> > > 2000-km issue)
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > Anoop,
> > > > >>> >
> > > > >>> > For a protection hierarchy to work all nodes
> > > > >>> > need to know about all failures.
> > > > >>> >
> > > > >>> > I agree with your comment that this needs to be
> > > > >>> > clearly documented as part of the standard.
> > > > >>> > Futhermore, if the WG decides to accept this
> > > > >>> > TTL decrement algorithm it must be documented
> > > > >>> > properly.
> > > > >>> >
> > > > >>> > With regard to your last question / comment.
> > > > >>> > In wrapping, the adjacent nodes can react immediately if
> > > > >>> > they have the highest priority failure. Thereby
> > > > >>> > wrapping will have quicker reaction times to
> > > > >>> > steering. The need to broadcast in the wrapping
> > > > >>> > case is to support the hierarchy. If no hierarchy
> > > > >>> > was supported, then the decision could be completely
> > > > >>> > local. In this case I would still argue that a
> > > > >>> > broadcast of the event was useful for 2 reasons.
> > > > >>> > 1) The same algorithm supports steering which is
> > > > >>> > the default mode
> > > > >>> > 2) The packets that are trapped on the wrong ring
> > > > >>> > will get killed.
> > > > >>> >
> > > > >>> > cheers,
> > > > >>> >
> > > > >>> > mike
> > > > >>> >
> > > > >>> >
> > > > >>> > Anoop Ghanwani wrote:
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > Mike,
> > > > >>> > >
> > > > >>> > > I was trying to say that when a node "unwraps" due
> > > > >>> > > to the ring healing, it can't throw away packets
> > > > >>> > > forever because the ring might wrap at some other
> > > > >>> > > place making it valid for this node to see packets
> > > > >>> > > with the wrap bit set. Therefore a node would have
> > > > >>> > > to set some kind of timer (on the order of RTT) and
> > > > >>> > > only throw away packets for that duration.
> > > > >>> > >
> > > > >>> > > The above discussion was trying to solve the problem
> > > > >>> > > where all nodes do not know about protection events;
> > > > >>> > > only those adjacent to the fault do. If all nodes do
> > > > >>> > > know about protection events, the solution you mention
> > > > >>> > > should work, but it does need to be documented in the
> > > > >>> > > spec.
> > > > >>> > >
> > > > >>> > > [Off topic discussion]
> > > > >>> > > To me, it seemed like the main argument for doing wrapping
> > > > >>> > > is that only nodes adjacent to the fault need to know about
> > > > >>> > > it and react to it. If all nodes do need to know about
> > > > >>> > > a protection event, then it it probably more efficient
> > > > >>> > > for them to use steering.
> > > > >>> > >
> > > > >>> > > -Anoop
> > > > >>> > >
> > > > >>> > > -----Original Message-----
> > > > >>> > > From: Mike Takefman
> > > > >>> > > To: Anoop Ghanwani
> > > > >>> > > Cc: djz@xxxxxxxxxxx; stds-802-17@xxxxxxxx
> > > > >>> > > Sent: 6/24/02 12:07 AM
> > > > >>> > > Subject: Re: [RPRWG] control TTL (the 255-station
> > > and 2000-km issue)
> > > > >>> > >
> > > > >>> > > Anoop,
> > > > >>> > >
> > > > >>> > > wrapping nodes always communicate with every other
> > > > >>> > > node anyway. This is necessary for protection
> > > > >>> > > heirarchy to work. Also, given the broadcast
> > > > >>> > > nature of messages to make steering work in under
> > > > >>> > > 50 ms, I have no concern over all nodes knowing
> > > > >>> > > that all protection events are done and the ringlets
> > > > >>> > > are healed.
> > > > >>> > >
> > > > >>> > > If one waits for the ringlets to be healed
> > > > >>> > > and then killing the packet life is fine. Or
> > > > >>> > > maybe I did not understand your comment.
> > > > >>> > >
> > > > >>> > > mike
> > > > >>> > >
> > > > >>> > > Anoop Ghanwani wrote:
> > > > >>> > > >
> > > > >>> > > > > > The problem with (3), which you seem to advocate,
> > > > >>> > > > > > is the time gap between the wrap action and the
> > > > >>> > > > > > the distribution/settling of the wrap state
> > > information
> > > > >>> > > > > > in other stations. During this time difference, any
> > > > >>> > > > > > and all TTL-strip based frames will be discarded.
> > > > >>> > > > >
> > > > >>> > > > > A good point david, in response please consider
> > > the following
> > > > >>> > > > >
> > > > >>> > > > > Never decrement when on the wrong ring. Once the wrap
> > > > >>> > > > > state is left, kill the packet if the ring id
> > > > >>> > > > > is wrong. THus going into wrap does not cause the
> > > > >>> > > > > packets to be prematurely lost. When leaving wrap
> > > > >>> > > > > the packets will be killed once everyone knows
> > > > >>> > > > > the wrap is over.
> > > > >>> > > >
> > > > >>> > > > Mike,
> > > > >>> > > >
> > > > >>> > > > Does everyone on the ring know when a wrap has occured
> > > > >>> > > > and when it heals? I thought wrapping was a local issue
> > > > >>> > > > and only nodes adjacent to the fault know about it.
> > > > >>> > > > In that case, if the node at which wrapping occurs
> > > > >>> > > > detects a heal, and for some reason doesn't pull a wrap
> > > > >>> > > > packet off, it will continue to circulate forever.
> > > > >>> > > > The node can't be dropping wrapped packets forever
> > > > >>> > > > because the wrap could occur somewhere else at
> > > > >>> > > > which time it would be a legal packet for pass-through.
> > > > >>> > > >
> > > > >>> > > > -Anoop
> > > > >>> > >
> > > > >>> > > --
> > > > >>> > > 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
> > > > >>> >
> > > > >>
> > > > >>--
> > > > >>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
> > >
>
>