Subject: [core] https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 17 Jun 2015 18:16:56 +0000

Team,

I submitted a draft that collects my thoughts as well as several discussions we have had on the email reflector regarding the use of a standardized message layer. In addition several comments regarding tschofenig-core-coap-tcp-tls that we have been discussing over the last several months.

Here is the link to the document
https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

I would be happy to discuss this on the list and in Prague.

BR,
Tim

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2015 20:31:20 +0200

Thanks.  I'm reading section 5 as a set of editorial improvements that
are urgently needed for the coap-tcp-tls draft.

One question for that: what makes you say:
       TCP connections in the current draft are
       currently limited to a single Request/Response information
       exchange.  This limitation means that multiple TCP connections
       are needed for parallel information exchanges.  For example, an
       Observe/Notification information exchange would have to be on a
       different TCP connection as a simple Get request, causing
       multiple costly TCP connections to be established.

Request/response matching is via the token, so there is no problem at
all in having multiple requests active, and answered out of sequence, in
a single TCP connection.  (There is no equivalent of the HTTP
"pipelining" problem.)

Grüße, Carsten

Carey, Timothy (Timothy) wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 17 Jun 2015 19:09:30 +0000

Carsten,

Its really the question of the number of TCP sessions that will need to be established. I can't do say Get/temp Observe:0 and Get/foo at the same time - they would need separate TCP session. The use of message id that are valid across TCP sessions would make this possible - right?

BR,
Tim

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2015 1:31 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

Thanks.  I'm reading section 5 as a set of editorial improvements that are urgently needed for the coap-tcp-tls draft.

Request/response matching is via the token, so there is no problem at all in having multiple requests active, and answered out of sequence, in a single TCP connection.  (There is no equivalent of the HTTP "pipelining" problem.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2015 22:17:43 +0200

Carey, Timothy (Timothy) wrote:
> Its really the question of the number of TCP sessions that will need to be established. 
> I can't do say Get/temp Observe:0 and Get/foo at the same time - they
would need separate TCP session.

You just have to make sure these requests use different tokens -- that
is not different from what you need to do in UDP when making parallel
requests.

>The use of message id that are valid across TCP sessions would make
this possible - right?

Message-IDs allow you to have multiple retransmission sequences in
progress at the same time.  There is no need for retransmission in TCP
though.  So all you need to do is use a token for each request that is
not still active (i.e., is not waiting for a response, including
additional responses, a.k.a. notifications, for observe).

E.g. (assuming that it takes a second to read out the temp sensor):

-> token='' GET /temp Observe=0
-> token='a3' GET /foo
<- token='a3' 2.05 "foo is bar"
<- token='' 2.05 Observe=4711 {"e":[{ "n": "mytemp", "v":23.5, "u":"Cel"
}]}
-> token='b1' GET /foo
<- token='' 2.05 Observe=4778 {"e":[{ "n": "mytemp", "v":23.5, "u":"Cel" }]}
<- token='b1' 2.05 "foo is baz"
<- token='' 2.05 Observe=4892 {"e":[{ "n": "mytemp", "v":23.5, "u":"Cel" }]}
-> token='' GET /temp Observe=1
<- token='' 2.05 {"e":[{ "n": "mytemp", "v":23.5, "u":"Cel" }]}

For the first request, I have used the token '' (which I mean to say the
0-length token), which stays active as long as the observation for /temp
is registered at the server (here, it becomes free after the last
response).  The tokens 'a3' and 'b1' (which I mean to say two random
1-byte length tokens) are active until the response is in.  The second
request to /foo might as well use 'a3' as its token, because that became
free when the response came in.  But nothing is wrong with rotating
through a larger set of tokens, either.

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 17 Jun 2015 22:13:24 +0000

Carsten,

Yes - that is where Klaus and I left the discussion on the email thread.
If we can add the text to the draft from Websockets:
CoAP Request/Responses, which can  are exchanged asynchronously over the TCP connection, i.e., a CoAP client can send multiple requests without waiting for a response, and the CoAP server can return responses in any order. Responses MUST be returned over the same TCP connection as the originating request. Concurrent requests are differentiated by the Token, which is scoped locally to the TCP connection.

So what is being asked is inclusion of the above text to handle the long lived and parallel requests. 

BTW -we did see the Request/Response MUST be in the same session as an unnecessary constraint since a token should be all that is needed by an application to match requests and responses. However it looks like the constraint seems a fundamental implementation decision for CoAP over DTLS (section 9.1.2 of RFC 7252). I don't know if that’s really something we want to or even can relax. 

BR,
Tim

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, June 17, 2015 3:18 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

You just have to make sure these requests use different tokens -- that is not different from what you need to do in UDP when making parallel requests.

this possible - right?

Message-IDs allow you to have multiple retransmission sequences in progress at the same time.  There is no need for retransmission in TCP though.  So all you need to do is use a token for each request that is not still active (i.e., is not waiting for a response, including additional responses, a.k.a. notifications, for observe).

For the first request, I have used the token '' (which I mean to say the 0-length token), which stays active as long as the observation for /temp is registered at the server (here, it becomes free after the last response).  The tokens 'a3' and 'b1' (which I mean to say two random 1-byte length tokens) are active until the response is in.  The second request to /foo might as well use 'a3' as its token, because that became free when the response came in.  But nothing is wrong with rotating through a larger set of tokens, either.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 18 Jun 2015 09:38:54 +0800

Hi Tim, 

After reading your dradt, there are questions to be clarified.

> This draft discusses the need for a consistent messaging layer that
   can be used but the transport protocols as they adapt to the CoAP
   Request/Response layer. 

Is it an intention to define a new message layer which consists an transport-independent part and transport-spesific parts?

>3.  Standard Primitives vs Transport Specific Adaptation
>   If a standard set of primitives were used, each Transport protocol
   would document how to implement the CON and NON messages with ACK and
   RST responses.
 What is the “each Transport protocol”? Is it the adaption layer or transport layer (in Figure 3: CoAP Layers - Standard Primitives)? Regards,
Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Carey, Timothy (Timothy) 
Sent: Thursday, June 18, 2015 2:16 AM
To: [email-masked] 
Subject: [core]https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

Team,

BR,

Tim

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 18 Jun 2015 22:07:05 +0000

Gengyu,

My hope was that we could simply reuse the message layer already defined for UDP/SMS. The only new “primitive” I could even envision would be for the Timeout…

Each transport protocol is UDP, SMS, TCP, Websockets. We would have to decide if we want the same message layer interface between the transport protocol and the request/response layer or if we want each transport to specify how they would adapt to the Request/Response layer.

If we choose the same message layer – then each transport protocol would specify how it adapts to the message layer primitives.

Does this help?

BR,
Tim
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, June 17, 2015 8:39 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core]https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

Hi Tim,

What is the “each Transport protocol”?

Is it the adaption layer or transport layer (in Figure 3: CoAP Layers - Standard Primitives)?

Regards,

Gengyu WEI

From: Carey, Timothy (Timothy)<mailto:[email-masked]>
Sent: Thursday, June 18, 2015 2:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [core]https://www.ietf.org/internet-drafts/draft-carey-core-std-msg-vs-trans-adapt-00.txt

Team,

BR,
Tim
________________________________
_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core