[core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt
christian@amsuess.com Wed, 05 August 2020 14:24 UTC
Return-Path: <christian@amsuess.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 728783A09E7 for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 07:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 vhcI0Vu-dUeq for <core@ietfa.amsl.com>; Wed, 5 Aug 2020 07:24:38 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B403A09A2 for <core@ietf.org>; Wed, 5 Aug 2020 07:24:37 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 33E4240760; Wed, 5 Aug 2020 16:24:35 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BA7C9AB; Wed, 5 Aug 2020 16:24:33 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:947b:e942:281b:482c]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CCBF4180; Wed, 5 Aug 2020 16:24:32 +0200 (CEST)
Received: (nullmailer pid 3494816 invoked by uid 1000); Wed, 05 Aug 2020 14:24:31 -0000
Date: Wed, 05 Aug 2020 16:24:31 +0200
From: christian@amsuess.com
To: mohamed.boucadair@orange.com, "Jon Shallow (supjps-ietf@jpshallow.com)" <supjps-ietf@jpshallow.com>, "core@ietf.org" <core@ietf.org>
Message-ID: <20200805142431.GB3480705@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/"
Content-Disposition: inline
In-Reply-To: <26993_1595950051_5F2043D8_26993_392_1_787AE7BB302AE849A7480A190F8B93303150608A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <29030_1593429656_5EF9CE98_29030_149_1_787AE7BB302AE849A7480A190F8B9330314E8C6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/utIRdGJe2uZP9XE-WoVN9p8ezgg>
Subject: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt
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, 05 Aug 2020 14:24:40 -0000
Hello Med, hello Jon, here's a few concrete points I'd like to suggest for new-block: * Applicability: I'd have expected to read something like this in the introduction: > The block-wise transfer of [RFC7959] covers the general case, but > falls short in situations where packet loss is highly asymmetrical. > > The new options introduced here provide roughly similar features to > the Block1/Block2 options. They provide additional properties that > are tailored towards the intended use case, and leave out mechanisms > like non-atomic access and proxy support that would complicate their > description. > > They are not intended for general CoAP usage, and any use outside > the DOTS use case should be carefully weighed against the loss of > interoperability with generic CoAP applications. It is hoped that > experience gained with these options can go into future extensions > of the block-wise mechanism that are both generally applicable and > serve this particular use case. * Separation of layers, sub-topic "congestion control": It should be possible to phrase all congestion control parts of this in a dedicated section (which may also make sense as an appendix). I'd avoid all other mentions of things like PROBING_RATE: For example, Section 3.4 right in the middle of a paragraph on re-requesting missing blocks states that > The rate of requests for missing blocks is subject to PROBING_RATE. Yes it is, but so is every single CoAP request until the client hears back from the server. Repeating these things in places where are not a new requirement may make it easier for some implementers that try to build the whole stack in a single go, but even for them is prone to the authors missing a spot -- and for everyone else this will each time trigger the question of "is this new here or isn't this already handled by a component two layers down the stack?". I haven't tracked every single retransmission and rate limiting statement throughout the document, but I expect that this section could boil down to something like > For the DOTS use case, the following default CoAP parameters are > updated to better reflect the typical deployments: > > * PROBING_RATE: 10 kilobyte/second > > The averaging process mentioned in RFC7252 Section 4.7 after which > PROBING_RATE applies is not fully defined there. For the above > applications, a new parameter PROBING_RATE_WINDOW is introduced. > Messages up to a total size of PROBING_RATE_WINDOW may be sent > before PROBING_RATE is considered, and the probing rate may > generally be exceeded by that amount of data in short term. > > * PROBING_RATE_WINDOW: 15 kilobyte (The latter replaces MAX_PAYLOADS, and I'm not sure whether it is better to express this in terms of package count or bytes on the wire, just giving an example here. All numbers in the above were pulled out of uninformed air.) * Separation of layers, sub-topic "Tokens": Same thing, next layer. Whenever you're tempted to talk of a token, consider some of these replacement phrases as a first step: * "MUST be sent with a new token" -> "is a new request". * "Tokens MUST be included" -> (nothing -- transports use tokens by construction) * "MUST be sent with the same token as the response" -> "is sent as a response to" / "is sent as an additional response to that request". (Here it may make sense to refer to the tokens in an additional " (which means it uses the same token, the same way an observation response uses the requests's token for multiple responses)"). * Naming: It's technically a minor thing, but people have already complained to me about how hard the Block[12] names are to comprehend, and introducing these options as Block[34] would not help here. I'd like to suggest QuickBlock-Block[12]. (I know that this part of designing a new option is annoying. In the interest of winding up with something that can be learned easily, it is unfortunately essential). In connection with that, it may make sense to briefly think about a draft name before it is submitted as a WG draft. new-block sounds like a 7959bis, which in my understanding this does not aim to be. * 4.TBA3 Missing Payloads: I don't quite see why this needs a distinct code. 4.08 Request Entity Incomplete sounds perfectly suitable to me. If you think that sending an existing 4.xx code in the middle of a block-wise transfer would cancel the transfer, there's still two ways out of this: * You're just defining what a block-wise transfer is; just allow it. (In a RFC7959 block-wise transfer that runs over a proxy, the proxy may be currently incapable of doing any forwarding and return 5.03 Service Unavailable Max-Age:5. The client would then just pause 5 seconds and send the latest block again.) * For all but the last block, it may also be an option to send it as a payload to a 2.31 code -- I don't think that would be outright forbidden (and at any rate, all involved clients speak the protocol anyway). * The draft describes this all as "just working through a proxy" -- original block-wise does not, and I'd like to hear how this is hoping to get away without the options being proxy-unsafe. Is there any point at all in using block-by-block proxying for these use cases? Unless a proxy is sitting right inside the link under attack, and unless the bodies get huge, it may be way easier for this to be purely hop-by-hop. Proxies would reassemble the full bodies and, for the next hop, just decide what works best there (be it regular block-wise, Block34 or BERT). (If there's a point in allowing block-by-block forwarding, we can talk it through and work through the initial ideas that will come up like "We use large enough Request-Tag values so they are unique", "how large does that need to be", "why do we end up having a Request-Tag in every request now" and "why do we not want that", but my gut feeling is we won't need to go there.) Kind regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] core-block-04: Applicability and general r… christian
- Re: [core] core-block-04: Applicability and gener… supjps-ietf
- Re: [core] core-block-04: Applicability and gener… christian
- Re: [core] core-block-04: Applicability and gener… mohamed.boucadair
- Re: [core] core-block-04: Applicability and gener… mohamed.boucadair
- Re: [core] core-block-04: Applicability and gener… supjps-ietf