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

Fredrik Wegelid <fredrik.wegelid@wittra.se> Wed, 26 June 2019 11:57 UTC

Return-Path: <fredrik.wegelid@wittra.se>
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 482C4120283 for <core@ietfa.amsl.com>; Wed, 26 Jun 2019 04:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=wittra.se
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 fvH9hhHN3wqg for <core@ietfa.amsl.com>; Wed, 26 Jun 2019 04:57:44 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB20120033 for <core@ietf.org>; Wed, 26 Jun 2019 04:57:44 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id h10so1916283ljg.0 for <core@ietf.org>; Wed, 26 Jun 2019 04:57:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wittra.se; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yfS0wgTUCmMesD8vi8BLpPfl1zWLn64nK0tC/lJVM28=; b=ir+58Mvl8YbWJGRBgQ3jT67l3GT4oXOpcK3Tx5l0epZi0Dshcb+Svv1Cgz+z00L0PT tiYoU2sGB4t3Xpx3ugZAYjnnxA1rWy//ILWI8lJfrL5qLJUd1f5HRePDXG0ZkW0mLrxV jn+tl4UhV0JnaNPGzkyDRFEBZ5l6hUFAagSEM3Kr/DK2wPr0GW/BAndWHY42TvK2cgUN 5PAWvM53aaIai56Of13XinbFcEm8ZZzzWVG18FjmUERBzdA+aTIsYB+chcT9WUhgtyv0 hvnGvW90TWQjAwC1phTA9JmT7/td37eIFc7A2BYuQh8fSjhLQQ1zBO2D4pnn/HUDtH5v l6Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yfS0wgTUCmMesD8vi8BLpPfl1zWLn64nK0tC/lJVM28=; b=XFU8TtU8+/YoLKFwv12IcAVx7oid0rITTJ00/NTCSkVpVZY3NcX+L8SCNg+8r5M0EN LwsVwM3vPUkfgh4PAdJgfGMrqP4sQSFfvccc1eHpWbE9xtvMi7mgvs1qhGQdB+dSeyuD XypQUWDG0ZS43SAfJLI4X/mvW6cAUyz8xYASkD1/sJ80vMUGhIW0mKvmytZJ5LrqaKhP 10LwK/Uye0EqbcR8x3HiIYy4LRFrzX3S0Ijg+EoPASuEhhlyaaQQtayNnXTn8baIRGm3 p3nZnmrY99K1vDaLYailNXuiGxlO7WfNI0ZnTOTZxrEISTsPYd7tJp+VnHCb0RIh1lIu IUKA==
X-Gm-Message-State: APjAAAXYeqgfNnc0M/dHN9QcyUjpVYlXocVxj8OGqToR5NFtllW+RuSP HV92ld7fbusRTbRnNxqnMFo/Qw==
X-Google-Smtp-Source: APXvYqzGj9eB1BYs8S2zArmJntm5Y7G3unCVRV4dg6JDJZi57e1m4u22jjlBWaXIL2boYsvl+F4rJg==
X-Received: by 2002:a2e:3a05:: with SMTP id h5mr2731087lja.114.1561550262431; Wed, 26 Jun 2019 04:57:42 -0700 (PDT)
Received: from sannas-ipad.localdomain (h-206-4.A137.corp.bahnhof.se. [176.10.206.4]) by smtp.gmail.com with ESMTPSA id h78sm998414ljf.88.2019.06.26.04.57.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 04:57:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Fredrik Wegelid <fredrik.wegelid@wittra.se>
In-Reply-To: <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org>
Date: Wed, 26 Jun 2019 13:57:40 +0200
Cc: core <core@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <33FF3DB7-076E-4A2A-BF64-9240406D1927@wittra.se>
References: <95486C6F-A08A-487E-974B-5692D474C06B@wittra.se> <135E11E6-07C7-471B-B2F9-94F875191199@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jQd6eijEW-zJFKLytIZz4SuNgQA>
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: Wed, 26 Jun 2019 11:57:47 -0000

Hi Carsten,

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

Client -> Server: 	NON POST Payload: “Block 1...”
Server -> Client:	NON 2.31 Continue
Client -> Server: 	NON POST Payload: “Block 2...”
Server -> Client:	NON 2.31 Continue

More blocks…

Client -> Server: 	NON POST Payload: “Final block...”
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: “Block 1...”
Client -> Server: 	NON POST (No-Response:26) Payload: “Block 2...”

More blocks…

Client -> Server: 	NON POST Payload: “Final block...”
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’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’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 “Not interested in 2.31 responses”.  (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
>> 
>