Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt

[Brian E Carpenter <[e-mail]>]

Hi,

Sorry about the delayed response, coming just between summer holidays where I live and New Year holidays where Bing lives ;-). Some comments in line.

On 18-Dec-19 23:54, Liubing (Leo) wrote:
> Hi Brian,
> 
> Thanks for the detailed review. Please see my replies inline.
> 
>> -----Original Message-----
>> From: Anima [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Monday, December 16, 2019 12:21 PM
>> To: Anima WG <[e-mail]>
>> Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt
>>
>> Hi,
>>
>> I think this is a useful extension of the basic autonomic infrastructure. Here are
>> some comments and questions on the GRASP part of the draft. I'd be interested
>> in the authors' comments.
>>
>>> 5.1 Realizing Instant P2P Transmission
>>>
>>>    This could be a new message in GRASP. In fragmentary CDDL, an Un-
>>>    solicited Synchronization message follows the pattern:
>>>
>>>       unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id,
>>>       objective]
>>
>> I suggest simply calling this M_PUSH (but see later comments).
> 
> [Bing] Personally I'm ok with it. "PUSH" sounds more intuitive.

[Brian] OK. But I still have some questions, see later.

> 
>>>    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,
>>
>> That port is normally tied up with multicast reception. But since we have a
>> SUBSCRIBE mechanism below, the question of the port can be resolved at
>> SUBSCRIBE time. There must be a listener process for this port, of course.
> 
> [Bing] The M_PUSH is not bind with SUBSCRIBE. It could be sent standalone. Is it possible we could specify that GRASP_LISTEN_PORT MUST monitor M_PUSH as well?

[Brian] Theoretically, yes, but in that case why don't we simply use M_FLOOD as already defined but sent to a unicast UDP destination? Obviously in this case there will be no flood relaying but otherwise the existing mechanisms for receiving a flood message can be reused. That has the advantage that M_FLOOD can carry more than one objective if required.

(By the way, because M_FLOOD is unacknowledged it's easy to do with UDP. M_REQ_SYNCH and M_SYNCH are easy to do with TCP, but UDP is more complicated because the messages have to be matched to the right session, which is automatic with TCP.)

>  
>>>    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).
>>
>> One objective per message is much simpler to implement. If not, this becomes
>> more like a "unicast Flood". If you want that, we could define the syntax
>> precisely like M_FLOOD.
> 
> [Bing] I tend to agree from practical perspective. However, I'm not very sure whether it's necessary to close the little flexibility of multiple objective in one message?

[Brian] As noted above, when I think about coding this, it actually seems simpler to copy M_FLOOD.

>>> 5.2 Realizing Instant Selective Flooding
>>>
>>>    Since normal flooding is already supported by GRASP, this section
>>>    only defines the selective flooding extension.
>> ....
>>>    The action means, when the match rule applies, the current device
>>>    just continues flood or discontinues.
>>
>> Please remember that a normal M_FLOOD has two aspects for a node that
>> receives it. First, the node stores the objectives delivered in its own flood cache.
>> Second, *if* it is a relay node (with interfaces to more than one link within the
>> AN, such as a router) it relays a copy of the M_FLOOD to its AN neighbors,
>> subject to anti-looping rules.
>>
>> 1) If the result of the match is "continue" I assume that the node does exactly
>> what it does with a normal flood, i.e. caches the received objectives and if it is a
>> relay, it relays the flood to its neighbors.
> 
> [Bing] Exactly.
> 
>> 2) If result of the match is "discontinue" I assume the node does not cache the
>> flooded objectives.
> 
> [Bing] The text doesn't explicitly specify the cache behavior. But I share the same opinion that the node does not cache when the match is "discontinue".
> 
>> 2) If result of the match is "discontinue" and the node is also a GRASP relay,
>> what does the node do? Discard or relay? It cannot know the result of the match
>> in its neighbors.
> 
> [Bing] If there is matching condition in the packet, then the matching rules behavior automatically be superior. So, even it is a GRASP relay, it would discard the packet when match condition is "discontinue".

[Brian] OK. That needs to be stated carefully in the draft. It's a little complicated for the implementation, because it delays the decision to relay a flood until after the O_SELECTIVE_FLOOD option has been processed. (My existing code makes that decision much sooner, so some restructuring would be needed.)

By the way, I think you need to define where the O_SELECTIVE_FLOOD option is placed. For example

flood-message = [M_FLOOD, session-id, initiator, ttl,
                ?selective-flood-option,
                +[objective, (locator-option / [])]]

> The match rules don't consider whether how the neighbors would react on the same rule. This might be "rude" for some scenarios, but could be efficient in some specific scenarios, e.g., highly-herachycal networks.
> 
>> I really don't understand the meaning of the matching rules, especially "match-
>> object = NEIGHBOR / SELF". I think this needs a lot more explanation and some
>> more detailed examples.
> 
> [Bing] Normally, the match object is the node itself. 

[Brian] OK. However, Anima doesn't really have a formal node identity, so I think you need to define what you mean very precisely. At the moment I don't know what I would write in my program for this.

> But we wanted to keep a bit programmability to allow the node to judge whether to continue or discontinue the flooding based on its neighbors' information.
> It assumes that the node has already learned the neighbors' info previously. Let me try to make some detailed examples in the next version.
>  
>>> 5.3 Realizing Subscription as An Event
>>>
>>>    In fragmentary CDDL, a Subscription Objective Option follows the
>>>    pattern:
>>>
>>>          subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj]
>>>          objective-name = SUBSCRIPTION
>>>
>>>          objective-flags = 2
>>>
>>>          loop-count = 2
>>>
>>>          subobj = text
>>>
>>>
>>>    This option MAY be included in GRASP M_Synchronization, when
>>>    included, it means this message is for a subscription to a specific
>>>    object.
>>
>> The M_SYNCH message is the reply from a data source to a data destination, so
>> I think that's wrong. I think that SUBSCRIPTION should  be used in M_REQ_SYN,
>> when a node first wants to get the value of a given objective but also wants to
>> subscribe to future push updates. So the reply to a M_REQ_SYN with a
>> SUBSCRIPTION option would be M_SYNCH with an initial value for the objective,
> 
> [Bing] You are right, we made the mistake. Thanks for pointing it out.
> 
>> but the session could stay open with M_PUSH to follow at any time. (So that
>> solves the question of the port: whatever port is used for sending the
>> M_REQ_SYN listens for the M_PUSH messages.)
> 
> [Bing] As replied above, I believe this is a valid use case. But we wanted to decouple M_PUSH and SUBSCRIBE. 
> 
>> A new M_REQ_SYN would also be used to carry UNSUBSCRIBE. Alternatively,
>> the node could simply close the port and the next M_PUSH would fail. If we did
>> that, UNSUBSCRIBE would not be needed.
> 
> [Bing] If M_PUSH is standalone, then UNSUB is needed.

[Brian] Agreed.

>  
>> Finally do we actually need M_PUSH, rather than just sending M_SYNCH again
>> whenever needed?
> 
> [Bing] Even if we don't need M_PUSH standalone. I think current GRASP doesn't support multiple M_SYNCH for a single M_REQ_SYNCH? 
> Quoted as below from GRASP, I interpret it as "Per Sync Per Req":
> " It then sends a synchronization request (using M_REQ_SYN)
>    to the counterpart, including a specific synchronization objective.
>    The counterpart responds with a Synchronization message (M_SYNCH,
>    Section 2.8.10) containing the current value of the requested
>    synchronization objective.  No further messages are needed and the
>    transport connection SHOULD be closed. "

[Brian] Yes, that would have to change. But if we make PUSH the same as unicast FLOOD, this issue goes away.

>  
>>> 5.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.
>>
>> I don't understand this. An M_SYNCH by definition delivers the current value of
>> an objective. Why do we need to say that we're publishing it?
> 
> [Bing] I think it's another mistake. The PUB option should be in the M_PUSH message. Since it is per Sync per Req (if I understand it correctly).

[Brian] OK.

If you make a new version  with the changes we've discussed, I will think about a test implementation. 

Regards
   Brian
> 
> Many thanks again!
> 
> B.R.
> Bing
>  
>> Regards
>>    Brian Carpenter
>>
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
>