Subject: [core] arriving at BERT for early block requests

From: Christian Amsüss <[email-masked]>
Date: Thu, 15 Mar 2018 15:32:06 +0100

Hello CoAP-over-TCP authors and working group,

during a RFC8323 interop, a question concerning BERT came up:

Can a request block operation (say, a large PUT) be conducted with BERT
by a TCP client without waiting for the CSM?

If the client does not wait for the server's CSM, it can't know the
Max-Message-Size, and whether the server indicates the
Block-Wise-Transfer capability. The only way to send the PUT right away
is to send an 1:(0/1/1024) regular block with szx=6.

The server then sends back its CSM (say, MMS=64k and supporting block).
Now who can take the started operation up to BERT? The server would send
2:(0/1/1024) acknowledging the first block, and the client preparing the
next block "SHOULD [...] use the block size preferred by the server or a
smaller one".

Is BERT an exception to that rule, and if so, is that written somewhere?

Or can such a transfer never become a BERT one, and clients with large
requests should take the time to wait for the CSM rather than save a
single round-trip and suffer the penalty of a dozens more due to limited
block sizes?

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Mar 2018 15:47:01 +0100

Hi Christian,

> On Mar 15, 2018, at 15:32, Christian Amsüss <[email-masked]> wrote:
> 

Indeed, the text 

   To avoid unnecessary latency, a Connection Initiator MAY send
   additional messages after its initial CSM without waiting to receive
   the Connection Acceptor's CSM; however, it is important to note that
   the Connection Acceptor's CSM might indicate capabilities that impact
   how the Connection Initiator is expected to communicate with the
   Connection Acceptor.  For example, the Connection Acceptor's CSM
   could indicate a Max-Message-Size Option (see Section 5.3.1) that is
   smaller than the base value (1152) in order to limit both buffering
   requirements and head-of-line blocking.

focuses on capability indications that restrict the defaults instead of the initiator charging ahead with using capabilities it hasn’t been presented yet.

> is to send an 1:(0/1/1024) regular block with szx=6.

Well, sending something the peer may not support is risky, but I wouldn’t say it’s outright forbidden.
Maybe the initiator still knows the CSM from the last time?  Maybe it’s just “feeling lucky”™?
(The peer cannot even check for premature use of capabilities as it probably already has sent the CSM and doesn’t know when that’ll have arrived.  Of course, when a capability is being used that is *not* present, the connection will not be successful.)

> smaller one”.

Increasing the block size during a transfer was not an objective of the block-wise protocol, so I don’t think that can be done.

> Is BERT an exception to that rule, and if so, is that written somewhere?

I don’t think so.

> Or can such a transfer never become a BERT one,

Once it is started with a smaller block size, it can’t.

> and clients with large

It is probably saner to just do this (except maybe when a cached CSM is available, but that would still be a bit of a gamble).

Do you have an example use case of opening a connection and then charging ahead with BERT without waiting for the CSM?

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 15 Mar 2018 16:01:54 +0100

I cannot speak for the authors, but as I have written my code, the first
block would be sent with an SZ of 6 and then subsequent messages would use
BERT.  It is written in part this way because I setup the first message to
be sent before I ever worry about trying to open the TCP session to the
server.

Jim

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Christian Amsüss
> Sent: Thursday, March 15, 2018 3:32 PM
> To: Core WG mailing list <[email-masked]>
> Subject: [core] arriving at BERT for early block requests
> 
> Can a request block operation (say, a large PUT) be conducted with BERT by
a
> TCP client without waiting for the CSM?
> 
> If the client does not wait for the server's CSM, it can't know the Max-
> Message-Size, and whether the server indicates the Block-Wise-Transfer
> capability. The only way to send the PUT right away is to send an
1:(0/1/1024)
> regular block with szx=6.
> 
next
> block "SHOULD [...] use the block size preferred by the server or a
smaller
> one".
single
> round-trip and suffer the penalty of a dozens more due to limited block
> sizes?
> 
> Best regards
> Christian
> 
> --

---

From: Jim Schaad <[email-masked]>
Date: Thu, 15 Mar 2018 16:53:33 +0100

Carsten,

> From: core <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Thursday, March 15, 2018 3:47 PM
> To: Christian Amsüss <[email-masked]>
> Cc: Core WG mailing list <[email-masked]>
> Subject: Re: [core] arriving at BERT for early block requests
> 
> Hi Christian,
> 
> > Can a request block operation (say, a large PUT) be conducted with
> > BERT by a TCP client without waiting for the CSM?
> 
> Indeed, the text
> 
> focuses on capability indications that restrict the defaults instead of the
> initiator charging ahead with using capabilities it hasn’t been presented yet.
> 
> > Block-Wise-Transfer capability. The only way to send the PUT right
> > away is to send an 1:(0/1/1024) regular block with szx=6.
> 
> (The peer cannot even check for premature use of capabilities as it probably
> already has sent the CSM and doesn’t know when that’ll have arrived.  Of
> course, when a capability is being used that is *not* present, the connection
> will not be successful.)
> 
> > 2:(0/1/1024) acknowledging the first block, and the client preparing
> > the next block "SHOULD [...] use the block size preferred by the
> > server or a smaller one”.
> 
> Increasing the block size during a transfer was not an objective of the block-
> wise protocol, so I don’t think that can be done.

Indeed, there is a requirement that the size be the same or smaller.  However I would question that this is a change of the block size if going from no BERT to BERT.  The block size is the same, one just have the ability to have a more efficient transfer.

If you started w/ a block size of 512 rather than 1024, then I would agree that BERT could not be triggered as the BERT document says that SZX can be changed in the middle of a transfer, but it can only be made smaller.

Jim

> > single round-trip and suffer the penalty of a dozens more due to
> > limited block sizes?
> 
> It is probably saner to just do this (except maybe when a cached CSM is
> available, but that would still be a bit of a gamble).
> 
> Do you have an example use case of opening a connection and then charging
> ahead with BERT without waiting for the CSM?
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 15 Mar 2018 18:54:13 +0100

Hi Carsten,

On Thu, Mar 15, 2018 at 03:47:01PM +0100, Carsten Bormann wrote:
> It is probably saner to just do this (except maybe when a cached CSM
> is available, but that would still be a bit of a gamble).
> 
> Do you have an example use case of opening a connection and then
> charging ahead with BERT without waiting for the CSM?

The cases I stumbled upon it was wget-style client tools.

The only realistic case that comes to my mind is registering with a
fresh connection on a known resource directory (where the representation
of .well-known/core is still fresh).

> Maybe the initiator still knows the CSM from the last time?

Given that CSMs have no formal persistence, that seems no more reliable
than Feeling Lucky in the first place -- the client would need to be
prepared to receive 4.0x Bad Option.

(For the matter of the not really increasing block sizes itself, Jim has
spoken my mind.)

Thanks
Christian