Re: [Anima-signaling] Session IDs in relayed messages (and the Initiator field)

["Liubing (Leo)" <[e-mail]>]

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Tuesday, January 12, 2016 3:44 AM
> To: Liubing (Leo)
> Cc: Anima signaling DT
> Subject: Session IDs in relayed messages (and the Initiator field)
> 
> Bing,
> 
> > 2. Section 3.3.5.1 Flooding
> >> If it receives a multicast Flood message on a given interface, it MUST
> relay it by re-issuing a Flood message on its other interfaces. The relayed
> message MAY have a different Session ID.
> > [Bing] Is there any concern that different Session IDs for the same flood
> message?
> > My rough idea is that the same Session ID might be beneficial to identify
> the flooded message. E.g., the interface could easily examine whether the
> message had been relayed once.
> 
> That was what I thought until I started writing the code. It gets very
> complicated because of the "birthday paradox" risk of duplicate Session IDs.
> You have to track the pair (Session ID, initiator address). That's why I
> proposed adding an 'initiator'
> to several messages (see the discussion with Carsten attached below). The
> issue is just the same for flood and discovery.
> 
> Relying on the loop count to terminate multicast loops is much simpler.
> 
> There are only two ways to create a loop: a bad physical topology, which will
> create problems for everybody, not just GRASP, or a faulty GRASP
> implementation that relays multicasts back to the same interface, which will
> be detected during debugging.
> So I think the loop count is enough protection.
> 
> If we accept that, then using a new Session ID each time a multicast is
> relayed to a new link is fine. We do lose the knowledge of which GRASP node
> originally generated the Discover or Flood.
> 
> What do you think? There would be a few more changes to the text for this.
> I have two versions of the Python code already, with or without the 'initiator'
> field, and they both seem to work with identical results.

[Bing] As you said, it depends on whether we accept loop count is enough. I personally don't have a solid opinion on this. 
I think it's ok to post the 02 as it is, and maybe mark it as a new open question?

Best regards,
Bing

> Regards
>    Brian
> 
> On 11/01/2016 08:38, Brian E Carpenter wrote:
> > On 11/01/2016 07:52, Brian E Carpenter wrote:
> >> Hi Carsten,
> >> On 11/01/2016 02:38, Carsten Bormann wrote:
> > ...
> >>> More odd to me is that the session-id only makes sense in
> >>> conjunction with the initiator, but the latter is not always given.
> >>> I can't quite make rhyme and reason out of when it's there and when
> >>> not.  Maybe that should be explained in the text (beyond what's in
> >>> 3.6), including how the initiator is implied when not present in the
> >>> message (source IP address of UDP packet?).
> >>
> >> The issue only arises at all because of the need to relay discovery
> >> and flood packets from one interface to another. In all other cases
> >> the source address of the packet is fine for disambiguating sessions.
> >> And in my implementation, the issue doesn't even arise for relayed
> >> discovery messages, because it proved easier to launch a new
> >> discovery session than to propagate the old one.
> >>
> >> You know, I'm going to look at my code again. If I can do the same
> >> trick for flood messages when they are relayed, we just wouldn't need
> >> the stupid initiator field at all.
> >
> > I had to add three lines of code to the relay function to do this.
> > So I now propose to remove the 'initiator' field from the messages
> > where I added it (and add the necessary clarifications about using the
> > source IP address). That will be a straightforward change to the -02D
> > draft that I sent yesterday, so co-authors, please let me know what
> > you think ASAP.
> >
> > Thanks Carsten, this helped a lot.
> >
> >     Brian
> >