Hi Bing, Responses in line:
On 12/07/2018 15:58, Liubing (Leo) wrote: > Hi Brian, > > Thanks for your comments! Since this new version proposed some protocol > extensions, we really need review from GRASP perspective. Please see reply > inline. > >> -----Original Message----- >> From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter >> Sent: Thursday, July 12, 2018 11:15 AM >> To: Anima WG <[email protected]> >> Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt >> >> Hi, >> >> I haven't had time to carefully read sections 1-5, but I think their general >> message is fine. Here are some first comments on section 6, the proposed >> GRASP extensions: >> >>> In fragmentary CDDL, a Un-solicited Synchronization message follows >>> the pattern: >>> >>> unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, >>> objective] >>> >>> A node MAY actively send a unicast Un-solicited Synchronization >>> message with the Synchronization data, to another node. This MAY be >>> sent to port GRASP_LISTEN_PORT at the destination address, which >>> might be obtained by GRASP Discovery or other possible ways. The >>> synchronization data are in the form of GRASP Option(s) for specific >>> synchronization objective(s). >> >> Three comments on that: >> >> 1. For this to work, the receiving node must always be listening for a new >> TCP >> session on that port. So that means a new API function >> (listen_unsolicited?) and of course either a separate thread or an additional >> entry in the event loop. Not a problem, just an implementation comment. > > [Bing] I believe so, another API should be needed. > >> 2. We need to specify that a new session_id is generated for each new >> M_UNSOLDSYNCH message. > > [Bing] Yes, detailed behavior will be completed in the next version. > >> 3. Is this available for any synchronization objective, or do we need to add >> a new >> flag bit? > > [Bing] Ideally, I think the possibility should be open for any > Synchronization Objective. But personally I prefer to avoid revising the base > protocol as much as possible (e.g. changing the flag bits). How about we just > assume any Sync Obj could be Un-solicited, would there be any harmfulness? I think it's fine. Effectively it just means this is a read-only objective, whether flooded, synchronized on request, or unsolicited. The NEG flag means it is read/write, by negotiation. >>> The selective flood option encapsulates a match-condition option >>> which represents the conditions regarding to continue or discontinue >>> flood the current message. >> >> To be clear, the match is evaluated in every node, and the flooded objective >> is >> dropped if there is a match? So we save on storage, not on processing. > > [Bing] Yes, it's even more flexible that we can define either "something > matched" or "something not matched" to let the node drop the flooded messages. > Save on storage is surely one benefit, but I think maybe the more beneficial > is saving on network traffic, especially in an constrained environment. And > also on security benefit, that some sensitive informative won't be propagated > too far. Yes, you can reduce relayed (forwarded) flooding, that's true. > >>> 6.5 Publishing Objective Option >>> >>> In fragmentary CDDL, a Publish Objective Option follows the pattern: >>> >>> publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name >>> = PUBLISH >>> objective-flags = 2 >>> loop-count = 2 >>> pubobj = text >>> >>> This option MAY be included in GRASP M_Synchronization, when >>> included, it means this message is for a publish of a specific object >>> data. >> >> Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub bus >> does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) > > [Bing] Currently, we follow the principle that Sub/Pub should be a more > strict transaction model. Un-solicited Pub seems too arbitrary. > But we can leave it as an open question, let's see if we could find some > scenarios that really benefited from un-solicited Pub. In any case this would be easy to add later, if found useful. > > Btw, we actually cared more about another question regarding to Sub/Pub. From > semantic perspective, we actually preferred to make Sub/Pub as new messages, > rather than current objective extension. But later we thought we should > utilize the base protocol as much as possible, so we chose objective > extension. May I ask your opinion on this? I think that's a good choice. In fact it gives you more flexibility at the ASA level, without changing the GRASP core. (In the same way, we could define the bulk transfer mechanism at the objective level, with literally zero changes needed in the protocol definition. I believe I could code a simple version of pub/sub tomorrow, without touching the basic GRASP code, except that I have to catch a plane.) Regards Brian > > Best regards, > Bing > >> >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
