Toerless Eckert <[email protected]> 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.
> 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?
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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
