Re: [Anima] Magnus Westerlund's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 04 December 2020 20:13 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 80E8D3A0FB8; Fri, 4 Dec 2020 12:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 pb36yOp4fV1z; Fri, 4 Dec 2020 12:13:41 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 78BF63A0F4A; Fri, 4 Dec 2020 12:13:41 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id q10so4535368pfn.0; Fri, 04 Dec 2020 12:13:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b0FV1SNxhCg9xhMXSWyIXVLesf6ZjUr7Nytu2unlKT8=; b=Et9xbAniMjOBH75JyYvv0bc1QTvtuqAPTXURf96W/dWIvW146EGuhvIcQYksVBToYw sV1IyAMV++BCYuRy+Cd6jIdlBKXFKMo//3Wr/C1TnffrPDeceGWLQcG8XuR0Rt5zHuW3 pTCuGW68hr6E3oo3lfYocQv7Ip87osywLbrr5Tukq0pMmV1wqsA2GmRC8wzf858pA7qT XSU04VAxQ6uVGmuKVKfChAe+v8CwxQfUFIFoBw81rW2INd9gcBncVkQbR+eveEGvUKRg UOurpjED1zCVawxnl99iJYPo7ZFOoA9Qm66dpNJJaAMAsB7v6l233uRFEx5IV0LCO0yl tMNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b0FV1SNxhCg9xhMXSWyIXVLesf6ZjUr7Nytu2unlKT8=; b=NQHvvfEENqZBdWQ2eSk21vlrdP070SMTX1MwX6OFbpcSukCF/ozUdnaVWnZGkVxBRF i2kZetHxfTHQFZOi+qc3m6Rj2fl5wIdg9g8CuNe5PN+2SP4DcstqwtzFCy+lCF7LAq54 +A2qk17jhqsjxypHgCNrJL42jxuWGXPOzXc4jaZhZGsF/p3FzsOu84oruQmxX2YI7NlA UkUamCBOB1M2cl8Y5ZisDSS5gHtnuzokN/RZkx8+hXH2rjijtNCSRqk5CJdTKLOxlZhH nuI1Va1lKXDCF7YSbcfFtfPnZ4F1NTEPeo/LAOyfUxQDWTB8KqLITspdIyRRXZjASRED ycCg==
X-Gm-Message-State: AOAM532px8R5OxnjPvJwsnMLcyoEKUIR6Wbj8g2FHRMCaobd7ZMWA/Cf f2KVCKd24OIwkAQUVhwgXxpQzkDCPkWo5w==
X-Google-Smtp-Source: ABdhPJwtPLHg6g7+nPC9X/SYcEQ3WjjQDhstaBHL2eyyEDvC+3Z0fLkMeRWmn4g3V6XDx2voOEm/ig==
X-Received: by 2002:aa7:8b15:0:b029:196:59ad:ab93 with SMTP id f21-20020aa78b150000b029019659adab93mr5258184pfd.16.1607112819208; Fri, 04 Dec 2020 12:13:39 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id e29sm2335073pfj.174.2020.12.04.12.13.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 12:13:38 -0800 (PST)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "iesg@ietf.org" <iesg@ietf.org>
Cc: "draft-ietf-anima-grasp-api@ietf.org" <draft-ietf-anima-grasp-api@ietf.org>, "jiangsheng@huawei.com" <jiangsheng@huawei.com>, "anima@ietf.org" <anima@ietf.org>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>
References: <160700528599.27447.1943648730093384240@ietfa.amsl.com> <4c7cc11f-6d5c-95d2-ea37-b5d23f300537@gmail.com> <cc7423f5292fb0b09c309ff64320580d6a516fde.camel@ericsson.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9b7bdffe-9048-c263-6084-7c954ebad821@gmail.com>
Date: Sat, 5 Dec 2020 09:13:33 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <cc7423f5292fb0b09c309ff64320580d6a516fde.camel@ericsson.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/B9bO3jW4aWb4nmA3SojX_9809QM>
Subject: Re: [Anima] Magnus Westerlund's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
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, 04 Dec 2020 20:13:44 -0000

On 04-Dec-20 21:36, Magnus Westerlund wrote:
> 
> 
> On Fri, 2020-12-04 at 09:07 +1300, Brian E Carpenter wrote:
>> Hi Magnus,
>>
>> You raise an interesting point, but it's really about deployment
>> of the whole ANIMA infrastructure. We need the infrastructure to work
>> even when everything else is broken, which means it must have a
>> guaranteed slice of resource capacity and it should not exceed that
>> slice even when the autonomic system is fixing breakage.
>>
>> If that doesn't work, GRASP sessions will start timing out, so the API
>> will report failures, starting with discovery failures**. That's where
>> the recommendation for exponential backoff comes in. But I think the
>> problem is deeper than the API.
> 
> I raised this as I didn't see any discussion in the API that you could either
> become hanging on a call waiting for local resources (which would be bad for
> what I understand is intended to be asynchronous API) 

GRASP itself would be the only source of a local wait, but it only consumes
standard resources (sockets and possibly o/s threads) so I don't see this
as a real issue.

> or how the calling APP
> would learn that your request timed out, 

That would come back as an error code, although the actual error code
would depend on the particular case. (In the case of discover(), it
just comes back as a blank reply.)

> or simply are still being worked on
> because busy. 

In a threaded implementation, the thread would simply sleep until
the error code pops up. In the event loop case, you'd get the
noReply code until something happens or the callback triggers.

> My concern is that without any type of push back towards the
> calling application it can't regulate what it is doing to focuse the resources
> on what is most important.

I think it's going to be like the game loop in a complicated game.
It will have to pay attention to other issues while a negotiation
is proceeding. (Most of the times I used stackoverflow to figure
out how to do something in my own test cases, I found myself reading
advice to game implementers.)

> Secondly, does there exist any prioritization
> mechanism on the GRASP level that helps with this.

No, we've never considered that. It wouldn't be hard to add
prioritization options to GRASP.

Thanks
   Brian

> 
> Cheers
> 
> Magnus
> 
>>
>> ** I've seen it happen, when running GRASP on a busy IETF wireless
>> network, back when we used to have meetings.
>>
>> Regards
>>     Brian
>>
>>
>> Regards
>>    Brian Carpenter
>>
>> On 04-Dec-20 03:21, Magnus Westerlund via Datatracker wrote:
>>> Magnus Westerlund has entered the following ballot position for
>>> draft-ietf-anima-grasp-api-08: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> So I didn't have time to read your document in detail, thus I can easily
>>> have
>>> missed something.  Hopefully a bit of clarification on what I might have
>>> missed
>>> will resolve this issue.
>>>
>>> I do wonder over one aspect of this API surface. How does it handles when
>>> the
>>> GRASP layer is unable to send the messages in a timely fashion based on the
>>> API
>>> calls? Looking at GRASP I understand that it is using either UDP or TCP. The
>>> rate limiting of UDP does not appear to be more well specified that to
>>> follow
>>> RFC 8085 recommendations. So my concern here is that you actually have some
>>> risk of running into that the upper layer using this API tries to become a
>>> bit
>>> to active and do everything at once, thus resulting in that TCP congestion
>>> control and flow control might block timely transmissions, and for UDP the
>>> rate
>>> limiter / congestion control of the UDP messages. What happens in this API
>>> when
>>> this occurs?
>>>
>>>
>>>
>>>