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.
> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
