On Sun, May 11, 2025 at 10:50:29AM +0100, Michael Richardson wrote:
> Toerless Eckert <t...@cs.fau.de> wrote:
> > 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.
>
> 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.
> > 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.
>
> Agreed.
So we could use full CoAP, but then we inherit a lot of "higher layer CoAP"
complexity
that's a mismatch. I would hope that the CoAP folks would welcome if we
extracted the
message-layer reliability/CC and re-use it. Certainly a good topic to ask for
CoAP WG
time to discuss.
> > 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.
>
> Is there a goal of having a gateway able to speak cGRASP and also GRASP?
> Would a cGRASP peer do CoAP with a GRASP peer once discovery is done?
> CoAP/HTTP proxies exist, but this would be a CoAP/TCP proxy?
All this proxying is painful, so i think it belong into
draft-eckert-anima-acp-free-ani, which
alas i did not have enough time to present @IETF1222. It includes other crap
like NAT'ing
of addresses, which is great to be done at the GRASP "gateway" layer.
For simple deployment, i think we'll just move from GRASP to cGRASP once it's
done:
If we do not want complex gateways, all devices need to support the same
transport, e.g.: TCP or
UDP. I am pretty sure all devices doing TCP can also do UDP (cGRASP). But not
vice versa.
Of course, there is still the question to the CoAP WG if they feel that their
CC is good enough
for large networks. From my understanding it could hopefully work, and it would
even be better,
if they have some WAN example use-cases of CoAP (but some of the low bitrate
radios have similar
latency issues as fast LANs). And if they (CoAP) have ever asked ICCRG opinion.
And as i said,
cGRASP is already trying to copy good parts of CoAP CC (IMHO)...
> What are the self-management use cases that we need to satisfy?
>
> > 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:
>
> Agreed.
Thanks a lot!
Toerless
>
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
