Re: [Anima] Review comments on draft-ietf-anima-grasp-api
Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 20 September 2019 02:26 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C287D1200C3 for <anima@ietfa.amsl.com>; Thu, 19 Sep 2019 19:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGjsYu_8-1Kn for <anima@ietfa.amsl.com>; Thu, 19 Sep 2019 19:26:03 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9234D12003E for <anima@ietf.org>; Thu, 19 Sep 2019 19:26:03 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id u17so2940018pgi.6 for <anima@ietf.org>; Thu, 19 Sep 2019 19:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=oIlg2YwVDxqV8vG43Ycm1U3ZnVvioOO0DxnWfZzUq9g=; b=mowvkANXjt/WOWnXWm9mrsutZ3Ly9ekea0ye6wNecnESF4bz2T1UDKoalNUoG5uHp7 nX9AkxthLptr5/BWOXGmqVtLERMISMaq4VWyzZ/yk4F4O/EijwEJcIN4U7lbET8EltZ0 GWBLpZf//z1v+RwFL9QVhiYyvLPIZInYXjnX1RB+VskpGmgDIeEmptKzvtyWvnRBVc9r tShQezgugzQlEDbpagDXF4zhO+182znvQlWnTNe+BMJnHIxvs+c54OMi3E1/t2WuGyao 967I5iqswpINm0jNogkMj28C5u6BLflbOFJSnqEvwB/Wlsu6qKqZxHz88hSM/u9TObis FHeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oIlg2YwVDxqV8vG43Ycm1U3ZnVvioOO0DxnWfZzUq9g=; b=YXOqwMRoLIDyL6IOOF82zkgavXAQShPtXI0pzZa28AOETYBk+9ensdU0ysezWpblHw SBmpsLkuVNMSol6wEVE09I/C4qh4tJ/bNBNAb3B8h4a70AmPNapg+CYF7hfYQb9Ew1Tu C+HnIR9alNOv9wIouB7dBkZKHwBPpqHNYZ0jFpWFMIlvilisAyy0Z+vS8oNI40gK1qzi FQOGi6Vyz+cGtZ+lpbpJCpKP0+qDquI3eL/37Cd/L1u2eKaRU9XiFHQewzYS7d0+2ldW Tfat3CfBLN3iuCJCZqGKqjdc2lG3e+cZumPiBqeJIIeirxAb/ZmLIL542UInPhmCam9/ 1Ipg==
X-Gm-Message-State: APjAAAUWbI7oJNklNvfE2uMGGLmCYgtWuvYRBcPfK+S34fBM5X5maxF5 VX0SeUZxOoJfigY9wDan7e43yBn0
X-Google-Smtp-Source: APXvYqzCJAxsHrhtzUjocqa3h2j9z9vmShDLY/axXGzvff+FDmPUDV4+mbxWSBKOegUjCYCDm+UiZg==
X-Received: by 2002:a63:4451:: with SMTP id t17mr12856513pgk.128.1568946362733; Thu, 19 Sep 2019 19:26:02 -0700 (PDT)
Received: from [192.168.178.30] (82.206.69.111.dynamic.snap.net.nz. [111.69.206.82]) by smtp.gmail.com with ESMTPSA id 65sm353194pff.148.2019.09.19.19.26.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2019 19:26:02 -0700 (PDT)
To: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>, "anima@ietf.org" <anima@ietf.org>
References: <6F4E6B0C717D4641A2B79BC1740D8CF4A7E22578@DGGEMM533-MBX.china.huawei.com> <59be9ae2-9ccf-a5aa-1b70-5075574a05d3@gmail.com> <6F4E6B0C717D4641A2B79BC1740D8CF4A7E22D04@DGGEMM533-MBX.china.huawei.com> <bca8409b-8fc6-4a52-4b2c-27cfd63e1070@gmail.com> <6F4E6B0C717D4641A2B79BC1740D8CF4A7E2307E@DGGEMM533-MBX.china.huawei.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <438f7146-45ce-396b-9005-849e15371a87@gmail.com>
Date: Fri, 20 Sep 2019 14:25:58 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <6F4E6B0C717D4641A2B79BC1740D8CF4A7E2307E@DGGEMM533-MBX.china.huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/roxztf3mnMjC3ud9HQOJvbwKfo0>
Subject: Re: [Anima] Review comments on draft-ietf-anima-grasp-api
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 02:26:06 -0000
Hi Guangpeng, I will try to explain it in much more detail in the new draft. You are quite correct that the ASA doesn't need to know any details of the session ID, but the problem comes when the same function is used as the callback for multiple sessions. Regards Brian Carpenter On 19-Sep-19 18:34, Liguangpeng (Roc, Network Technology Laboratory) wrote: >> 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:brian.e.carpenter@gmail.com] >> Sent: Thursday, September 19, 2019 10:13 AM >> To: Liguangpeng (Roc, Network Technology Laboratory) >> <liguangpeng@huawei.com>; anima@ietf.org >> 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:brian.e.carpenter@gmail.com] >>>> Sent: Thursday, September 19, 2019 4:39 AM >>>> To: Liguangpeng (Roc, Network Technology Laboratory) >>>> <liguangpeng@huawei.com>; anima@ietf.org >>>> 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 >>>
- [Anima] Review comments on draft-ietf-anima-grasp… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Anima] Review comments on draft-ietf-anima-g… Brian E Carpenter
- Re: [Anima] Review comments on draft-ietf-anima-g… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Anima] Review comments on draft-ietf-anima-g… Brian E Carpenter
- Re: [Anima] Review comments on draft-ietf-anima-g… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Anima] Review comments on draft-ietf-anima-g… Brian E Carpenter
- Re: [Anima] Review comments on draft-ietf-anima-g… Liguangpeng (Roc, Network Technology Laboratory)