[core] arriving at BERT for early block requests

[Christian Amsüss]

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

[Carsten Bormann]

Hi Christian,

Post by Christian Amsüss
Hello CoAP-over-TCP authors and working group,
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

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.

Post by Christian Amsüss
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.

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.)

Post by Christian Amsüss
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”.

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.

Post by Christian Amsüss
Is BERT an exception to that rule, and if so, is that written somewhere?

I don’t think so.

Post by Christian Amsüss
Or can such a transfer never become a BERT one,

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

Post by Christian Amsüss
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?

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

[Jim Schaad]

Carsten,

-----Original Message-----
Sent: Thursday, March 15, 2018 3:47 PM
Subject: Re: [core] arriving at BERT for early block requests
Hi Christian,

Post by Christian Amsüss
Hello CoAP-over-TCP authors and working group,
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
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.

Post by Christian Amsüss
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.

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.)

Post by Christian Amsüss
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”.

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

Post by Christian Amsüss
Is BERT an exception to that rule, and if so, is that written somewhere?

I don’t think so.

Post by Christian Amsüss
Or can such a transfer never become a BERT one,

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

Post by Christian Amsüss
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?

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
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hi Carsten,

Post by Carsten Bormann
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).

Post by Carsten Bormann
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

[Jim Schaad]

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-----
Sent: Thursday, March 15, 2018 3:32 PM
Subject: [core] arriving at BERT for early block requests
Hello CoAP-over-TCP authors and working group,
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