Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP

Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> Thu, 27 June 2019 05:19 UTC

Return-Path: <prvs=074fe7ca3=abhijan.bhattacharyya@tcs.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4812006D for <core@ietfa.amsl.com>; Wed, 26 Jun 2019 22:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcs.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW7-HdkTQva5 for <core@ietfa.amsl.com>; Wed, 26 Jun 2019 22:19:45 -0700 (PDT)
Received: from indelg02.tcs.com (indelg02.tcs.com [203.200.109.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E2C12012E for <core@ietf.org>; Wed, 26 Jun 2019 22:19:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcs.com; i=@tcs.com; q=dns/txt; s=default2048; t=1561614996; x=1593150996; h=mime-version:in-reply-to:references:subject:from:to: message-id:date; bh=6+/zK5kk0Y5A0f2XoYR8S5u6MifNLKo1y0YdAnI5jXA=; b=SkQosXw0WI7AmtqwDLSCXUdq3FHs8tCwf+uwkOvlhEKpGwAc63R8jdhO MU8XZioxeAf8vPMTQudH1umbQmKtvBHdAYZ6WxHWwYlJ+44MbNH42pN1/ V6rRZEQ/hPz+0DX8aSJuhLVWyTPOI+HLyfnNT42TJTZq1xE5dHuR38dv/ LL/bsXO4GfwMe+6+SrzCi+fMyrqGhT885e67BpPhlNbb8IeTfBTkaO2Xc 8dxIujte9A2na3f2o/Sq7Q6h/33/1cVpXD5Y+REKXUiFjKD3GLOV6b2bF Nvjqerfq9yDiDMHeuj/abOowp6JUkIBrk9adCbrnafk6GWtqBEut2wf+c w==;
IronPort-PHdr: 9a23:8hQOMxLDwvauzC5nrtmcpTZWNBhigK39O0sv0rFitYgXKvT6rarrMEGX3/hxlliBBdydt6sezbOJ+PG6ESxYuNDd6SlEKMQNHzY+yuwu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk6nbVk9Kev6AJPdgNqq3O6u5ZLTfx9IhD2gar9uMRm6twrcutQIjYd4N6o8yBTFr39Wd+9LwW9kOU+fkwzz68ut4ZJv6Thct+4k+8VdTaj0YqM0QKBCAj87KW41/srrtRfCTQuL+HQRV3gdnwRLDQbY8hz0R4/9vSTmuOVz3imaJtD2QqsvWTu+9adrSQTnhzkBOjUk7WzYkM1wjKZcoBK8uxxyxpPfbY+JOPZieK7WYMgXTnRdUMlPSyNBA5u8b4oRAOoHIeZYtJT2q18XoRejGQWgGObjxzlVjXH0wKI6yfwsHg7F0wI6Hd0OvmnaotXrOqkRX+67y7XHwC7ZYP9Kwzrw8ozIfgw8rfyKQLl+cdDRyU4qFw7dklifsozlPzKX1usXtWiQ8vdtVeK1hG47twF+uCSgxsc2hYnThoMUykrL/jh+zYkvPtK4SE97Ydy+H5tWrS2VLIt2Tdk+Q2F0oik11r0GtoShfCkKyJUo3QXSa+CbfIiT+B7sSOGRITJhiX9jZbmxiRGy8U26xe39UMm5yFdKoTRZktnCrHwN0AbT6sefRvth4kihwiyD2BzU6uFBJ00/iKnVK4Y5z7ItlJcfr17PEjHrlEnsgqKaaF8o9+ms5unhf77ovIWTN5VuhQH7Kqkun8u/DvkmPQUWRGib/Pi81KXk/U3kXLVGlv02nbfdsJDdPckVpba3DQFa3Igl8xixATSo3tcWk3cBNlxLfwyJgpT0N13WIfD4C+mwg0i0nTt2xf3KIKftDovQInTZnrrtY6xx5k9YxQYryNBQ/ZNUCrUPIPLpXU/xscTVAQUiPAy0wubnCs9y1oUEVW2UAq+WKr/SsUOS6e0zI+mDfpUVuTb9Kvc//PPukWM2mUQHcaa12psXbWi0Hu56LEWBfXrsntABHH8WsQo5VuzllkaPUT9NaHauUaIw/DY7CJipDY3bXICinKSB3DunHp1Rfm1JFkqDHmzvd4ifR/cNaSOSLtVmkjweWrirU5Uh2g22tA/m17pnKfLZ+iMCtZ39ydd1/ezTlRIo+T16Ecud3H+CT2V1nmwVXDI30qF/oVBhyleZy6d0medYGsIAr89OBykgOJLGzu8yNN39VwbAcp/dRkyrTs+nAncuQ908x94CS1l8B8m4h1bY0nzuS5QcjaeXCZp82KXG2nH3IY4pwH/M04E9nVhgRdFAYynujall+kCHDInTnm2YmrqkM6MG03ie2n2EyD+ntkFZUgd2GY/FVGwDb0DWpM7o90qKG7akCbUlOw0Hw86LNrdDYd3gl0RXTd//M8+YaGW0zTTjTS2Uz6+BOdK5M14W2z/QXQ1dy1ge
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AFAACWThRd/0UgFaxlGgEBAQEBAgEBAQEHAgEBAQGBVAQBAQEBCwGBZ4EZgSyEe5QdmGwUgWcJAQEBAQEBAQEBIAEKDAEBhEACgyA1CA4BAwEBBQEBAQEFAYsjDII6KQGCZgEBAQMBAQElQAcQCwUGDQQDAQIBJwcnHwkIBgEJAQgRCoMHAYF7HqQsAQEBgW4zhDYChD6BRoE0AYt/aA9+gRGDEj6BBIFdAQEDgSsBEgEJNoMYBIImBIwNJwOIV4cbjXcHAoIZXYV1hGSDeQWEWYIqhxKOGo0phzeRXgKBG3FwUIJsCYJEDAuDTYUUhUdqjGyCQwEB
X-IPAS-Result: A2AFAACWThRd/0UgFaxlGgEBAQEBAgEBAQEHAgEBAQGBVAQBAQEBCwGBZ4EZgSyEe5QdmGwUgWcJAQEBAQEBAQEBIAEKDAEBhEACgyA1CA4BAwEBBQEBAQEFAYsjDII6KQGCZgEBAQMBAQElQAcQCwUGDQQDAQIBJwcnHwkIBgEJAQgRCoMHAYF7HqQsAQEBgW4zhDYChD6BRoE0AYt/aA9+gRGDEj6BBIFdAQEDgSsBEgEJNoMYBIImBIwNJwOIV4cbjXcHAoIZXYV1hGSDeQWEWYIqhxKOGo0phzeRXgKBG3FwUIJsCYJEDAuDTYUUhUdqjGyCQwEB
X-IronPort-AV: E=Sophos; i="5.63,422,1557167400"; d="scan'208,217"; a="52150961"
MIME-Version: 1.0
Sensitivity:
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se>
References: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se>, <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org>
From: Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
To: Fredrik Wegelid <fredrik.wegelid@wittra.se>, Carsten Bormann <cabo@tzi.org>, core <core@ietf.org>
Message-ID: <OF6FE7EA39.5EF1BA5F-ON65258426.001AC7FC-65258426.001D278F@tcs.com>
Date: Thu, 27 Jun 2019 10:48:26 +0530
X-Mailer: Lotus Domino Web Server Release 9.0.1FP10HF213 April 26, 2018
X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:26, Serialize complete at 06/27/2019 10:48:27, Itemize by http on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:27, Serialize by Router on InKolM02/TCS(Release 9.0.1FP10HF213 | April 26, 2018) at 06/27/2019 10:48:30, Serialize complete at 06/27/2019 10:48:30
Content-Type: multipart/alternative; boundary="=_alternative 001D277165258426_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/y9W16NC8mKMRZHrehe_V_c3l_qc>
Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 05:19:49 -0000

Hi Fredrick and Carsten,
Thanks for the discussion so far. Let me put my thoughts.

The proposal to reduce the traffic in case of block-wise transfer using no-response is obvious. However, there is a catch. As per my understanding, the use case considered for block-wise transfer relates to transfers demanding high integrity of the received data and very low complexity at the receiving end in re-assembling the segments. One example is firmware upgrade of remote sensors: you cannot miss a single bit. Also, the message reception is tightly sequential in order. In case you miss one segment or receive in out-of-order, the transfers seizes in between.

Now, Fredrick, coming to your solution: I do not know the QoS requirements in your perceived use case. You do not care about responses of intermediate blocks (essentially this means RESTfully fire-and-forget!) and you take the response of the last block to ensure the end of transfer. Now the question is, if you care for all the blocks at the receiving end (for which you did not care for a response) how do you ensure reception of all the blocks? Considering the resource constrains in IoT use cases it will be a wastage of bandwidth if you have sent all the segments from the transmit end and the receiver, after receiving the end block, realizes that one intermediate segment got missing. The whole transfer, and the resource consumption related to that, becomes useless. You might have rather stopped at the loss instance and take corrective measures to resume. That would save your resources. So, there something more to think and design carefully according to the exact QoS requirements of the perceived class of use-cases.

However, in case you are looking for real-time + low-latency + low-resource consuming transfer, you may please have a look at this proposal that we already submitted few months back: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-02 . To relate this draft to your problem you may simply consider to model your block-wise traffic as a time-series traffic.

Having said that, I did once nurture some ideas to make block-wise transfer "statistically" more resource-efficient, yet reliable . But, must I be confirmed about the efficacy of my idea, both theoretically and experimentally, before I speak about that. I have kept that in back burner. In case there is enough interest I can renew the interest and discuss.

Thank you.     

With Best Regards
Abhijan Bhattacharyya
Consultant / Scientist,
{Internet Protocols | 5G | Standardization}, 
TCS Research,
Tata Consultancy Services
Building 1B,Ecospace
Plot -  IIF/12 ,New Town, Rajarhat,
Kolkata - 700160,West Bengal
India
Ph:- +91 33 66884691
Cell:- +919830468972 | +918583875003
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
Business Solutions
Consulting
____________________________________________


-----"core" <core-bounces@ietf.org> wrote: -----
To: Carsten Bormann <cabo@tzi.org>
From: Fredrik Wegelid 
Sent by: "core" 
Date: 06/26/2019 05:28PM
Cc: core <core@ietf.org>
Subject: Re: [core] RFC 7967 (No-Response) together with block-wise transfers in CoAP

"External email. Open with Caution"

Hi Carsten,

This is how an example looks like without the No-Response option.

Client -> Server: NON POST Payload: &#8220;Block 1...&#8221;
Server -> Client:	NON 2.31 Continue
Client -> Server: NON POST Payload: &#8220;Block 2...&#8221;
Server -> Client:	NON 2.31 Continue

More blocks&#8230;

Client -> Server: NON POST Payload: &#8220;Final block...&#8221;
Server -> Client:	NON 2.01 Created (As an example)

With the No-Response option I wish the exchange to look something like this:

Client -> Server: NON POST (No-Response:26) Payload: &#8220;Block 1...&#8221;
Client -> Server: NON POST (No-Response:26) Payload: &#8220;Block 2...&#8221;

More blocks&#8230;

Client -> Server: NON POST Payload: &#8220;Final block...&#8221;
Server -> Client:	NON 2.01 Created (As an example)

This would mean that the server would not send the 2.31 responses for each block (as the No-Response option is set to 26) while it still would send the final response (since the final block does not have the No-Response option set).
This allows the client to ensure that all blocks were sent successfully. If they are not, the server would respond with another code. It would also mean that the amount of traffic on the network is reduced.

Best regards,
Fredrik

> On 26 Jun 2019, at 13:43, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Hi Fredrik,
> 
> I&#8217;m not sure I entirely understand the message exchanges you envision; maybe you can provide an example.
> 
> RFC 7967 has a way to suppress responses based on the response code.
> Unfortunately, the granularity is on the class only at the moment.
> The option that carries this information isn&#8217;t explicitly defined as an extension point.  Still, someone (the original author?  The WG?) might want to go ahead, e.g., by defining a bit in the option value that says &#8220;Not interested in 2.31 responses&#8221;.  (Maybe we want to understand what exactly a client would not be interested in a bit more before we go ahead allocating bits like this.)
> 
> Abhijan, what do you think?
> 
> Grüße, Carsten
> 
> 
>> On Jun 26, 2019, at 13:30, Fredrik Wegelid <fredrik.wegelid@wittra.se> wrote:
>> 
>> Hi,
>> 
>> I hope that I am using this email list in the correct way. I apologise if that is not the case.
>> I have some questions/thoughts about using the No-Response option (RFC 7967) together with block-wise transfers in COAP.
>> 
>> In my team we are using CoAP to send messages from devices to a server. The messages are of such a size that we need to make block-wise transfers. In an attempt to reduce the amount of traffic in the network we have looked at using the No-Response option. We are however not clear on how this would work if used together with block-wise transfers. We would like to use the No-Response option to make the server omit the 2.31 Continue responses from the server on each block. We would however still like to be able to get a response on the last block to indicate the status of the entire block sequence. 
>> 
>> Does this make sense? In RFC 7967 block-wise transfers are not mentioned. Are they meant to be used together?
>> 
>> Best regards,
>> Fredrik Wegelid
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>> 
> 

_______________________________________________
core mailing list
core@ietf.org
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