Subject: Re: [core] Fwd: New Version Notification for draft-tschofenig-core-coap-tcp-tls-04.txt

From: Simon Lemay <[email-masked]>
Date: Mon, 20 Jul 2015 17:16:33 +0200

Hi Matthias

(i seems to have lost the email so i copied the replied at the end of this email)

Thank you very much for the review.

I think all point you mentioned on the draft (started with a page number) are very valid and should be reviewed/correct.

I agree that the implantation of a UDP/TCP gateway would be most valuable in  determining the best way. (i would be more than happy to help :))

i think that creating a gateway would help a lot indeed in finding the best solution.

But for now I do think that the best proposed solution would be L3.  but i am not too sure that i would want every resource bigger than a 2byte frame either go out of band which would force a device to implement a second protocol.  In some cases, i think that it will be available and allowed, but this become more of a business logic as to what a device can offer and needs knowledge about the device. I feel that going out-of-band goes a bit outside of interoperability unless we specify what is the out of band control.

The other problem, is that if we keep blocking feature for proxy purpose, then following the standard, if we go outside the allowed framing, we need to result to application layer fragmentation. The current way to do this is to create block of 1024 bytes.  So this would be quite weird on TCP to do so.  Any higher drop of data, especially if dynamic on numbers (like a resister of historical data or things like that) would then trigger this behavior.  I believe that L1 as threshold that is too low and would either be truncated or fragmented at the application layer.

Cheers
Simon

————————————————————————————————————————————————————————————————————————————

Hi

First, here is my review of the CoAP over TCP/TLS draft as volunteered in Dallas. After that, I added some comments on the alternatives introduced in -04.

Page 2) The paragraph on Web environments is a bit confusing when talking about front-ends (usually the Web pages for the user). Proposal:

Finally, CoAP may be integrated into a Web environment where IoT devices use CoAP over UDP to connect to a cloud infrastructure, but the CoAP messages are then transported using TCP between the back-end services.  These services may also use a transparent TCP-to-UDP gateway at the cloud boundary to talk to the UDP-based IoT.

Page 2) Last paragraph: "document document"

Page 3) Talking about transported Non-Confirmables already caused a lot of confusion. The document should state _from the beginning_ that the whole message sub-layer with its message types is obsolete when using TCP/TLS.

Page 3) The specification of UDP-to-TCP / TCP-to-UDP gateways should go into a proper section. (I also do not like the statement "re-pack [...] into NON messages".)

Page 3) Figure 2 is quite pointless :)

Page 4) It would be helpful to mention separate responses and token matching directly in the document (I guess the reference to RFC 7252 aims at this).

Page 4) Figure 3 again talks about NON messages...

Page 5) Figure 5 should already include the specified bits instead of "T" for type (like the payload marker)

Page 5) "Message Length" in L1 should probably be "Length Shim" like in Figure 5 (or the other way round).

Page 6) Not sure if the missing Version field in Figure 6 is a bug or a feature.

Page 7) The discussion is a bit misplaced in a sub-section on the message format. The insight on the record length field could be integrated into the last paragraph of Section 1 (in a crisper form). The impact on CoAP extensions (e.g., block and observe) should go into its own section.

Page 7) I think Section 5 on message transmission should come before message format. The fact that a single TCP connection is used for multiple request-response exchanges should be mentioned early. The information on potential interleaving of request-response pairs also connects nicely to the last paragraph of Section 3.

--------------

In general, I think we need some experience from implementing UDP/TCP gateways (both ways) to decide on practical lengths indicators.

For L2 and L3, I see the problem that the short length indicators of one byte are too short and most messages will need two bytes anyway (note that GET and DELETE requests still need to carry the URI and other options).

The advantage of L2 and L3 is the possibility of a 32-bit length indicator. However, since blockwise transfers are mentioned to be required for nodes with TCP/TLS binding, I do not really see the need for 32 bits. It would be convenient in a CoAP-over-TCP/TLS-only environment, but I see the compatibility with UDP-based devices at risk. In my opinion, having one Web protocol in common for _all_ classes of IoT devices is the greatest part of CoAP. For bulk data or multimedia, applications can still include links to http, ftp, or rtp resources---that's the nice part about the Web.

I count this as +1 for L1.
Reasonable use cases together with a properly working UDP/TCP gateway can still convince me, though ;)

Ciao
Matthias