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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 19 September 2019 02:12 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 BC59212008A for <anima@ietfa.amsl.com>; Wed, 18 Sep 2019 19:12:51 -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 USvM4kQ9xtjv for <anima@ietfa.amsl.com>; Wed, 18 Sep 2019 19:12:49 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 6562D120072 for <anima@ietf.org>; Wed, 18 Sep 2019 19:12:49 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id b128so1213425pfa.1 for <anima@ietf.org>; Wed, 18 Sep 2019 19:12:49 -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=a4XiuIwpcxpNqE7BJfmpn3/493oWtYEnp3vvuf/Caqk=; b=fOsjfrSVZtMPdLYz0TemDAiI+T/qTUsTPEGZPcGDDDLYrZUcNtYZJpg9aTf3Rk9tiu uh7rGGxgB7z0p4eIMsD9dC/kcOz1Mi9A+/SsVGZduZXdVrsYWeAw8tgfFIIB6twbr0fK wHZe0T6Hbzt6G4iwlMSbnj1/zx73p4UdFr+CEz+AbMITP/nKtAGh7qHubsKhE1lLsqAg sI50KgfGs/VX+radVW7w3ySr3XYWhiMKgQRFVRmR/CG6T3BwKeeTJwdCrk9GXzo/0+gm dS/73GNVC28l3O1eu9HdBVuufYNv+OyxX163IUIkWa6AMjYeTkGcMT/NIoyTCPQ6wRyT AA7Q==
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=a4XiuIwpcxpNqE7BJfmpn3/493oWtYEnp3vvuf/Caqk=; b=OUV3RLKvMcEsxLJzDbk88jMjSGmuOLjjGnF+YpABP+IY2NYgQ857QSPzIWg6GQdPbu wrZDPhviuM2rs7wZnTiLS14iLsZkHiQ8HbDJb/ZSYmMtBecINVrkBk+ofQV0A0lnFmEJ IKk6eC+zMXW/BAcCIxj7RLH3lYyhGajy6P18WJ4ctTlk3gCUKKFidrEFNJnLu4Vueo4P 1d4vVJKiWCOpCMiym2RDuPuoCsfcqyBpDImegZh5F/uep103AGJLlzummOKhR0Z65qC6 C79tBcxTY89Ybf2C+pgHINwWK4ZakUiVmeIDvTSkG0O2VoNGSy8hFzEwwXtA9an57xp5 PihA==
X-Gm-Message-State: APjAAAUy88PSL/jvl0Kz4LVS7lAh2keCpHFqCAE4xwpHIJko0gJzyU8Y HQzzk8hWcUK+G31sgNTRySdp7nAo
X-Google-Smtp-Source: APXvYqz0L7ua+MbF1XV96kcw4MWWtXHjxTKhSFVjdiufCgR0DXLTRUsPwq5TweB0L5Y1FOOC2JVjZQ==
X-Received: by 2002:a65:6104:: with SMTP id z4mr6677791pgu.27.1568859168608; Wed, 18 Sep 2019 19:12:48 -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 71sm17515743pfw.147.2019.09.18.19.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Sep 2019 19:12:47 -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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <bca8409b-8fc6-4a52-4b2c-27cfd63e1070@gmail.com>
Date: Thu, 19 Sep 2019 14:12:43 +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: <6F4E6B0C717D4641A2B79BC1740D8CF4A7E22D04@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/MpYLs3nnZKxm_YYJ9SM24OwgWnM>
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: Thu, 19 Sep 2019 02:12:52 -0000

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
>