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-bounces@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Thursday, July 12, 2018 11:15 AM
>> To: Anima WG <anima@ietf.org>
>> 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
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 