Hi Toerless，
Thanks for all your advices! Here are some my responses.
1. The structure issue
The structure of the draft will be adjusted to better distinguish the different
types of changes from GRASP to cGRASP.
2. Choice between CoAP and UDP
The reliability mechanism of cGRASP is indeed inspired by CoAP. The
"exponential backoff in retransmission" and "values for default
parameters" have been described in "3.2. Retransmission and retransmission
timeout" and "4.4. cGRASP constants" separately.
The proposal of CoAP-based cGRASP is due to CoAP's mature ecosystem in IoT
where CoAP may be preferred (e.g., the IoT nodes attached to the campus or
entrepreneur networks, where CoAP has already been installed and
used. Both the UDP-based and CoAP-based cGRASP are optional for
nodes, up to their implemented protocol or preference.
3. New section for cGRASP relays
-03 version doesn't give much thoughts to cGRASP relay and defaults cGRASP
relay to be the same as defined in RFC8990. The cGRASP relay will be
reconsidered, and flooding mechanisms of ISIS/OSPF will be referred
to.
And, could you give more details about "The big benefit of cGRASP
is lightweight, hop-by-hop reliable flooding"?
4. Restructure the "non-IP considerations" under a new section for
"link-local" GRASP
The "non-IP considerations" originally aims to discuss how to enable cGRASP to
work on a non-IP network. Your advice that "all the considerations for BLE
without IP have to stay within a single L2 network" is reasonable and will be
carefully considered.
------------------ Original ------------------
From: "Toerless Eckert"<t...@cs.fau.de>;
Date: Fri, May 9, 2025 11:56 PM
To: "anima"<anima@ietf.org>;
Cc: "anima-chairs"<anima-cha...@ietf.org>;
"mjethanandani"<mjethanand...@gmail.com>;
Subject: [Anima] Re: Adoption call for constrained GRASP (
draft-zhu-anima-lightweight-grasp )
[WG chair hat off - to chime in with my own opinions]
Thanks a lot for the work to the authors so far. I think constrained GRASP is
very important
for ANIMA not only to allow a complete "TCP-free" constrained ANI with an ACP
not relying on TCP, but also for ASA to ASA communications on constrained
devices
without the need for TCP stack. And:
For me, reliable flooding of information (such as service announcements) or
discovery (flooding of discovery) is the biggest benefit of GRASP that no other
existing IETF protocol can provide (they all rely on servers or multicast, and
multicast across router hops is difficult). So i am particularily excited that
flooding could be done a lot better with cGRASP than GRASP due to the absence
of TCP
(i'll describe details later).
In general i think there is a good amount of work that needs to be done to get
the draft
into the shape i would like to see it in, but if we can agree on the goals,
then i would
rather like to see that work done as an adopted WG draft than as an individual
document
(as i already wrote in the adoption call email).
How level what i would like to see:
1. Structure: There needs to be a better distinction between the different type
of changes
from GRASP to cGRASP:
1.1. The additional information carried in a cGRASP message not in a GRASP
message
so that it can run over UDP. Aka "Nonce", Acknowledgment
info and the like
1.2. New / changed information elements not related to 1.1, aka: in the GRASP
header as it would be even if running over TCP. Those
information element
changes could be because there where bugs or the like in
RFC8995 or for other
reasons.
1.3 Elements removed from the RFC8995 GRASP headers (if any), e.g.: for
optimization.
2. Choice between CoAP and UDP:
I think it would be great to agree on the relationship between
cGRASP and CoAP.
Here is my opinion:
2.1. I don't think we should ever use CoAP. I just can't see how CoAP overall
would be
anything but a pain and duplication of effort.
Unfortunately, CoAP is not modularily
defined with multiple layers, so we would always need to
put cGRASP inside of a
CoAP header, and that involves using some CoAP Method
Codes, where we then either
need to also add (unnecessary) URI fields into the packet,
or have useless struggles
with the CoAP folks to get our GRASP message type(s) be
recognized as new Code's
for CoAP. And extending CoAP with multiple GRASP message
types really does not sound
like a good method. What if the next protocol like GRASP
wants to use CoAP reliability...
But (c)GRASP is just not request/reply based, so the
existing CoAP Code points are
just unnecessarily complex for cGRASP also from that point.
2.2 However, i very much would like to re-use the CoAP "messaging model",
aka:
how messages over UDP are made reliable and in a limited
fashion flow-controlled.
I think the spirit of cGRASP reliability already does this,
but it neither says
so explicitly, nor is it consistent in terminology (e.g.:
Nonce in cGRASP instead of
Message ID in CoAP), nor in functionality. Aka: no
specification of exponential
backoff in retransmission, values for default parameters,
no specification of
the congestion control with NSTART or the like.
Motivation: The biggest challenge of cGRASP will be to
prove to WIT IESG review that we
have a working reliability mechanism with flow-control
sufficient for the target
deployment targets. And given how we do not want to
re-invent the wheel, i think
the easiest way to get through this and feel confident
about what we do is to simply
use CoAPs model. We just need to extract the relevant
functionality from the CoAP
RFC (which alas is not written too modular).
I think CoAP is exactly the right protocol to steal/get
this reliability/flow-control layer
from, as it is the most widely deployed, IETF specified
protocol, over UDP AFAIK.
Ultimately this also means the transport layer for cGRASP
is a good amount of textual
spec work more - but NO actual functional novelty that we
would have to verify,
prove and optimize. Just extracting/copying the right text!
3. I think we do need a section for cGRASP relays:
GRASP relay, every message needs potentially be copied and
buffered separately to every
GRASP neighbor, and if there is even short term congestion, then
those TCP buffers can
become large.
On a cGRASP relay, reliability and flooding are joint in a single
protocol layer.
Hence a cGRASP relay can simply keep each message to be floowed in
a single buffer,
generate a Nonce (aka: CoAP transport Message ID) for it and then
just keep the list
of cGRASP neighbors from which it has not received an
acknowledgemenet for it.
In addition, also the flooding can easily be optimized: In
redundant networks and using
TCP, a message may need to be resent unnecessarily because it is
in a TCP buffer,
but the same message was already received by the peer from another
redundant path and
is being sent back. With cGRASP integrating reliability and
flooding, it is easy to
discover this situation: find received message by session-id. If
we already have it,
we mark the peer from which we received it as alreasdy having the
message and cancel
any outstanding retransmissions.
When we start to go into this direction, we are btw. getting very
much into IGP territory,
where ISIS and OSPF are very much beloved to flood all type of
"not-necessarily-core-routing"
related information - and both protocols struggle in whether or
how much of such
extraneous information they may want to flood. cGRASP could become
an interesting alternative.
The flooding in ISIS/OSPF has two more optimizations to make them
more scalable which we
could IMHO also add if we wanted).
Also textual note: the -03 version says that we MUST NOT make
flood sync messages reliable,
but of course the opposite is true. _The_ big benefit of cGRASP is
lightweight, hop-by-hop
reliable flooding.
4. I would restructure the "non-IP considerations" under a new section for
"link-local" GRASP, describing all options of cGRASP without the
presence of
any GRASP relay (aka: DULL plus cGRASP unicast link-local), and
then include the
option for non-IP encapsulations in that. Because that's
ultimately the limiting
characteristics:
- We could use GRASP relays to forward cGRASP messages between
multiple non-IP
networks (mesh of BLE or the like), but because we do not
want to re-invent
unicast forwarding, but we do need unicast end-to-end
connectivity, this solution
will not fly. So all the considerations for BLE without IP
have to stay within a single
L2 network.
Cheers
Toerless
On Fri, May 09, 2025 at 05:52:59PM +0200, Toerless Eckert wrote:
> Dear ANIMA WG enthusiasts
>
> This email starts a three-week adoption call for drafts
>
> draft-zhu-anima-lightweight-grasp
>
> The timeline is longer than the usual two weeks because we have other
drafts
> up for adoption call in parallel.
>
> [ Note that the file name only includes "lightweight" to make the revision
history easier,
> the text already calls it constrained GRASP (cGRASP). It
would/should be renamed
> to "constrained" during adoption. ]
>
> This draft has undergone already several rounds of improvements and good
> discussions on the list and during WG meetings. However, investing more
substantial
> work into this effort would be much better spent if it was clear that the
WG
> agrees to carry this effort through, and hence this adoption call.
>
> Constrained GRASP is a necessarily element for implementation of an ANIMA
ANI on
> constrained devices without requirements for TCP. It even more so would be
required
> by ASA on devices without TCP. This includes potentially even
> devices without IP, such as in BLE networks.
>
> Constrained GRASP could have benefits also for non-constrained
environements -
> it could eliminate the need for different protocol approaches for
constrained/unconstrained
> ANI environments.
>
> Also, cGRASP could provide in-network flooding that could aleviate the
need to encumber
> IGP protocols with additional, non-routing related information that needs
to be flooded.
>
> So, please review, provide feedback, also if you are interested to help
> as author or contributor.
>
> And as always: If you don't like something, please explain.
>
> ---
> Toerless Eckert (for the chairs)
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
