Subject: [core] core-block-04: Applicability and general remarks draft-bosh-core-new-block-04.txt

From: [email-masked]
Date: Wed, 5 Aug 2020 16:24:31 +0200

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

---

From: <[email-masked]>
Date: Wed, 5 Aug 2020 21:01:19 +0100

Hi Christian,

Thanks for this review.  Med and I will update the draft as appropriate.

Otherwise, comments inline

Regards

Jon

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 05 August 2020 15:25
> To: [email-masked]; Jon Shallow (supjps-
> [email-masked]); [email-masked]
> Subject: core-block-04: Applicability and general remarks draft-bosh-core-
> new-block-04.txt
> 
> Hello Med, hello Jon,
> 

Jon> Thanks for the suggestions
>   section (which may also make sense as an appendix).

Jon> Good idea

>   handled by a component two layers down the stack?".

Jon> OK
>   just giving an example here. All numbers in the above were pulled out

Jon> My leaning is towards packet count - circuit speeds cover a significant
range. I need to think this through.
Jon> The default RFC7252 PROBING_RATE is too low in my humble estimation - a
large packet can cause long inter-packet gaps (300 bytes is a 5 minute
delay)
>     response uses the requests's token for multiple responses)").

Jon> Agreed - Token references needs to be tidied up.  Will work on this.
"additional" may help us here to clarify which token 'value' should be used
where.
>   I'd like to suggest QuickBlock-Block[12].

Jon> Certainly Block[34] are likely to transfer data more quickly than
Block[12].  However xxxx [12] implies a replacement for Block[12] which I am
not so sure about.

>   a 7959bis, which in my understanding this does not aim to be.

Jon> Good idea.
>   code. 4.08 Request Entity Incomplete sounds perfectly suitable to me.

Jon> As we have to define the diagnostic payload as containing the missing
blocks, we did not want to change the semantics of how 4.08 is used - hence
TBA3.

Jon> That said, a 4.08 response could contain 1 or more Block3 options but
that would take up more space.
>   block-wise transfer would cancel the transfer, there's still two ways

Jon> I was concerned about the 4.08 diagnostic payload changing format, but
yes, an 'unexpected' error code could terminate the transfer.
>     forbidden (and at any rate, all involved clients speak the protocol

Jon> I have an issue with changing the 2.31 reporting on the last successful
block received - this currently fails if block num of 0 is missing as we
cannot indicate block num = -1 has been received.
Jon> If the last block is received, but a previous one was not, a 2.31 could
be used to re-request the missing block, but a 2.01/2.04 would need to be
held back for the final block acknowledgement.
>   to get away without the options being proxy-unsafe.

Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12] when this
was written, but your comment implies that there is.  Certainly CoAP to
other protocol proxies could run into issues.

Jon> I was thinking of block by block proxying working and hence could be
proxy unsafe.
>   block-wise, Block34 or BERT).

Jon> Yes, there could be full body re-assembly and the full body held in
cache if needed.  This would add in a bit of latency.  However this would
restrict a Block[34] possibility of supporting streaming of data should that
be required.
>   is we won't need to go there.)

Jon> For Block3 which would use Request-Tag, I would expect that for a
specific body of data for a specific resource the Request-Tag to remain the
same - and if the body changes a new Request-Tag is used.
Jon> As this is the same Request-Tag for whether the whole body is cached,
or individual blocks of the body the Request-Tag usage will not change.
2^32 should be large enough - 2^64 even better - but re-usage has to be
generally considered.

~Jon

---

From: <[email-masked]>
Date: Thu, 6 Aug 2020 07:59:21 +0200

Hello Jon,

> Block[12].  However xxxx [12] implies a replacement for Block[12] which I am

I'd read Something-Block[12] more as a variaton on it, and Block[34] as
"the successors to Block12".

> blocks, we did not want to change the semantics of how 4.08 is used - hence

No, that's what media types are for. By putting in a Content-Format that
the client understands, you pick a (not the) representation of the error
situation (which, unlike in a situation where no Content-Format is
present, is not called a diagnostic payload, but just a payload, or some
representation of the error).

That payload is, by the way, a piece I'd be very happy to use outside
new-block as well. There's nothing that keeps a server from reporting
application/missing-blocks+cbor-seq in response to a Block2 (granted,
it'd a bit underspec'd there, but at least worth experimenting), so the
client could still try to send the missing blocks again.

> restrict a Block[34] possibility of supporting streaming of data should that

Unless DOTS has a use case for streaming data, I'd put that out of
scope. (This scope limitation is what'll allow us to get this done in a
reasonable time scale). And even if it were, that's not true: There
could still be contentual fast forwarding of parts (once the server has
a fresh representation of some of the resource, it could make it
available using the same or a different block-wise mechanism), just not
(potentially even proxy-safe) direct forwarding of the requests as they
are.

KR
c