Subject: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 17 Apr 2015 20:16:02 +0000

Team,

Could someone confirm the number of TCP sessions that are established to send a Request/Reply using NON. If I look at the draft - I would suspect 2 TCP sessions needed established - 1 for the Request and 1 for the Reply

>From RFC 7252 Section 5.1

>From the TCP draft

Thanks in advance,
Tim

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 22:50:58 +0200

On 17 Apr 2015 at 22:16:32, Carey, Timothy (Timothy) ([email-masked]) wrote:
Could someone confirm the number of TCP sessions that are established to send a Request/Reply using NON. If I look at the draft – I would suspect 2 TCP sessions needed established – 1 for the Request and 1 for the Reply

One TCP connection (actually, the connection is what defines the endpoint pair).  The text from RFC 7252 you are citing is about how UDP is being used (which doesn’t have connections).

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 17 Apr 2015 21:16:57 +0000

So then how does one send Asynchronous Request / Asynchronous Reply in TCP? – This message exchange pattern is available in UDP and SMS…

BR,
Tim

From: Carsten Bormann [mailto:[email-masked]]
Sent: Friday, April 17, 2015 3:51 PM
To: Carey, Timothy (Timothy); [email-masked] WG
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

On 17 Apr 2015 at 22:16:32, Carey, Timothy (Timothy) ([email-masked]<mailto:[email-masked]>) wrote:
Could someone confirm the number of TCP sessions that are established to send a Request/Reply using NON. If I look at the draft – I would suspect 2 TCP sessions needed established – 1 for the Request and 1 for the Reply

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2015 23:22:12 +0200

On 17 Apr 2015 at 23:17:08, Carey, Timothy (Timothy) ([email-masked]) wrote:
So then how does one send Asynchronous Request / Asynchronous Reply in TCP? – This message exchange pattern is available in UDP and SMS…
I’m not familiar with these terms in the CoAP context, so I have a hard time answering.

(Everything in CoAP is asynchronous.  Responses are linked to requests using tokens, so there is no lockstep requirement.  But I’m probably really not understanding the question.)

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 17 Apr 2015 21:31:42 +0000

Carsten,

Yes that is how we see it as well but if you hold the TCP session waiting for the Response that defeats the purpose of the token – right? Maybe I am missing something here.

BR,
Tim

From: Carsten Bormann [mailto:[email-masked]]
Sent: Friday, April 17, 2015 4:22 PM
To: Carey, Timothy (Timothy); [email-masked] WG
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

On 17 Apr 2015 at 23:17:08, Carey, Timothy (Timothy) ([email-masked]<mailto:[email-masked]>) wrote:
So then how does one send Asynchronous Request / Asynchronous Reply in TCP? – This message exchange pattern is available in UDP and SMS…

---

From: "weigengyu" <[email-masked]>
Date: Tue, 21 Apr 2015 20:46:51 +0800

Hi Tim, 

It does not matter to hold TCP connection. 

A TCP connection can do one-way or two-way data delivery. 
the client can do one-way transfet when the client sends request to the server, and release the connection.  
Then the server setup another connection to deliver response.

But, the client often close the TCP connection half-way from the client to the serncer and hold the connection waiting for response
so as to reduce the overhead of setting up a new TCP connection.  

The request and response match by the CoAP token anyway.

It is likely to be application-dependent that using one TCP connection for request/response  or setting up another TCP connection for response.

Regards,

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

From: Carey, Timothy (Timothy) 
Sent: Saturday, April 18, 2015 5:31 AM
To: Carsten Bormann ; mailto:[email-masked] 
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Carsten,

BR,

Tim

Grüße, Carsten

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

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 21 Apr 2015 13:26:53 +0000

Gengyu WEI,

Thanks for the response.

My concern is that with UDP – the request is sent and all “resources” are cleaned up; then a reply is received and again the “resources” are cleaned up. In this case it would be up to a higher layer (e.g., message layer, request/response layer or application layer) to block any processing. The current CoAP specification leaves the decision for a non-blocking/blocking request/response mechanism to the application layer which is exactly what it should do.

In TCP we have different message behavior where the application layer cannot cleanly employ a non-blocking request/response unless in the draft of the specification.

Your proposal that you can break the TCP connection mid request/response has a couple of problems.
1) I actually want a response; however I do not want to tie up resources (sockets) between the request and response.
2) Having half open/closed TCP connections is generally not a good design practice you are stuck in the time wait problem.
3) Applications shouldn’t be concerned with manipulating the transport layer directly.

Makes sense?

BR,
Tim

From: weigengyu [mailto:[email-masked]]
Sent: Tuesday, April 21, 2015 7:47 AM
To: Carey, Timothy (Timothy)
Cc: Carsten Bormann; [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim,

Regards,

Gengyu WEI

From: Carey, Timothy (Timothy)<mailto:[email-masked]>
Sent: Saturday, April 18, 2015 5:31 AM
To: Carsten Bormann<mailto:[email-masked]> ; mailto:[email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Carsten,

BR,
Tim

From: Carsten Bormann [mailto:[email-masked]]
Sent: Friday, April 17, 2015 4:22 PM
To: Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]> WG
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 22 Apr 2015 22:56:01 +0800

Hi Tim, 

I have got some troubles to understand.

> My concern is that with UDP – the request is sent and all “resources” are cleaned up; then a reply is received and again the “resources” are cleaned up. 
What do you mean all resources? 
Are the resources CoAP servers or  things that a CoAP server attached with?  
If that all “resources” are cleaned up, who is responsible for reply? 

>In this case it would be up to a higher layer (e.g., message layer, request/response layer or application layer) to block any processing. 
What do you mean to block any processing?  
UDP delivers Datagram, CoAP message delivers message with CON or NON, a request invokes the receiver to process and reply. 
Does “to block any processing” means to give up receiving message, or abort to process the request?

> The current CoAP specification leaves the decision for a non-blocking/blocking request/response mechanism to the application layer which is exactly what it should do.
What do you mean non-blocking/blocking request/response mechanism here? 
Searching RFC7252, there is no such a description.

Regards.

Gengyu WEI

From: Carey, Timothy (Timothy) 
Sent: Tuesday, April 21, 2015 9:26 PM
To: weigengyu 
Cc: Carsten Bormann ; [email-masked] 
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,

Tim

Hi Tim, 

Regards,

Gengyu WEI

Carsten,

BR,

Tim

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 23 Apr 2015 13:53:23 +0800

Hi Tim, 

Sorry I misunderstand “to block any processing”.
It mean the block transfers, that is related to “Blockwise transfers in CoAP”. 

Yes, it is the application to determine whether to do block transfers.
But what the application depends on to make the decision?
>From the viewpoint of network, it should be MTU. 
The MTU limits the size of UDP and CoAP message.
So, The size of CoAP message limits the size of block, and further the block size can be negotiated beween CoAP client and server.

>In TCP we have different message behavior where the application layer cannot cleanly employ a non-blocking request/response unless in the draft of the specification.
MTU also  limits the size of TCP segment. 
If needed, one CoAP message can be sent in one TCP segment. 

> 1) I actually want a response; however I do not want to tie up resources (sockets) between the request and response.

The response matches with a request by the token. 

If not “to tie up resources (sockets) between the request and response’, 

to set up another TCP connection for the response.

> 2) Having half open/closed TCP connections is generally not a good design practice you are stuck in the time wait problem.

When data delivery is halp duplex, you can keep a two-way connection. 

Otherwise, half open is an alternative.  

>3) Applications shouldn’t be concerned with manipulating the transport layer directly.

Refer to HTTP Header Keep-alive, it is used to inform the TCP to keep or diconnect the connection. 
It is well accepted.  And such a mechanism is also related to Web-socket.

Regards,

Gengyu WEI

From: weigengyu 
Sent: Wednesday, April 22, 2015 10:56 PM
To: Carey, Timothy (Timothy) 
Cc: [email-masked] 
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim, 

Regards.

Gengyu WEI

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,

Tim

Hi Tim, 

Regards,

Gengyu WEI

Carsten,

BR,

Tim

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Apr 2015 08:55:38 +0200

> The MTU limits the size of UDP and CoAP message.

(Talking about the UDP case:)
That is indeed an area where the current IPv6 architecture doesn't
provide as much help as one would like it to.  The MTU is not
necessarily a good choice, in particular when hops with adaptation layer
fragmentation are involved.

The problem is mitigated a bit by the fact that usually a constrained
network with a preference for small packets is the last (incoming) or
first (outgoing) hop to a constrained node, so this node may have more
insight into good packet size choices than the network as a whole is
able to provide.  Using -block, this node can then communicate its
choice to a peer.

A while ago, I have proposed a way to get more (and more detailed)
information out of the network:
https://tools.ietf.org/html/draft-bormann-intarea-alfi-04
Earlier drafts of that had the problem that IPv6 hop-by-hop options tend
not to traverse the general Internet intact.  So I came up with a
SPUD-like alternative solution in -04 (see its section 5:
https://tools.ietf.org/html/draft-bormann-intarea-alfi-04#section-5
).  With (the real) SPUD now being looked at for communication to
middleboxes in general, that basic approach might actually go forward later.

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 23 Apr 2015 16:51:22 +0000

Gengyu,

Sorry I have been searching for the right terminology but a picture is worth a thousand words they say – so I attempted to depict my question.

If I have 3 exchanges between a CoAP client and server.
Based on Carstens comment in a prior response:
“One TCP connection (actually, the connection is what defines the endpoint pair).”

I would expect the 3 tcp sessions for the following:

If I follow RFC 7252 section 5.1 (which Carsten said was for UDP). It would look like:

We also have applications where the client/server would have a long lived TCP session span multiple information exchanges.

Really shouldn’t we in the draft allow any of these scenarios – maybe I am missing something.

Thanks,
Tim

From: weigengyu [mailto:[email-masked]]
Sent: Thursday, April 23, 2015 12:53 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim,

Regards,

Gengyu WEI

From: weigengyu<mailto:[email-masked]>
Sent: Wednesday, April 22, 2015 10:56 PM
To: Carey, Timothy (Timothy)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim,

Regards.

Gengyu WEI

From: Carey, Timothy (Timothy)<mailto:[email-masked]>
Sent: Tuesday, April 21, 2015 9:26 PM
To: weigengyu<mailto:[email-masked]>
Cc: Carsten Bormann<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,
Tim

Cc: Carsten Bormann; [email-masked]<mailto:[email-masked]>

Hi Tim,

Regards,

Gengyu WEI

Carsten,

BR,
Tim

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 23 Apr 2015 19:11:01 +0200

Hi Tim,

> Really shouldn’t we in the draft allow any of these scenarios – maybe I am missing something.

the CoAP-over-WebSockets draft [1] (which I believe also captures the
intended behaviour for CoAP-over-TCP) currently has the following
text:

   CoAP requests and responses are exchanged asynchronously over the
   WebSocket 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
   connection as the originating request.  Concurrent requests are
   differentiated by the Token, which is scoped locally to the
   connection.

Does that help?

Klaus

[1] https://tools.ietf.org/html/draft-savolainen-core-coap-websockets-04

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 23 Apr 2015 18:49:00 +0000

Klaus,

Very close - this wording takes into account the multi request/response scenario.
However the text
" Responses MUST be returned over the same
   connection as the originating request.  "

wouldn't allow for the scenario where I want to send a request in one session and receive the response in a different connection. - Which is the behavior of the UDP "session".

Is there any reason why that constraint exists? Is it because there is an expectation that the Token would be unique (scoped) to a particular connection? I thought it would be endpoint based.

BR,
Tim

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Thursday, April 23, 2015 12:11 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim,

> Really shouldn’t we in the draft allow any of these scenarios – maybe I am missing something.

the CoAP-over-WebSockets draft [1] (which I believe also captures the intended behaviour for CoAP-over-TCP) currently has the following
text:

Does that help?

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 23 Apr 2015 21:14:24 +0200

> Is there any reason why that constraint exists? Is it because there is an expectation that the Token would be unique (scoped) to a particular connection? I thought it would be endpoint based.

It's consistent with what CoAP defines for DTLS sessions [1]:

   The following rules are added for matching a response to a request:
   The DTLS session MUST be the same, and the epoch MUST be the same.

   This means the response to a DTLS secured request MUST always be DTLS
   secured using the same security session and epoch.

It's also consistent with HTTP which allows multiple requests and
responses to be carried over a single connection, but not that a
response is carried over a different connection than the request.

Klaus

[1] http://tools.ietf.org/html/rfc7252#section-9.1.2

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 23 Apr 2015 19:47:27 +0000

Klaus,

So what you are saying is the a DTLS/UDP based Request/Response must be in the same DTLS session - correct?
I see that Observe Notifications have the same constraint.

Ok so yes your text in Websockets would solve the long lived TCP session that we need. 

Thanks for your help!

BR,
Tim 
-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Thursday, April 23, 2015 2:14 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

It's also consistent with HTTP which allows multiple requests and responses to be carried over a single connection, but not that a response is carried over a different connection than the request.

Klaus

---

From: "weigengyu" <[email-masked]>
Date: Fri, 24 Apr 2015 09:47:28 +0800

Hi Tim,

The scenarios depicted in your email are right to tell the problem related to CoAP over TCP. 
You try to give the traffic pattern between request and response. 

Such problems was happened when using HTTP1.0 (over TCP), and handled in HTTP1.1, and Websocket.

So, there maybe two alternatives considering CoAP over TCP,  
1. define a new or modified message format; as in draft-tschofenig-core-coap-tcp-tls-03 
2. define a new option; probably to learn something from http 1.0 or websocket.

Regards,

Gengyu WEI

From: Carey, Timothy (Timothy) 
Sent: Friday, April 24, 2015 12:51 AM
To: weigengyu 
Cc: [email-masked] 
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Gengyu,

 

 

 

 

Thanks,

Tim

Hi Tim, 

 

Regards,

Gengyu WEI

From: weigengyu 

Cc: [email-masked] 

Hi Tim, 

 

Regards.

Gengyu WEI

To: weigengyu 

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,

Tim

Hi Tim, 

Regards,

Gengyu WEI

Carsten,

BR,

Tim

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Fri, 24 Apr 2015 10:10:00 +0800

> fragmentation are involved.

I agree.
MTU just limits the largest size of PDU.
And it is short of standards to tell what is the fittest and most efficient.

To get efficient tranfer within a constrained network,
it is likely to get one application message into one data link frame.
But, the application has no way to have this cross layer information.

Maybe, it is required to define something as draft-bormann-intarea-alfi-04.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, April 23, 2015 2:55 PM
To: weigengyu
Cc: Carey, Timothy (Timothy) ; [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session 
Establishment

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Apr 2015 18:32:10 +0200

(I managed not to send this message out for a week, sorry.)

I stared at your message for a while and then found it that it seems we forgot to include this in RFC 7252:

If you draw a client-server picture, the client MUST always be on the left side.

But seriously:

The way the TCP binding is written at the moment, tokens are local to the TCP connection.
If you open a new connection, you have a clean slate.

Grüße, Carsten

On 23 Apr 2015 at 18:51:51, Carey, Timothy (Timothy) ([email-masked]) wrote:

Gengyu,

 

 

 

 

Thanks,

Tim

Hi Tim,

 

Regards,

Gengyu WEI

From:weigengyu

To:Carey, Timothy (Timothy)

Cc:[email-masked]

Hi Tim,

 

Regards.

Gengyu WEI

From:Carey, Timothy (Timothy)

To:weigengyu

Cc:Carsten Bormann ; [email-masked]

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,

Tim

Hi Tim,

Regards,

Gengyu WEI

From:Carey, Timothy (Timothy)

To:Carsten Bormann ; mailto:[email-masked]

Carsten,

BR,

Tim

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 30 Apr 2015 04:29:21 +0000

Carsten,

Thanks for the reply. So with this reply and the one from Klaus I can take away that, for TCP, we can have one or more request/reply exchanges within 1 TCP session. These request/reply session may or may not use the core block capabilities.

The only missing capability that exists in UDP but not TCP is the ability to issue the request in one “session” and receive the reply in another “session”.

I am going to go through the list archives and try and present a summary in IETF 93 of what has been discussed over the last couple of months.

Thanks,
Tim

From: Carsten Bormann [mailto:[email-masked]]
Sent: Wednesday, April 29, 2015 5:32 PM
To: Carey, Timothy (Timothy); weigengyu
Cc: [email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

But seriously:

Grüße, Carsten

On 23 Apr 2015 at 18:51:51, Carey, Timothy (Timothy) ([email-masked]<mailto:[email-masked]>) wrote:
Gengyu,

Thanks,
Tim

Hi Tim,

Regards,

Gengyu WEI

From:weigengyu<mailto:[email-masked]>
Sent: Wednesday, April 22, 2015 10:56 PM
To:Carey, Timothy (Timothy)<mailto:[email-masked]>
Cc:[email-masked]<mailto:[email-masked]>
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Hi Tim,

Regards.

Gengyu WEI

From:Carey, Timothy (Timothy)<mailto:[email-masked]>
Sent: Tuesday, April 21, 2015 9:26 PM
To:weigengyu<mailto:[email-masked]>
Cc:Carsten Bormann<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Subject: RE: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Gengyu WEI,

Thanks for the response.

Makes sense?

BR,
Tim

Hi Tim,

Regards,

Gengyu WEI

From:Carey, Timothy (Timothy)<mailto:[email-masked]>
Sent: Saturday, April 18, 2015 5:31 AM
To:Carsten Bormann<mailto:[email-masked]> ; mailto:[email-masked]
Subject: Re: [core] draft-tschofenig-core-coap-tcp-tls-03 : TCP Session Establishment

Carsten,

BR,
Tim