Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt
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:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Thursday, July 12, 2018 11:15 AM >> To: Anima WG >> 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 objectiv
Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt
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:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter > Sent: Thursday, July 12, 2018 11:15 AM > To: Anima WG > 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? > >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. > > 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. 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? Best regards, Bing > > > Regards >Brian > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
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. 2. We need to specify that a new session_id is generated for each new M_UNSOLDSYNCH message. 3. Is this available for any synchronization objective, or do we need to add a new flag bit? >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. > 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.) Regards Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
