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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 04 December 2020 08:36 UTC

Return-Path: <magnus.westerlund@ericsson.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 03E773A09CD; Fri, 4 Dec 2020 00:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 eb7Gb2bj8GE9; Fri, 4 Dec 2020 00:36:26 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2733A0AF5; Fri, 4 Dec 2020 00:36:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V1TsgvmeJmLbSzw2YuTlsMHUQ3okiYQZuk1KgmtNROWCbg6v+p1YDJ7EC8rlKoBzbZypDY+1VjUBs+NltryWYAl5ZcgXatMyM6IVCKl1MWHVQqHt5X8P6BVvfI8X4R+aWp3yqpe2S5p+oedMlPbicNdhRskO+/zyDT2krRiRE0XoQyMcQTnDjXFqO5g+ThIv8oGreNw8mAmpHek6FPIN0iV3msi1UVUVt8tB4JEWmuOXgV0sgFyYTjqBy3LjYXKtdtN2pF8pyn0woobvYOh+mrK3d0WKUkn/nE0gu6BECGqwaKpW60dt55dnECJo6CQOH9pj5Wk2Cgiqfga02hcIXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uGptAIspUNz+HISp6DDR3bm/hnrI9zu1Zl0DOr2nMj8=; b=RBKJl8EHX+ciDVDPnLqTqYSlejHf7HgaIYXYSgvAqkALzQ8wq9ghPTUqpGdZEZsyoQreeAFPlQ/Y2+7QgZTnP4qwGi2jbmXAxRaOe6m2T3Ju2hun5+uMgZWX1AAX6HCOzQowVtPwtZz+ACPV+6Jb6HrKohfP8LnKEVx52J8nwCmoevcUx3SUk6Wbgtq3PEF8nyXFGPkJiKWi0Q4Zd1BGCVAwV1HShdKcR2wQyeWz4L/sPgyiDOhU0qd+0l2p8AAZlXnHLQk/wRiYT6/HjfKMdI446nSIQZ4r/tJQrjnWYlQnDidzNfwTQYTSk08umMbqrx/MMjnYH4/GcfJmfyjNzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uGptAIspUNz+HISp6DDR3bm/hnrI9zu1Zl0DOr2nMj8=; b=SRZz6oIG1rgIbft05EpIutX9lK06vzlzuy2YVZCrBko6X+XA/fvZKupShoQVq9vBnNgPoqrtKDLBvh79zssKSJFZJX+nzChx78EcFimYFs81KEz6A/Yy8Ma3B3PUOqcLC/a6e0z7f8C9WzzFSQv/l4mXinJWALNVmmFEnaRI644=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3706.eurprd07.prod.outlook.com (2603:10a6:7:8d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Fri, 4 Dec 2020 08:36:21 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3632.018; Fri, 4 Dec 2020 08:36:21 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.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>
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)
Thread-Index: AQHWyX+mAPa4wQeq7UKGg1bNNA1k2KnlzMWAgADRToA=
Date: Fri, 4 Dec 2020 08:36:21 +0000
Message-ID: <cc7423f5292fb0b09c309ff64320580d6a516fde.camel@ericsson.com>
References: <160700528599.27447.1943648730093384240@ietfa.amsl.com> <4c7cc11f-6d5c-95d2-ea37-b5d23f300537@gmail.com>
In-Reply-To: <4c7cc11f-6d5c-95d2-ea37-b5d23f300537@gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8da85c61-45ad-4fcb-bc47-08d8982fad59
x-ms-traffictypediagnostic: HE1PR0702MB3706:
x-microsoft-antispam-prvs: <HE1PR0702MB3706829482415486F3F58F7395F10@HE1PR0702MB3706.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yyN6AKhResQAvCedU40PsD/uo/Ngnft+H7LUYf801XMPpIPfWWKgnRfVRb6Rd5d5Qcy54/M8kSvAF80kMkNQ/VhEK3hp3GgPorv7xSHu1v7fId2u7/uPon8g9HZElzsUP0SFAWqQqIkhvFuqPpVDvmiCpfp1p1dBZF6aCRjtzp3P+A0kZCXO8CU96KlqWayvw++Ta4rMP4JqkeB50HmxfFmglsXP+ef6kmTiZyXE0sedNuOqylZiyjgvV1tMute+leZQn2LTKLWL4uKvqhtF3VQMT537iuqKhkEElko4KJ0IBJdRLRwRP5p5Yp7NtOEiIvADcpNZ6h5TfphdUU7C88GtUVnyR/8JhTIpv6kCoXfldug47c4HgGgGD/6n8BYXfW1YYdIwCSq22h/XqIoVqgWvuAYb9qaPX2NNuP5IGNnloSUqyiLwPxBCXilLz8r3N073vpamY7WSLVFAmyYuZA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(136003)(39860400002)(376002)(6486002)(6506007)(64756008)(66476007)(66446008)(83380400001)(54906003)(110136005)(76116006)(66556008)(66616009)(36756003)(8676002)(2906002)(6512007)(8936002)(66946007)(99936003)(44832011)(26005)(186003)(316002)(2616005)(5660300002)(53546011)(478600001)(86362001)(4326008)(966005)(71200400001)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?OWtkcWFBeDBFUmpRZ2pHR3BhM3hjUUp0NjNRRFlaRExtYnBjVTZHcmxNa01P?= =?utf-8?B?bi9ZaGF1K3VSVjJvdjQ3QzliMTU1RDNCQTg0YjJLWHMzUDhSTC9US2JadE55?= =?utf-8?B?SHZFQWk2dkNVMmhnWHo4VUM4UXJrQXNXN0ZzTTRQQmVleXRYZW1ocUNEUGdB?= =?utf-8?B?UDJ2eGpnMElxVEQrRHNGNms2YUVvVE5zeWdaOTRVUktILzRUdzE2VUJ6MStQ?= =?utf-8?B?aDh3Y1B5eTlpTEhMSGlCRlFZbmRzQ2IzdVJWUXBnUXhiUitOci9EMDdjdzBw?= =?utf-8?B?WGpQVm0zWjBJRnA1dUU4bmkzaGZBSVN4UWplZzFtcldqbDZacHd0c1NMR3N4?= =?utf-8?B?THhEaTJNSXVkMGxtSVk2ZHlEMmNoMTYrZ3NWS1czWkZ0c295TndMSW9RM1NG?= =?utf-8?B?d0M5RnUrckIvMys5NWFJQW9lTDFtZFQ5RGNYL3BqZDgrQVY0MTdIeGJOUElQ?= =?utf-8?B?c0J6TmxEZ3drczhZU25NZ2RhVmh5VWo2TDAwNHdjWDcvVERiRDFTaXRsbWI5?= =?utf-8?B?L2E3eHR5bFlhcGRMZ0lUM1RDZi9mTzB6OExDOVFRbDFIR2FLaW5RZjZWMEhi?= =?utf-8?B?UitYdExWejRYT1VMeXFGMUV2bkNoQlRnQWhqYVdIT1VKZGc5VUxLK0xLRUdK?= =?utf-8?B?WEJyV09lMitvOU5TMzcxaTZtY05TWWdOQkRtUEZpY0Nuc0s1VThDZjBnR1Rs?= =?utf-8?B?N3RJVmNHSDdpMzJNU1NubExoQnhwSzY1bktkNVh3N2dvL2FmR3d5TjJLM0Uy?= =?utf-8?B?eHJKSUtWZXFlbW5ac1N5TkNSd1lGclowUTJTN21NSXp6VnZYZ3FQL1lxMTd0?= =?utf-8?B?dFdYN29iMHlmbHRTM2hzU1J0TW9MRGYwVk9uK0N1ekZPek42WEh6TVJDQks2?= =?utf-8?B?eUhhMmVEaDhpRnFVN2Z0Q29YMDExRE14c29rVUVWbWdZTU14VlYrSk9GV2xU?= =?utf-8?B?OE1vZ1ZZdldKVnNOaU5LQlUrK3RVekY5MGNocmloclFkMkowSnU1ZENKSXpE?= =?utf-8?B?Ry9OdDl0bnV2WXY3WGorYmhOOUlaUE1uUUF3Q1dhVG5YUUlrTnJycU5sOGRG?= =?utf-8?B?MTU4cGFQSlZ4VDJiaDBmZVp5Q0t0OFNyWkp6cW1YejhPRUM0endFcVFGa1JQ?= =?utf-8?B?L2VYK3huMHF6NkJtZnBzcDQyYU5LU1hWdWd5UXI2WU90dFREbXY1WDVFRmd6?= =?utf-8?B?eE1uZEJvMG9Qd0RiWkJIZkFMWWhwOVVwbE0vZE1DQmdHamxzVkh4Sk1tRXQ3?= =?utf-8?B?bml2QzdPVDNCcHh2UEROaGQxQ1hyaUNGeVVVQnRvTFBuYWR5TStkL1hrTjdw?= =?utf-8?Q?rp8jHz+VuCNua85INazWFfUKH5BWhhbb4I?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-HqUZguHlXYHB9gu2Clqc"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8da85c61-45ad-4fcb-bc47-08d8982fad59
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 08:36:21.0979 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QxVIJMTgaky/yFPNjMnP7LEK8J2JnljA5M5Keb2uBts3oQTF7JhwDbMe4RLfrAZ6uEUl1eIB9we5E7I7r2gpbRJw1MZ7EwSwp8FUchxFbLc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3706
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/0f6sZduhmGm7-y6i5o9JMlvvX6E>
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 08:36:28 -0000


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) or how the calling APP
would learn that your request timed out, or simply are still being worked on
because busy. 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. Secondly, does there exist any prioritization
mechanism on the GRASP level that helps with this. 

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