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

[[e-mail]]

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]>; [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.