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

"weigengyu" <weigengyu@xxxxxxxxxxx> · 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: tsv-art@xxxxxxxx ; Yoshifumi 
Nishida ; draft-ietf-core-coap-tcp-tls@xxxxxxxx 
; core@xxxxxxxx ; ietf@xxxxxxxx 
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 <Brian.Raymor@xxxxxxxxxxxxx> 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:nishida@xxxxxxxxxxxxxx] 
Sent: Friday, April 
  21, 2017 2:08 PM
To: Brian Raymor <Brian.Raymor@xxxxxxxxxxxxx>
Cc: Yoshifumi 
  Nishida <nishida@xxxxxxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-core-coap-tcp-tls@ietf.org; core@xxxxxxxx; ietf@xxxxxxxx
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 <Brian.Raymor@xxxxxxxxxxxxx> 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
core@xxxxxxxx
https://www.ietf.org/mailman/listinfo/core