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

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2015 23:52:20 +0200

I have submitted a slight update to the coap-tcp-tls draft.

Apart from a number of editorial improvements, this now includes three
alternative proposals for the frame length representation.  Reasoned
comments why we should or should not veer off the simple 16-bit length
(called alternative L1 in the draft), and, if yes, into which direction
(L2? L3? what else?), are welcome.

This is not yet integrated with the text from the websockets draft.

Grüße, Carsten

-------- Original Message --------
Subject: New Version Notification for
draft-tschofenig-core-coap-tcp-tls-04.txt

A new version of I-D, draft-tschofenig-core-coap-tcp-tls-04.txt
has been successfully submitted by Carsten Bormann and posted to the
IETF repository.

Name:		draft-tschofenig-core-coap-tcp-tls
Revision:	04
Title:		A TCP and TLS Transport for the Constrained Application Protocol
(CoAP)
Document date:	2015-06-10
Group:		Individual Submission
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-tschofenig-core-coap-tcp-tls-04.txt
Status:
https://datatracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/
Htmlized:
https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-04

Abstract:
   The Hypertext Transfer Protocol (HTTP) has been designed with TCP as
   an underlying transport protocol.  The Constrained Application
   Protocol (CoAP), which has been inspired by HTTP, has on the other
   hand been defined to make use of UDP.  Therefore, reliable delivery
   and a simple congestion control and flow control mechanism are
   provided by the message layer of the CoAP protocol.

   A number of environments benefit from the use of CoAP directly over a
   reliable byte stream that already provides these services.  This
   document defines the use of CoAP over TCP as well as CoAP over TLS.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "weigengyu" <[email-masked]>
Date: Thu, 11 Jun 2015 09:33:42 +0800

Hi Carsten and all,

One question about this draft.

In page 3, second paragraph,
"A UDP-to-TCP
  gateway will therefore discard all empty messages, such as empty ACKs
  (after operating on them at the message layer), and re-pack the
  contents of all non-empty CON, NON, or ACK messages (i.e., those ACK
  messages that have a piggy-backed response) into NON messages. "

This draft mentioned the UDP-to-TCP gateway for transfering CoAP.
Is it possibles that there is a TCP-to-UDP gateway?

Or it is not necessary to concern a CoAP message will go through TCP-to-UDP 
gateway?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, June 11, 2015 5:52 AM
To: [email-masked] WG
Subject: [core] Fwd: New Version Notification for 

Grüße, Carsten

-------- Original Message --------

Abstract:

The IETF Secretariat

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2015 08:57:03 +0200

> Is it possibles that there is a TCP-to-UDP gateway?

Certainly; as there are frequent role (client/server) reversals in CoAP,
I would expect both functions to be included in a single gateway.
On the way from UDP to TCP, it strips away the message layer; in the way
from TCP to UDP, it adds in the message layer functionality (e.g.,
adding message-IDs and performing retransmissions if required).

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 11 Jun 2015 15:39:21 +0000

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

---

From: "weigengyu" <[email-masked]>
Date: Fri, 12 Jun 2015 11:18:34 +0800

Hi Carsten,

Thank you for your reply.

Grüße, Carsten wrote:
> On the way from UDP to TCP, it strips away the message layer;

It is clearly described for UDP-to-TCP gateway in page 3, second paragraph.

> in the way

In this draft, only one place mentions TCP-to-UDP, in page 2 third 
paragraph.
"Finally, CoAP may be integrated into a Web environment where the
   front-end uses CoAP from IoT devices to a cloud infrastructure but
   the CoAP messages are then transported in TCP between the back-end
   services.  A TCP-to-UDP gateway can be used at the cloud boundary to
   talk to the UDP-based IoT. "

It is likely that the draft needs some descriptions on how to construct the 
CoAP message.
Based on the message format for CoAP over TCP in this draft,
when a CoAP message goes through the TCP-to-UDP gateway,
there is an entity on the TCP-to-UDP gateway decides by itself to send a CON 
or a NON message over UDP.

What is this entity?  It is a message adaptor, or a CoAP endpoint.
And whether this entity's decition is the same as the original CoAP 
endpoint's decision?

Regards,

Gengyu WEI

-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, June 11, 2015 2:57 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Fwd: New Version Notification for 

Grüße, Carsten