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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 03 December 2020 20:07 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 835703A0D99; Thu, 3 Dec 2020 12:07:29 -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 Uy40V1HaIGv2; Thu, 3 Dec 2020 12:07:27 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 E2F753A0CE5; Thu, 3 Dec 2020 12:07:15 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id o5so2069043pgm.10; Thu, 03 Dec 2020 12:07:15 -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=UR4oijpWefXFrwuoZRnutWRROOjJTQ54MYISyOXp7mA=; b=GCCTbhwWS23tcsIyUdxbLm2NZqQH9BVmwYWKHIabD0+IkDWj8OerDSI63XiX1QRz9Y RGR0FS2HHa6RCgiiEoUgDU6yqgTDNYuayxZ/IlF+nFqLdWQTpP5muqK2awDaTqV962h3 o8W2sXA1cM6lAjNmgpbdeIGXaigWky6o+QT418WxnlTj/65gROoLUHn/6QZvrWI1MCJB p35Bt/bHeBQh0OS8Zr0H/nGsdSDM8ojv+U4ptfef68IAXSfyUrAhYQxNYceX2vpJ93YB Vg/raMGZdvM6w0JIO2wGJwEUFfvSokVIU44E33ub2mH1/bLsaQEFeSbaarR7xqe8huTi Ie2Q==
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=UR4oijpWefXFrwuoZRnutWRROOjJTQ54MYISyOXp7mA=; b=ikXdCe+36hI3ztzcidNdo+fovxod4Jk3Uvx8E/sh4CxwihVMSiuyxW5EBls5PyLOUD 2xSO6eq/EBOjAFl8+Qleb/yVlH5srcyiZjct8sEqx8GknWALIuXq4bIXkz+tPz2eRV8n vCelh9QTcCV5vwy/+xQrr4SJ4zegJvunMadWXqqP+oWM5kiwtj26Tsb5y9029Ym9sM9r rI1/1JCtDuaJXxSp2yTk8mpD+kIxpy/+9ay1Ax0rH4ZJW7wYutaWvWPNKbFf4PiBnW5Z LgHIVq/4F2Ty1u5+++z74YUqYhYK3DC+QZtd82KU9K5sXhx3zDALpvd2gnn/L/gGS3vF WRPQ==
X-Gm-Message-State: AOAM533qQFjagpF5BQQs9MfBEWq0BQRUAnmM7MooF82WroKPz2aFYq3S g5CbkSg3YmvciE6d1lAM6s16oKuva1gk4Q==
X-Google-Smtp-Source: ABdhPJyX5e4gnCRCWPjgoRcOIAlq8DF1QxQLW3YJpuLC8WSUw3HGeYL/Uv4av6vLnrEA92dtf5hFMg==
X-Received: by 2002:a62:4e96:0:b029:198:1080:5bc6 with SMTP id c144-20020a624e960000b029019810805bc6mr440737pfb.26.1607026035386; Thu, 03 Dec 2020 12:07:15 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id h16sm202854pjt.43.2020.12.03.12.07.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 12:07:14 -0800 (PST)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-grasp-api@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>
References: <160700528599.27447.1943648730093384240@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <4c7cc11f-6d5c-95d2-ea37-b5d23f300537@gmail.com>
Date: Fri, 4 Dec 2020 09:07:11 +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: <160700528599.27447.1943648730093384240@ietfa.amsl.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/eMmNO1xw6tQ3lJ8CJxNTtB9BXZM>
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: Thu, 03 Dec 2020 20:07:37 -0000

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'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?
> 
> 
> 
>