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

[[e-mail]]

Hi All,

Some implementation notes on getting Quick-Block(1/2) up and running.

The implementation has been done using libcoap - where a lot of the RFC7959
block-wise handling was done by the application.  All the block handling has
now been moved down into libcoap (code not yet a part of libcoap, but will
be a PR) as a starting point for the draft-ietf-core-new-block
implementation.

Support of both Q-Block1 and Q-Block2

Currently, Q-Block1 and Q-Block2 can independently be supported (i.e. client
or server need only support one of them).  This made the detection of
whether the peer supported these options a bit more complicated - if the
client used both in a NON request, the resultant (optional) RST did not
indicate which option was not supported.  With a CON request, the 4.02
response is not clearly defined "5.4.1 This response SHOULD include a
diagnostic payload describing the unrecognized option(s)" as to how you can
determine which critical option it refers to.  Libcoap happens to return the
critical option(s) as options in the response, but I do not think that this
is universal.

For other implementations, it may be easier to mandate that both or none of
the options are supported by a CoAP agent (and would remove unnecessary code
in libcoap).

MAX_PAYLOADS

A design goal is that when using NON, it does not matter whether the body
fits in a single or requires multiple packets, the unidirectional sending of
the information does not require a response and it is recognized that there
may be some loss of receipt of the body.  With the current specification
there is an ACK_TIMEOUT wait (2s) every MAX_PAYLOADS (10) transmissions.
This works fine - large bodies are just bursty in their transmission.

Use of CON for the last of the MAX_PAYLOADS packet relies on there not being
an asymmetric traffic loss.  Use of CON every last of the MAX_PAYLOADS
packet does make the traffic considerably less bursty.

A thought moving forward for Q-Block1 is that on receipt of a NON
MAX_PAYLOADS packet that there is a 2.31 response (if all packets received)
or a 4.08 response indicating any missing packets (and possibly the next
packet in the sequence) so that the transmission of the next MAX_PAYLOADS
worth of packets is not delayed if response is received by the client.  If
the response does not get through, the ACK_TIMEOUT wait still stands.

Moving forward with Q-Block2 to reduce this burstiness is that if all the
packets have been received to date that the next packet in the sequence is
requested, else missing packets are reported on.  If the new request does
not get through, then the ACK_TIMEOUT wait still stands.

Q-Block2 implementation

The Q-Block2 was the easiest to implement.  However, working out how many
Q-Block2 can be fitted into a request packet for the missing blocks is not
that straight forward as the options with bigger block.num may require more
space.

A suggestion is to limit the number of missing Q-Block2 options to
MAX_PAYLOADS.  This also then ties in nicely with what a server can send at
once.

Q-Block1 implementation

a)

I really struggled with the CDDL definition for the payload of the 4.08
response and making sure that It was correct.   The cddl tool referred to in
RFC8610 is more focussed on JSON type structures (insisting that each object
is named) than pure CBOR.  The RFC8610 examples are JSON based - there is
reference to other RFCs that are CBOR based and their examples, but these
predate RFC8610 and (to me) of limited help.  It is still unclear to me that
the first line of the definition should use curly braces (as cddl tool
insists) or normal parentheses.  As an example, I am expecting the CBOR to
look something like
a2;   map(2)
  41;    byte(1) 
    01;  opaque request-tag - just happens to be 0x01 in this case
  83;    array(3)
    01;  uint missing-block-number
    02;  uint missing-block-number
    03;  uint missing-block-number
We also state "4. The data payload of the 4.08 (Request Entity Incomplete)
Response Code is encoded as a CBOR Sequence [RFC8742]". The array is
certainly a CBOR sequence, but is all of this structure a CBOR sequence?

As for Q-Block2, I think the array size of the CBOR should be limited to
MAX_PAYLOADS to ease the determination of the size of the payload, and make
it easier for the client to limit the number of packets sent at once.

b)

Using CBOR in the 4.08 payload means that libcoap needs to have some
knowledge about CBOR so I had to code in some simple code to cover this use
case.

c)

There are a lot of tokens to track.  With the current draft assuming that
each of the MAX_PAYLOADS packets is an individual request, this means that
there are MAX_PAYLOADS of tokens per multiple transmission that need to be
tracked.  It cannot be assumed that the last packet of the MAX_PAYLOAD set
will be received and that any response is against that last token.

In the same way that we have an "associated response" aka Observe that uses
the same token, would it be possible to have an "associated request" that
uses the same token to minimize token tracking and associated garbage
collection per singular body?

I would still expect any re-requested block (in 4.08 response) to be sent
with a different token and have to track that token as well.

Regards

Jon


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 23 September 2020 16:40
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: core-block-04: Applicability and general remarks
draft-bosh-core-
> new-block-04.txt
> 
> Hi all,
> 
> We proceeded with the publication of the candidate version:
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-01
> 
> FYI, Jon has now an implementation following this latest version of the
> specification. I let him share more feedback on the implementation.
> 
> Comments and suggestion are more than welcome, as usual.
> 
> Cheers,
> Jon & Med
> 
> > -----Message d'origine-----
> > De : core [mailto:[e-mail]] De la part de
> > [e-mail]
> > Envoyé : jeudi 10 septembre 2020 08:59
> > À : [e-mail]; [e-mail]; [e-mail]
> > Objet : Re: [core] core-block-04: Applicability and general remarks
> > draft-bosh-core-new-block-04.txt
> >
> > Hi Christian, all,
> >
> > We finally managed to prepare a candidate -01 of the draft that
> > hopefully addresses your review. The main changes are:
> >
> > * Update the Applicability Scope
> > * Remove the TBA3 (Missing Payloads), but use 4.08 instead
> > * The options are marked as unsafe. The caching behaviour is updated
> > * Move the CC text to a (new) dedicated section
> > * Avoid the normative language for the usage of Tokens. A new
> > (short) section is added for the token discussion.
> > * Rename the options to Quick-Block1/2
> >
> > We made other edits to enhance the readability of the document.
> >
> > The candidate version is available at: https://core-
> > wg.github.io/new-block/draft-ietf-core-new-block.txt
> >
> > A diff to track the changes can be seen here:
> > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-
> > ietf-core-new-block.txt&url2=https://core-wg.github.io/new-
> > block/draft-ietf-core-new-block.txt
> >
> > Please check the candidate version.
> >
> > Thank you.
> >
> > Cheers,
> > Jon & Med
> >
> > > -----Message d'origine-----
> > > De : [e-mail] [mailto:[e-mail]]
> > > Envoyé : mercredi 5 août 2020 22:01
> > > À : [e-mail]; BOUCADAIR Mohamed TGI/OLN
> > > <[e-mail]>om>; [e-mail] Objet : RE:
> > > core-block-04: Applicability and general remarks draft-
> > > bosh-core-new-block-04.txt
> > >
> > > Hi Christian,
> > >
> > > Thanks for this review.  Med and I will update the draft as
> > > appropriate.
> > >
> > > Otherwise, comments inline
> > >
> > > Regards
> > >
> > > Jon
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: 05 August 2020 15:25
> > > > To: [e-mail]; Jon Shallow (supjps-
> > > > [e-mail]); [e-mail]
> > > > Subject: core-block-04: Applicability and general remarks
> > > > draft-bosh-core- new-block-04.txt
> > > >
> > > > 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.
> > >
> > > Jon> Thanks for the suggestions
> > > >
> > > > * 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).
> > >
> > > Jon> Good idea
> > >
> > > >
> > > >   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?".
> > >
> > > Jon> OK
> > > >
> > > >   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.)
> > >
> > > Jon> My leaning is towards packet count - circuit speeds cover a
> > > Jon> significant
> > > range. I need to think this through.
> > > Jon> The default RFC7252 PROBING_RATE is too low in my humble
> > > estimation
> > > Jon> - a
> > > large packet can cause long inter-packet gaps (300 bytes is a 5
> > minute
> > > delay)
> > > >
> > > > * 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)").
> > >
> > > 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.
> > > >
> > > > * 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].
> > >
> > > 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.
> > >
> > > >
> > > >   (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.
> > >
> > > Jon> Good idea.
> > > >
> > > > * 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.
> > >
> > > Jon> As we have to define the diagnostic payload as containing the
> > > Jon> 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
> > > Jon> but
> > > that would take up more space.
> > > >
> > > >   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:
> > >
> > > Jon> I was concerned about the 4.08 diagnostic payload changing
> > > format,
> > > Jon> but
> > > yes, an 'unexpected' error code could terminate the transfer.
> > > >
> > > >   * 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).
> > >
> > > Jon> I have an issue with changing the 2.31 reporting on the last
> > > Jon> 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
> > > Jon> 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.
> > > >
> > > > * 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.
> > >
> > > Jon> I was not aware of CoAP to CoAP proxy issues with BLOCK[12]
> > > when
> > > Jon> 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
> > > Jon> be
> > > 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).
> > >
> > > 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.
> > > >
> > > >   (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.)
> > >
> > > 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
> > > Jon> 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
> > > >
> > > > Kind regards
> > > > Christian
> > > >
> > > > --
> > > > To use raw power is to make yourself infinitely vulnerable to
> > > greater
> > > > powers.
> > > >   -- Bene Gesserit axiom
> >
> >
> >
> _________________________________________________________________
> ___
> > _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > ce message par erreur, veuillez le signaler a l'expediteur et le
> > detruire ainsi que les pieces jointes. Les messages electroniques
> > etant susceptibles d'alteration, Orange decline toute responsabilite
> > si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender
> > and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that
> > have been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > core mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core
> 
> _________________________________________________________________
> ________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.