Subject: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach

From: "core issue tracker" <[email-masked]>
Date: Sat, 26 Mar 2016 15:55:51 -0000

#396: L1 vs. L3 Encoding Approach

 Copy-and-paste from the mailing list:
 http://www.ietf.org/mail-archive/web/core/current/msg06905.html

 At the T2TRG meeting, which took place the two days before the IAB IOTSI
 workshop in Santa Clara, we met with various OIC/OCF guys and talked about
 ongoing IoT standardization work in the IETF/IRTF as well as in the
 OIC/OCF.

 We learned that they have selected a different solution approach for
 CoAP over TCP: we have selected option L1 from Section 4 of
 https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04
 and they have selected option L3.

 In an off-list mail exchange we also received information about the
 performance investigations they have done. Here is what we got:

 > For 4MB data, the transmission time is
 >
 >     1. CoAP over TCP L1 + BWT : 70 s
 >
 >     2. CoAP over TCP L3       : 1.7 s

 (BWT = Block-Wise Transfer)

 We have not taken the performance aspect of larger file transfers (e.g.,
 transfer of a 4MB firmware update) into account when we made the
 solution decision in Yokohama. The reason why the OIC/OCF take such
 large file transfers into account is because of their desire to use CoAP
 also for non-constrained devices.

 I believe it would be good to verify / analyse the performance analysis
 of the OIC/OCF guys.

 In particular, it would be reasonable to compare the performance of
 option L1 and option L3 from Section 4 of
 https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04  with
 a CoAP protocol stack, such as Californium and the mbed CoAP library.
 Carsten pointed out that L1 is limited to 64 KiB (which is further
 reduced by Block's current largest block size of 1 KiB in the analysis
 above), while L3 allows for larger payloads. Of course, we may not need
 to use Block Transfer in CoAP when we already use CoAP over TCP.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [email-masked]          |  [email-masked]
     Type:  other technical          |     Status:  new
 Priority:  major                    |  Milestone:
Component:  coap-tcp-tls             |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/core/trac/ticket/396>
core <https://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Mar 2016 17:38:41 +0100

>  also for non-constrained devices.

Actually, we did discuss larger transfers in Yokohama (although the word
"performant" only occurs once in the minutes, specifically where
Matthias reported on the IoTivity work).  The understanding was that an
extension to -block like draft-bormann-core-block-bert would reduce the
performance gap between a 16-bit (L1) and a 32-bit length (L3), if
needed.  The sentiment in the room was a bit against creating a dialect
of CoAP with much larger payload sizes than the ones recommended in
section 4.6 of RFC 7252, but we didn't really have much input on this to
work from.

So this particular question really reduces to:  Should CoAP be extended
to provide payload sizes well over 64 KiB over TCP, TLS?  (The
Websockets framing already provides the capability, up to 16 EiB.)

Grüße, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 29 Mar 2016 18:51:23 +0530

Hi,
The ongoing work on CoAP over Websockets  will be really useful so far as 
running CoAP in an enterprise network (with firewalls having port 
filtering) is concerned. Websocket does not add too much overhead as well. 
Running CoAP on TCP in the enterprise scenario still needs to raise 
special request to the network administrator to open ports. So, would 
really like to see the CoAP on Websocket work to mature. 

Is there any implementation available for this 
draft-savolainen-core-coap-websockets-06 please? 

The "CoAP on TCP" and "CoAP on Websocket" both fundamentally solve the 
problem of running CoAP on reliable transport. So both work should 
progress in tandem. May be it can be viewed like "CoAP over TCP" forming 
the generalization while "CoAP over Websocket" becoming a specialization 
with version determination and payload length identification off- loaded 
to Websocket mechanism. May be, the scenario of huge data transfer becomes 
a special case which gets well handled by the Websocket variant keeping 
the TCP-only variant less complicated. 

Regarding the reported results on block-wise transfer on TCP, I am 
assuming that both end points were connected over an all-TCP transport. In 
block-transfer the application layer flow-control mechanism makes every 
block transfer a closed loop exchange. That contributes to the overall 
latency as well. While running on  TCP-only transport probably we can do 
away with the application layer flow control mechanism and make the block 
transfers completely open-loop (NON + No-Response ?). (And BERT relieves 
us a bit on the fragment size constrains). The last block (M=0) should 
trigger a response from the server indicating the state of the request 
execution (assuming a PUT/ POST).
However, not sure if block-wise transfer will be required for a TCP-only 
transport between the end-points.

However, the following statement should have been modified a bit. 
>> Of course, we may not need to use Block Transfer in CoAP when we 
already use CoAP over TCP.
It may be relevant when we have all through TCP. Of course block-mode will 
be required with the TCP variant of CoAP in order to talk to the classical 
CoAP (I mean RFC 7252) end-point with constrains as nicely mentioned in 
section 4.1 of draft-ietf-core-coap-tcp-tls-01. 

Sorry if I have missed anything due to lack of attention to the chain of 
discussions on these topics.
 
Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

From:   Carsten Bormann <[email-masked]>
To:     [email-masked]
Cc:     [email-masked]
Date:   03/26/2016 10:09 PM
Subject:        Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding 
Approach
Sent by:        "core" <[email-masked]>

Grüße, Carsten

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

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you