Re: [Anima] Review comments on draft-ietf-anima-grasp-api

["Liguangpeng (Roc, Network Technology Laboratory)" <[e-mail]>]

> Sorry to insist, but I really disagree. I'm thinking about how I would code the
> callback function for a resource allocator, and I'm sure it would need some sort
> of identifier for the particular resource request, since it might be handling many
> resource requests in parallel. In GRASP terms that is a session identifier.

I agree there must be a session identifier in GRASP. However I think this draft is about to define the GRASP API for ASA. The ASA invokes functions through these APIs, and a grasp library implement APIs which includes encapsulating GRASP messages, send out them and wait for receiving response messages. So for call-back approach, all the magic is in the library, the library is responsible for mapping session identifier in messages to correct call-back threads. The ASA just need to tell library which call-back function would be executed when invoke a asynchronous API, the ASA knows nothing about the session identifier used in the messages, thus donot need 'session-nonce' parameter in the API.

Best regards,
Guangpeng

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Thursday, September 19, 2019 10:13 AM
> To: Liguangpeng (Roc, Network Technology Laboratory)
> <[e-mail]>; [e-mail]
> Subject: Re: Review comments on draft-ietf-anima-grasp-api
> 
> On 19-Sep-19 13:23, Liguangpeng (Roc, Network Technology Laboratory) wrote:
> > Please see inline.
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[e-mail]]
> >> Sent: Thursday, September 19, 2019 4:39 AM
> >> To: Liguangpeng (Roc, Network Technology Laboratory)
> >> <[e-mail]>; [e-mail]
> >> Subject: Re: Review comments on draft-ietf-anima-grasp-api
> >>
> >> On 18-Sep-19 18:22, Liguangpeng (Roc, Network Technology Laboratory)
> wrote:
> >>> Hi authors,
> >>>
> >>> I read the draft. I think the API list for grasp is complete and
> >>> good. But I have
> >> some comments on section 2.2.
> >>>
> >>> 2.2. Asynchronous Operations
> >>>
> >>> '... there are two main techniques for such parallel operations:
> >> multi-threading, or a polling or 'event loop' structure.'
> >>>
> >>> According to my knowledge, 'multi-threading' is a different thing
> >>> with
> >> asynchronous programming mechanism. So I prefer to 'asynchronous
> >> programming mechanisms with multi-threading' here.
> >>
> >> OK, will rephrase.
> >>
> >>> The main techniques for asynchronous programming discussed in draft
> >>> should
> >> be 'polling', however, polling is not so efficient. The more
> >> efficient one is 'call back' mechanism.
> >>
> >> Yes, we certainly need to discuss callbacks. I'm not sure it is
> >> always more efficient, because that depends on the underlying
> implementation.
> >>
> > Agree that all performance rely on the implementation. Generally saying,
> polling will consume CPU resource to query response again and again until
> timeout occurs. In other hand, every implement of agent based on polling
> mechanism library will couple with the library. That means most time different
> programmers will write the code respectively for the agent and library. It's
> more hard to guarantee achieve the best performance. Compared to polling,
> call back mechanism decouples the whole workflow. Only the library
> programmer need to care about the asynchronous part performance. The
> agent programmers just need to implement logics according to 'call back'
> mechanism then everyone can get the same performance provided by the
> same library.
> >
> >>> 'session_nonce' parameter may be useful for polling, but 'call back
> >>> function
> >> pointer( or reference in some programming language)' is normally used
> >> as parameter of invoked functions. All logics should be executed in
> >> call back functions which will be called when some events occur, for
> >> example receiving response message for the request, or message timeout.
> >>
> >> Yes. However, if you have two simultaneous negotiations, you will
> >> still need the session_nonce in the callback, I believe.
> >
> > Yes or not, I think. If the library is implemented based on call back mechanism,
> the agent programmer don't need to know anything about 'session-nonce'. This
> means there needn't be this parameter in this kind of API. Indeed, the
> implementer of library need to consider 'session_nonce' carefully if its name is
> still 'session_nonce'. So, my opinion is 'session_nonce' is necessary parameter
> for polling-based API, but not for call-back-based API.
> 
> Sorry to insist, but I really disagree. I'm thinking about how I would code the
> callback function for a resource allocator, and I'm sure it would need some sort
> of identifier for the particular resource request, since it might be handling many
> resource requests in parallel. In GRASP terms that is a session identifier.
> 
> Regards
>     Brian
> 
> >
> >> Thanks very much,
> >>
> >>     Brian
> >>
> >>>
> >>> Best regards,
> >>>
> >>> Guangpeng Li
> >>
> > Best regards,
> > Guangpeng
> >