[Anima] Message size limit in GRASP - is it a problem?

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 12 August 2017 01:48 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 76A1A1200F3 for <anima@ietfa.amsl.com>; Fri, 11 Aug 2017 18:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_PASS=-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 C8T_vZs3Iqme for <anima@ietfa.amsl.com>; Fri, 11 Aug 2017 18:48:05 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 4F049132195 for <anima@ietf.org>; Fri, 11 Aug 2017 18:48:05 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id v77so21536224pgb.3 for <anima@ietf.org>; Fri, 11 Aug 2017 18:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=FZkW+lieEp6GjUSanu9qmN9i8KEWSGtr17Sjdh0jAf8=; b=TtguFnjYCetOxsptYGDFhY2xVnQdtuYtADosmHG0AsYWxTP2CSY2IBPqji6W0oinPW C3xXFB+UvYZmKgTZlUxlMD0dXc/AReIaKO8dh/JpFqWUNaz6P0igLqASfKPVsLWtwPmC V8gQsMopxIhBSq1vMF+9/5/0onS8As8ICoKPmkg40008vNWvvOLQWYxtqtJW/+k/HHrD +vXexVbeVvXfEZxAryh6Yn1DnTVJWne5tOapi6NBatwhKz0/NpP7yWOMyclxu2euinjM ipKZHPf1mfizD9FrEXMcLWpu7KFpYKi5hGtjRxldF8spdEd0907R6kw+ZQWl3yulAH7z MFMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=FZkW+lieEp6GjUSanu9qmN9i8KEWSGtr17Sjdh0jAf8=; b=hMu+IsbJOpABW+QxKB6urXhwaCGjsg1A0XLMpT1i3WNoRNWFbtJhXkMUGJFrCMlPx2 UM3yXjdZdlC7alyQj7rx0CPGy68M+0NoJUI+XPOqWAYB5VnvWwdt9wEWFJ1YtzuDdJ95 pRj4Pcxkh9AiIUvRB2kivVKNfb6c7EHcXQQUWwsk+43o/Y3rUkhnv+JTnl9hTG1wVBcX vRqfOW4FXPSY301CnO0ePsZWRv72iCNcyl/6rawr3D3gpLQ2Ly34YuaSu2tP1brrw0XC FS45Lpih5EiTHGhl/sFJ3+tElRewpRK+mogH0gMfizny2JP+6xBOYFKvO01Pl8nCGfCp xSVg==
X-Gm-Message-State: AHYfb5hxrD1nWW7WJVxAVud4Kg4q2UVPl0Qlm5lBdsSO1OQ0A/58dPWf OoI7qu2BUWSG5o2/
X-Received: by 10.98.57.66 with SMTP id g63mr18346101pfa.5.1502502484667; Fri, 11 Aug 2017 18:48:04 -0700 (PDT)
Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f74sm4886257pfk.131.2017.08.11.18.48.03 for <anima@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 18:48:04 -0700 (PDT)
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
To: Anima WG <anima@ietf.org>
Organization: University of Auckland
Message-ID: <c14dbc45-4ce2-a446-72ae-0ac28d93c849@gmail.com>
Date: Sat, 12 Aug 2017 13:48:10 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/mmeLJjZQi-mAw1QitdRw0zx27hc>
Subject: [Anima] Message size limit in GRASP - is it a problem?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 12 Aug 2017 01:48:07 -0000

Hi,

I assume everyone is aware that GRASP limits its message size to 2000 bytes.
In case anybody thinks that could be a problem, I don't think it is.
Or at least, it's easily overcome for objectives that might become large.

Recently I've coded a pair of demonstration ASAs to check the feasibility
of capturing DNS-SD information in an autonomic node, and relaying it to
other autonomic nodes via a GRASP objective. That is fairly straightforward,
and allows one "smart" ASA to handle the complexities of DNS-SD lookup for
any number of dumb client ASAs that don't want to bother with details of the
lookup process.

In the course of testing this I managed to generate a GRASP message that
significantly exceeded the 2000 byte limit set by the GRASP spec.

Then I realised that for a negotiation objective, this can easily
and reliably be overcome, by fragmenting the reply at ASA level. The
process is as follows:

- the client ASA opens a GRASP negotiation by requesting a DNS-SD lookup
  via a GRASP objective.
- the "smart" ASA performs the lookup sequence (which involves some
  parsing of the results) and prepares the value to be returned. It
  is a sequence of DNS records (as described in RFC6763), which GRASP
  of course encodes in CBOR for transmission.
- if the result will fit in a single GRASP message, it is returned as
  the objective value in a single GRASP Negotiate message, and we're done.
- if the result is too long, it is fragmented, and the first fragment
  has a marker appended to it (in my test, I simply appended a dummy
  DNS record 'MORE').
- in that case, the client continues the negotiation (for example,
  by sending back an objective that contains the value 'ACK')
- repeat until done.

Coding this added about 25 lines of Python to each ASA. It's reliable
because all the transactions run over a TCP connection.
 
Regards
   Brian