IETF Logo Mail Archive

Re: [core] WG Last Call on draft-ietf-core-new-block

supjps-ietf@jpshallow.com Tue, 12 January 2021 15:26 UTC

Return-Path: <jon.shallow@jpshallow.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 F19EC3A03EB for <core@ietfa.amsl.com>; Tue, 12 Jan 2021 07:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 54rh3jkxZhVW for <core@ietfa.amsl.com>; Tue, 12 Jan 2021 07:26:03 -0800 (PST)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3D60F3A00C9 for <core@ietf.org>; Tue, 12 Jan 2021 07:26:02 -0800 (PST)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1kzLYW-0007jN-Nw; Tue, 12 Jan 2021 15:26:00 +0000
From: supjps-ietf@jpshallow.com
To: Marco Tiloca <marco.tiloca@ri.se>, christian@amsuess.com, draft-ietf-core-new-block@ietf.org
Cc: dots@ietf.org, core@ietf.org
References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <fa7956ae-31a3-7724-3af4-4e755a719045@ri.se> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <a549b34f-3f72-a6df-b2c3-ae9d3759b701@ri.se> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <f8774b5c-9736-1cff-266f-f9b66653a86c@ri.se> <065301d6e805$286163c0$79242b40$@jpshallow.com> <df2ee5a1-0d36-7f28-534d-42f2eb063040@ri.se> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se>
In-Reply-To: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se>
Date: Tue, 12 Jan 2021 15:26:10 -0000
Message-ID: <083c01d6e8f7$4137a420$c3a6ec60$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjUBa6IWcAGdmCj+Al0VD5oCSzuKDKg7hFnQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1E>
Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
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: Tue, 12 Jan 2021 15:26:07 -0000

Hi Marco and all,

Need clarity on how to do a (Q-)Block2 request for a specific block when the request needs (Q-)Block1.

Adding in the Observe option into Figures 11 & 12 caused other things to be updated (text is being updated) - e.g. the Observe option needs to be set on all of the Q-Block1 payloads making up the body.

However, I have run into not being sure what to do when a request needs Q-Block1 and the response needs Q-Block2 - and then we need to recover a missing Q-Block2 block.  Med and I have been discussing this offline. 

In the case of Q-Block1/Q-Block2 it is about what is the request needed to get a missing Q-Block2 block. In the case of Block1/Block2 it is all about the request needed to get the next Block2 block.

For whatever reason, a (Q-)Block2 block needs to be requested.  Given that the request has used (Q-)Block1 to handle the large body, do we just need to use the request method and matching options (with appropriate (Q-)Block2 NUM) without the payload, or do we have to use the payload as well and hence use multiple packets for the complete request?

If the server is caching the response, then a match can just be done on the cache-key if formed right.

If the server does not cache the response, then when using a FETCH, the FETCH will need to have the body to regenerate the response.

The closest I can find to this is in 2.7 rfc7959 which has

" In PUT and particularly in POST exchanges, both the request body and
   the response body may be large enough to require the use of block-
   wise transfers.  First, the Block1 transfer of the request body
   proceeds as usual.  In the exchange of the last slice of this block-
   wise transfer, the response carries the first slice of the Block2
   transfer (NUM is zero).  To continue this Block2 transfer, the client
   continues to send requests similar to the requests in the Block1
   phase, but leaves out the Block1 Options and includes a Block2
   request option with non-zero NUM."

In particular note the occurrence of the second "requests"  is plural in this line.
"   continues to send requests similar to the requests in the Block1
   phase"

This implies to me that there are multiple requests needed to make up the request with a full body to ask for a single block and that is the way to go - correct?

Secondly,

For a FETCH to cancel an Observe, again I can find no text giving clarity (as there are no references to payload), but have to assume that FETCH needs to be identical (apart from message id and Observe value which is now 1) including the payload - correct?

Regards

Jon

PS - We have worked out the wording for the 2.02 response.

> -----Original Message-----
> From: Marco Tiloca [mailto:marco.tiloca@ri.se]
> Sent: 11 January 2021 19:23
> To: supjps-ietf@jpshallow.com; christian@amsuess.com;
> draft-ietf-core-new-block@ietf.org
> Cc: dots@ietf.org; core@ietf.org
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi Jon,
> 
> Thanks for the fast reaction. Please, see inline.
> 
> Best,
> /Marco
> 
<snip>
> 
> As to the two new examples in Figures 11 and 12, please add the Observe
> option with value 0 to the requests from the client, i.e. O:0, just like you do
> in Figures 7 and 8.
> 
> Best,
> /Marco
> <==
>

v2.23.0 | Report a Bug | By Email