Re: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP Connections

[Hannes Tschofenig <[e-mail]>]

Hi Gengyu,

thanks for your input.

In the issue I added to the tracker I raised two issues, namely

1) "What should the CoAP over TCP state regarding the use of multiple
TCP connections?"

It seems you are arguing that nothing should be said about that topic.

2) "Should we recommend the use of Block-wise Transfer for large file
transfers and incorporate BERT into the CoAP over TCP draft?"

You didn't directly answer that question and I am curious what your
thoughts are.

Ciao
Hannes

On 05/04/2016 05:18 AM, weigengyu wrote:
> Hi,
> 
> The problem seems to be whether CoAP over Multiple Simultaneous TCP
> Connections needs considering in CoAP related drafts.
> 
> My suggestion is no.
> 
> There are many P2P communications adopts P2P/HTTP over Multiple
> Simultaneous TCP Connections.
> It is the P2P software to manage the multiple TCP connections, not HTTP.
> 
> Regards,
> 
> Gengyu WEI
> Network Technology Center
> School of Computer
> Beijing University of Posts and Telecommunications
> -----原始邮件----- From: core issue tracker
> Sent: Tuesday, May 03, 2016 4:39 PM
> To: [e-mail] ; [e-mail]
> Cc: [e-mail]
> Subject: [core] #409 (block): CoAP over TCP: Multiple Simultaneous TCP
> Connections
> 
> #409: CoAP over TCP: Multiple Simultaneous TCP Connections
> 
> CoAP has been designed to support small data transmissions. For device
> management it is, however, necessary to also deal with the transmission of
> larger payloads as well. Such larger payloads may be, for example,
> firmware/software updates.
> 
> The maximum payload size of CoAP is determined by the length field of the
> length field provided in the UDP header. It is ~64KB. For practical
> purposes the usable payload size is, however, much smaller due to
> performance issues introduced by fragmentation provided at the IP layer
> and/or adaption layers. For this reason the block-wise transfer mechanism
> has been defined.
> 
> Block-wise transfer is a mechanism that can be used to transfer larger
> payloads by chunking them into smaller parts (each part with a maximum
> size of 1024 bytes each). The block-wise transfer depends on CoAP and
> therefore uses the stop-and-wait defined in RFC 7252 (as a simple
> congestion control mechanism). The transfer of large payloads does,
> however, not block the transmission of other pending messages since they
> can easily be interleaved due to the nature of the block-wise transfer
> design.
> 
> When large payloads are transferred by CoAP over TCP then a large transfer
> blocks any other requests unless multiple TCP connections are opened. The
> question is therefore what should the CoAP over TCP state regarding the
> use of multiple TCP connections? Using multiple TCP connection increases
> RAM requirements; a single TCP connection introduces head-of-line
> blocking.
> 
> When CoAP over TCP is used with Block-wise transport in combination with
> BERT, see https://tools.ietf.org/html/draft-bormann-core-block-bert-00,
> then the previously described problem of large transfers that block other
> ongoing activities is (partially) mitigated. BERT changes the
> interpretation of the length information and changes it as a multiple of
> 1024 bytes (and thus increasing the size of the chunks).
> 
> The question is therefore whether CoAP over TCP should recommend the use
> of Block-wise Transfer for large file transfers and incorporate BERT into
> the CoAP over TCP draft.
> 
> (I would like to thank Achim Kraus for raising this issue during the OMA
> face-to-face meeting.)
>