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

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 14 Jul 2015 22:26:36 +0530

Hi Carsten,

The draft looks good and it will be useful in case deploying in the internet wherein the network is behind NAT/firewall.

I have few initial comments in CoAP+tcp URI scheme section (sec 6) are as follows: 

1) I could not understand the need for the separate namespace. The actual requirement is to mention the transport for the resource than the resource itself. It is preferred to mention the transport type as a parameter rather than URI scheme. 

2) CoAP TCP shall use the default port as 80. The advantage of 80 as default port is that the traversal through firewall is better w.r.t TCP port 80.

Regards
Partha

> -----Original Message-----
> From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Thursday, June 11, 2015 3:22 AM
> To: [email-masked] WG
> Subject: [core] Fwd: New Version Notification for draft-tschofenig-
> core-coap-tcp-tls-04.txt
> 
> 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
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jul 2015 07:44:20 +0200

Hi Partha,

thank you for your input.

> 1) I could not understand the need for the separate namespace. The actual requirement is to mention the transport for the resource than the resource itself. It is preferred to mention the transport…

This is less about stating a need than a statement about the way URIs work.
A new scheme does generate a new URI namespace (e.g., http:// vs.
https://).  A server is of course free to mirror the two namespaces for,
say, coap:// and coap+tcp://.  (We already have separate namespaces for
coap:// and coaps://, see section 6.2 of RFC 7252:

   Resources made available via the "coaps" scheme have no shared
   identity with the "coap" scheme even if their resource identifiers
   indicate the same authority (the same host listening to the same UDP
   port).  They are distinct namespaces and are considered to be
   distinct origin servers.
)

Trying to unify the namespaces for coap:// and coap+tcp:// (and,
probably, similarly for coaps:// and coaps+tcp://) is an interesting
idea; I'm not sure what the consequences of such a somewhat fundamental
change would be.

> 2) CoAP TCP shall use the default port as 80. The advantage of 80 as default port is that the traversal through firewall is better w.r.t TCP port 80.

I'm not sure that would work too well in practice, as many firewalls do
expect HTTP/1-like traffic on port 80.  (It would work with simple
packet filters.)

More importantly, port 80 is HTTP's port (HTTP/1.1, to be precise); do
you expect servers to operate some heuristic to distinguish CoAP from
HTTP requests?  Or should there be an upgrade dance as in section 3.2 of
RFC 7540?  (Maybe specifying such an upgrade dance for switching from
HTTP/1.1 to CoAP is a good thing to have handy...)

You are certainly free to use port 80 in a specific deployment where you
can make sure there is no conflict with HTTP, it is just not a very good
candidate for the default port.

Grüße, Carsten

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 16 Jul 2015 05:33:58 +0530

Hi Carsten,

Please read inline.

Thanks
Partha

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2015 11:14 AM
> To: Parthasarathi R
> Cc: [email-masked]
> Subject: Re: [core] Fwd: New Version Notification for draft-tschofenig-
> core-coap-tcp-tls-04.txt
> 
> Hi Partha,
> 
> > The draft looks good and it will be useful in case deploying in the
> internet wherein the network is behind NAT/firewall.
> >
> > 1) I could not understand the need for the separate namespace. The
> actual requirement is to mention the transport for the resource than
> the resource itself. It is preferred to mention the transport type as a
> parameter rather than URI scheme.
> 
<Partha> Let us analyze to see any side effect to have the same namespace for different protocols namely UDP, TCP </Partha> 

> > 2) CoAP TCP shall use the default port as 80. The advantage of 80 as
> default port is that the traversal through firewall is better w.r.t TCP
> port 80.
> 
<Partha> Agreed. The intention of preferring port 80 is not to bypass firewall but lot of firewall default behavior is to forbid other TCP connection wherein port 80 provides better firewall traversal. </Partha>

> HTTP requests?  

<Partha> In case the server handles both CoAP & HTTP, it MUST distinguish based on the incoming packet. </Partha>

Or should there be an upgrade dance as in section 3.2
> of
<Partha> HTTP Upgrade will lead to Websocket equivalent mechanism in the initial setup. As we are trying to minimize the number of packets, HTTP upgrade is not the preferred option IMO. </Partha>
 
> candidate for the default port.
<Partha> It is possible to design CoAP over TCP without any conflict with the existing HTTP(/1.1) server. The procedure to avoid the conflict shall be documented as part of this draft </Partha>

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 20 Jul 2015 15:12:46 +0300

Hello,

> <Partha> Let us analyze to see any side effect to have the same namespace for different protocols namely UDP, TCP </Partha>

Such an investigation and analysis of embedding transport information 
(which includes more than UDP and TCP) into various parts of a CoAP URI 
has been performed by draft-silverajan-core-coap-alternative-transports 
before the adoption of using the URI scheme to identify the CoAP 
transport. In addition to the draft, you can also see the slides 
presented at IETF 89: 
http://www.ietf.org/proceedings/89/slides/slides-89-core-0.pdf

In summary, two serious drawbacks of the approach you suggested were: 1) 
the need for any resource constrained CoAP client to fully parse the URI 
before selecting the transport and 2) failure of such a URI to resolve 
relative references correctly according to the given resolution 
algorithm in rfc 3986.

> <Partha> Agreed. The intention of preferring port 80 is not to bypass firewall but lot of firewall default behavior is to forbid other TCP connection wherein port 80 provides better firewall traver…

If what is required is to specifically transport CoAP messages over port 
80, then an alternative to consider is 
draft-savolainen-core-coap-websockets, as the restrictive firewall 
scenario was one of the problems it attempts to solve.

If what is required is firewall traversal but delivering CoAP messages 
over a reliable transport, CoAP over TLS should be considered, over the 
well-known port 443. As far as I'm aware, firewalls which allow port 80 
traffic should also allow port 443 traffic.

> <Partha> In case the server handles both CoAP & HTTP, it MUST distinguish based on the incoming packet. </Partha>

Packet-level inspection on each and every incoming packet would very 
likely cause heavy performance degradation in middleboxes such as 
HTTP-CoAP (over UDP, TCP) forward and reverse proxies, I think.

> <Partha> HTTP Upgrade will lead to Websocket equivalent mechanism in the initial setup. As we are trying to minimize the number of packets, HTTP upgrade is not the preferred option IMO. </Partha>

That may not necessarily hold true, please see 
http://dx.doi.org/10.1109/WMNC.2014.6878863 (I can send you a version if 
access to IEEE Xplore publications is a problem to you). An HTTP 
handshake negotiation leading to CoAP end-to-end using UPGRADE is 
comparatively small in terms of network packets exchanged, and is almost 
insignificant for long-lasting CoAP over TCP (or Websocket) sessions.

Regards,
Bill