Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

From: "weigengyu" <[email-masked]>
Date: Tue, 2 May 2017 13:31:27 +0800

Hi all, 

Transfering CoAP defined in -08 draft for reliable transmission facilities is as important as CoAP over CON/NON message. 
In -08 draft, it is just clear how to make a new message for tranfering over TCP, 
or other reliable facilities in the scenario (I) CoAP/UDP ---> (C2C) Proxy ----> CoAP over TCP. 
But in -08 draft it is unclear how to work for the scenario (II) CoAP/TCP ---> (C2C) Proxy ----> CoAP over UDP. 

The problem is when the C2C Proxy have got a message form the CoAP/TCP side, 
how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP? 
Even for the scenario (I), the problem is the same when delivering the CoAP response.

In these scenarios a key problem is that should the CoAP semantics be End-to-End or Hop-by-Hop when a C2C proxy is existed. 

Regards, 

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

From: Yoshifumi Nishida 
Sent: Sunday, April 30, 2017 12:24 PM
To: Brian Raymor 
Cc: [email-masked] ; Yoshifumi Nishida ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hello, 
As far as I've read -08 draft, I think this point has not been addressed yet. I hope some folks could elaborate a bit more if they think this is not an important point for the draft.
--
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <[email-masked]> wrote:

  I think that I understand your perceptions better. Prior to adoption of coap-tcp-tls and before I was active in the WG, I recall discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. What was intended?

  Tim Carey outlined some concerns in:

  https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2

  This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23.

  And in a related thread on the mailing list back in 2015 - https://www.ietf.org/mail-archive/web/core/current/msg06280.html - Carsten responded:

  > In any case, CON and NON are about message layer semantics, not about application semantics

  > -- you gave them a meaning they don't have. 

  By IETF 94, the authors were reporting – “Most of the Confusion around              CON/NON was resolved”. 

  Where relevant, I’ve added clarifications - such as the Appendix related to differences in Observe for reliable transports.

  Both Carsten and Hannes could probably offer more context if needed.

  From: Yoshifumi Nishida [mailto:[email-masked]] 
  Sent: Friday, April 21, 2017 2:08 PM
  To: Brian Raymor <[email-masked]>
  Cc: Yoshifumi Nishida <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
  Subject: Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07

  Hi Brian,

  Just in case,

  Reliable transports only provide reliability at transport level. It doesn't provide reliability in application protocol level. 

  RFC7252 has reliability mechanisms in it since it uses UDP. This means it has abilities to check both transport and app level reliability.

  This draft only provides transport level reliability and apps will need to detect app protocol failure by themselves. 

  This means 7252 and this draft are not totally equivalent from the viewpoint of applications. 

  I am not saying this is wrong or bad, but I believe app developer should aware this point.

  --

  Yoshi

  On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <[email-masked]> wrote:

    Hi Yoshi,

    > OK. I also think we should state that the protocol should notify the failure events to applications. 

    > Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not 

    > be enough.

    After reviewing with the authors, an additional clarification was appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

    The opinion of the authors (and Gengyu WEI’s recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that RFC6455 covers the WebSocket case and does not need to be repeated here.

    > When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol

    > provides such things. 

    RFC7252 provides timeouts and retries because it's implementing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

    > However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that

    > there need to be some guidance here.

    > BTW, PONG is one example.

    For coap-tcp-tls, there are multiple early implementations. This has never been reported as a source of confusion. 

    >> My sense is that we should treat this as an update to RFC7959 based on the original language:

    > I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people.

    I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

    Thanks again for helping us to improve the quality of the draft,

    …Brian

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 May 2017 08:01:22 +0200

> how the Proxy make a decision to delivery CON or NON message carrying CoAP over UDP? 

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a reliable transport protocol), should the proxy use CON or NON for the forwarded request?

I’d say, in both cases, CON should be the default way of forwarding the reliable request.
But there may be specific cases where a NON may be appropriate — CoAP does not provide the client with a way to control the proxy here.

Is that a problem?  Tell me more about your use case.

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Tue, 2 May 2017 14:11:33 +0800

Hi，

> The question is not very different from the UDP to UDP proxying case.
Something is different.

> If a request came in via a UDP CON (which is the equivalent of using a 
> reliable transport protocol),
> should the proxy use CON or NON for the forwarded request?
If it keeps the semantics end-to-end,  the proxy just forwards the message.
If it has the semantics hop-by-hop, the proxy can decide what type of 
message to transfer.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Carsten Bormann
Sent: Tuesday, May 02, 2017 2:01 PM
To: weigengyu
Cc: Yoshifumi Nishida ; Brian Raymor ; [email-masked] ; 
[email-masked] ; [email-masked] ; [email-masked]
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a 
reliable transport protocol), should the proxy use CON or NON for the 
forwarded request?

I’d say, in both cases, CON should be the default way of forwarding the 
reliable request.
But there may be specific cases where a NON may be appropriate — CoAP does 
not provide the client with a way to control the proxy here.

Grüße, Carsten

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 6 May 2017 22:48:44 -0700

> If it has the semantics hop-by-hop, the proxy can decide what type of

My interpretation for 5.2.3 in RFC7252 is CoAP layer can ignore the
preference of applications and alter the message type by its decisions. It
seems to me proxies can choose message types as they want.
--
Yoshi

> -----原始邮件----- From: Carsten Bormann

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 7 May 2017 22:17:55 -0500

Hi, Yoshi,

On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <[email-masked]>
wrote:

> Hello,
> As far as I've read -08 draft, I think this point has not been addressed
> yet. I hope some folks could elaborate a bit more if they think this is not
> an important point for the draft.
>

I've seen the subsequent e-mails in reply to yours, but it's not obvious to
me whether you think this point was addressed after reading those e-mails.

What do you think?

Thanks,

Spencer

>> I think that I understand your perceptions better. Prior to adoption of
>> coap-tcp-tls and before I was active in the WG, I recall discussions
>> related to the confusion over application vs transport reliability in CoAP
>> especially as related to CON and NON. What was intended?
>>
>>
>>
>> This topic was presented in detail at IETF 93 -
>> https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf -
>> starting on slide 23.
>>
>>
>>
>> And in a related thread on the mailing list back in 2015 -
>> https://www.ietf.org/mail-archive/web/core/current/msg06280.html -
>> Carsten responded:
>>
>>
>>
>> Where relevant, I’ve added clarifications - such as the Appendix related
>> to differences in Observe for reliable transports.
>>
>>
>>
>> *From:* Yoshifumi Nishida [mailto:[email-masked]]
>> *Sent:* Friday, April 21, 2017 2:08 PM
>> *To:* Brian Raymor <[email-masked]>
>> *Cc:* Yoshifumi Nishida <[email-masked]>; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> *Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
>>
>>
>>
>> Hi Brian,
>>
>>
>>
>> Just in case,
>>
>> Reliable transports only provide reliability at transport level. It
>> doesn't provide reliability in application protocol level.
>>
>>
>>
>> RFC7252 has reliability mechanisms in it since it uses UDP. This means it
>> has abilities to check both transport and app level reliability.
>>
>> This draft only provides transport level reliability and apps will need
>> to detect app protocol failure by themselves.
>>
>> > Since errors can happen not only in TCP, but also TLS and websocket
>> level, mentioning only TCP close or reset might not
>>
>> > be enough.
>>
>>
>>
>> After reviewing with the authors, an additional clarification was
>> appended to 3.4 Connection Health - https://github.com/core-wg/coa
>> p-tcp-tls/pull/140/files
>>
>>
>>
>> The opinion of the authors (and Gengyu WEI’s recent response -
>> https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is
>> that RFC6455 covers the WebSocket case and does not need to be repeated
>> here.
>>
>>
>>
>> > When we use 7252, I think applications basically don't need to
>> implement timeouts or retry mechanisms as the protocol
>>
>> > provides such things.
>>
>>
>>
>> RFC7252 provides timeouts and retries because it's implementing a
>> TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rf
>> c7252#section-2.1
>>
>>
>>
>> > However, when we use this one, it seems applications will need to have
>> such mechanisms. Isn't it a bit confusing? I am thinking that
>>
>> For coap-tcp-tls, there are multiple early implementations. This has
>> never been reported as a source of confusion.
>>
>>
>>
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>
>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 8 May 2017 12:52:20 +0800

Hi, 

A question related. 
It needs clarifying the CoAP End-to-End Semancetics for the following scenarios: 

1. CoAP EP1/UDP  ----> CoAP to CoAP Proxy  ----> CoAP EP2/UDP
2. CoAP EP1/UDP  ----> CoAP to CoAP Proxy  ----> CoAP EP2/TCP

The CoAP semantics including request/response and messages is defined in RFC7252. 
How the CoAP end-to-end semantics keep in a way among three cases. 

The CoAP end-to-end semancetics is required to keep 
  (1) between CoAP EP1 and CoAP EP2, 
  (2) or between CoAP EP1 and C2C proxy, and between C2C Proxy and CoAP EP2, 
       in another wors, the CoAP is hop-by-hop. 
  (3) or both (1) and (2).   

For (1), the proxy needs just to forward the message what received. 
For (2), the proxy needs to make a CoAP message by its decisions.
For (3), the proxy needs to have functions of (1) and (2) and to distinguish (1) from (2). 

I wonder which is required? What needs to support?  

Regards,

Gengyu WEI

From: Spencer Dawkins at IETF 
Sent: Monday, May 08, 2017 11:17 AM
To: Yoshifumi Nishida 
Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi, Yoshi, 

On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <[email-masked]> wrote:

  Hello, 

I've seen the subsequent e-mails in reply to yours, but it's not obvious to me whether you think this point was addressed after reading those e-mails.

What do you think?

Thanks,

Spencer

  --
  Yoshi

    Hi Brian,

    Just in case,

    --

    Yoshi

      Hi Yoshi,

      …Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 May 2017 09:31:00 +0200

Hi Spencer, 

I’m not Yoshi :-), but I just have started working on an update of
https://lwig-wg.github.io/coap/#rfc.section.6
with some of the new information that relates to CoAP over reliable; I hope that I will be able to push this during this week.

Note that CoAP over TCP/TLS/WS does address application layer acknowledgement beyond the request-response acknowledgement semantics by introducing the custody option of the PING/PONG signaling messages.  This may be useful in compensating the decrease of information available to the CoAP application as a result of moving some of the transport functionality into TCP.

Grüße, Carsten

> On May 8, 2017, at 05:17, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Yoshi,
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 8 May 2017 00:48:45 -0700

Hi Spencer,

I still expect to see some more comments on this point (my review point 2:)
I basically would like to see more explanations about how to avoid protocol
deadlock or some clarifications that this won't be an issue.
--
Yoshi

On Sun, May 7, 2017 at 8:17 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> I've seen the subsequent e-mails in reply to yours, but it's not obvious
> to me whether you think this point was addressed after reading those
> e-mails.
>
> What do you think?
>
> Thanks,
>
> Spencer
>
>
>> --
>> Yoshi
>>
>> On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <[email-masked]
>> > wrote:
>>
>>> RFC7252 has reliability mechanisms in it since it uses UDP. This means
>>> it has abilities to check both transport and app level reliability.
>>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 8 May 2017 00:49:05 -0700

Hi Carsten,

Great. I will take a look at it when it's published.
Thanks for the efforts!
--
Yoshi

On Mon, May 8, 2017 at 12:31 AM, Carsten Bormann <[email-masked]> wrote:

> with some of the new information that relates to CoAP over reliable; I
> hope that I will be able to push this during this week.
>
> Note that CoAP over TCP/TLS/WS does address application layer
> acknowledgement beyond the request-response acknowledgement semantics by
> introducing the custody option of the PING/PONG signaling messages.  This
> may be useful in compensating the decrease of information available to the
> CoAP application as a result of moving some of the transport functionality
> into TCP.
>
> Grüße, Carsten
>
>
>
> > This topic was presented in detail at IETF 93 - https://www.ietf.org/
> proceedings/93/slides/slides-93-core-0.pdf - starting on slide 23.
> >
> >
> >
> > Cc: Yoshifumi Nishida <[email-masked]>; [email-masked];
> appended to 3.4 Connection Health - https://github.com/core-wg/
> coap-tcp-tls/pull/140/files
> >
> >
> >
> https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that
> RFC6455 covers the WebSocket case and does not need to be repeated here.
> >
> >
> >
> TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/
> rfc7252#section-2.1
> >
> >
> >

---

From: "weigengyu" <[email-masked]>
Date: Mon, 8 May 2017 17:39:16 +0800

Hi, 

The clairification raised is my question. 

We did implement the protocol as the senarios described.
The problems were we met, not be thought out. 

I wish there will be an answer. 

Regards, 

Gengyu WEI

From: Yoshifumi Nishida 
Sent: Monday, May 08, 2017 3:49 PM
To: Carsten Bormann 
Cc: [email-masked] ; Yoshifumi Nishida ; [email-masked] ; Spencer Dawkins at IETF ; [email-masked] ; [email-masked] 
Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

Hi Carsten, 

  Hi Spencer,

  Grüße, Carsten