On Sun, May 11, 2025 at 06:20:34PM +0200, Carsten Bormann wrote:
>
> > These are reasonable points.
> > CoAP has congestion control, retransmissions, block-mode,... which are all
> > the things that TCP was doing for us. Re-inventing that would be silly.
> > So either all CoAP, or no-CoAP.
> >
> >> 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.
>
> Here we are.
>
> I would assume that whatever “mini-CoAP” you start to design will grow
> features over time until it is indistinguishable from CoAP, except just
> different, looking like a bad example of NIH in the end.
>
That's exactly not the goal. To me, CoAP has two layers, a message layer with
reliability
(retransmission) and (limited) CC, and a "transaction layer" where all the
glory/gory of
CoAPs Code point behavior and exchanges happens. Which would be terribly
drailing for GRASP
which effectively has exactly it's own transaction layer.
Alas, CoAP is not cleanly defined separating out these sub-layers.
If CoAP would give cGRASP let's say even just one CoAP "Code" Class value
(e.g.: "Other"), which does
not inherit the pre-defined 0, 2, 4 or 5 (Class) value semantics, then it seems
to me as if
we could simply inherit/re-use the CoAP message layer. But i fear that would
greate
a precedent that might not scale. Although it should scale, because the
semantics of the
transaction layer could be derived from the responder UDP port number and
therefore allow to
encode into the 5 bit "detail" of the Code multiple times differently (so
arbitrary protocols
with their own transaction layers could re-use CoAP message layer).
But if that simple integration / re-use would not work, then it's down to IMHO
Clone & re-use *sigh*.
> (From my IRTF perspective: When we designed CoAP, we didn’t have CBOR or CDDL
> available to us, so I think it would be an interesting research project to
> invent a CoAPng (next generation) that does use CBOR and CDDL.
> I’m just not so sure that this is what ANIMA wants to do.)
Yes, interresting research project, even a good IETF project. But remember that
GRASP is not using the typical REST transaction semantic, but has it's own
transactions which are in our (ANIMA) opinion better suited for M2M
communications.
So it's a different project, not cGRASP!
I actually have no strong opinion for the industry, about whether or not the
GRASP transaction semantic
is preferrable over e.g.: GET/POST, but personally, i find GET/POST for
peer-to-peer
communications terribly convoluted given how it was invented clearly for
client-server.
In draft-eckert-anima-acp-free-ani i specially wrote that no developer of M2M
communication
for network automation should be forced to use a particular approach: Those are
all offers,
and the software (Autonomic Service Agents) should just pick whatever suits
them best. And
given how much pre-existing software there likely is for the GET/POST paradigm,
and how little
for the new ANIMA transaction methods, it is easy to see where a lot of this
may go.
However: i am primarily interest in GRASPs ability for hop-by-hop
flooding/search,
with the FLOOD/DISCOVERY primitives for which no other IETF or even non-IETF
protocol offers
an alternative. And as i tried to lay out in my prior email, the best way to do
this FLOOD/DISCOVERY
(without a manually-to-be-engineered redundant set of servers!) does actually
reach down
into retransmission buffer re-use across multiple peers. So if we where to
re-use a software
stack to provide both CoAP and cGRASP over CoAP message layer, then we would
also need to
explain sufficiently how to have an API into the CoAP message layer to allow
for such buffer
sharing across multiple CoAP message layer connections.
>
> I would expect that building a cGRASP around CoAP would have a little more
> design freedom than your garden-variety CoAP application.
> E.g., using a different port number might work around BCP190 (so no need to
> have /.well-known/coap-grasp in every message).
Pigyy-Backing GRASP transaction on top of GET/PUT/... is the totally
unnecessary pain
and "who the heck is supposed to analyze what this gives us". Its just a tad
less
useless than IP over HTTP.
> The examples in Section 5 all use non-confirmable messages and then seem to
> hobble together confirmable messages and separate responses by adding options.
> Maybe the CoAP mechanisms are better for this; they have certainly received
> more design attention than what is sketched in Section 3.
What value would cGRASP get out of riding on top of CoAP complete (transaction
layer) >
The only benefit i see is for CORE WG not having to have the pain of allowing
someone
to share the CoAP message layer by allocing appropriate Code points and
explaining
how that works.
> In any case, this is a non-trivial design effort, and it seems to me this is
> still a bit remote from a clear direction that the WG wants to work under, so
> I think this is the time for formative contributions as opposed to already
> adopting one (or, essentially, two) of them.
QUIC exctracted all the relevant pieces of TCP and reformulated it on top of
UDP.
That's likely what i was proposing to do with the CoAP message layer as ANIMAs
best way forward without being stuck in potentially endless discussions with
CoAP WG.
Would i prefer a clean share of CoAP message layer - sure. Would i want to start
thinking about the implication os using the CoAP GET/POST/... transaction
layers ?
Not unless someone explains to me that there is actual technical benefits for
cGRASP in it...
Does this make sense ?
Cheers
Toerless
>
> Grüße, Carsten
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
