Re: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control)

[Christian Amsüss <[e-mail]>]

Hello,

On Wed, Dec 23, 2020 at 09:14:09AM +0000, [e-mail] wrote:
> You are completely right that the default probing-rate is to be
> increased for the DOTS case. FYI, this is why we went with the
> following in RFC8782:
>
> We avoided to include a pointer to these details as these are
> application-specific and that, even if the draft is motivated by the
> DOTS use case, other applications can make use of the new block
> functionality. 

At least a one-line reference into there would be helpful when reading
the congestion control section. It can be phrased as an example ("For
the particular use case of DOTS, these parameters are negotiated; even
when not negotiated, that application uses altered defaults as in
[ref-into-dots]") to avoid the impression of general applicability, but
some example *should* be given, for without changed parameters the
Q-Block mechanism is useless (3 hour wait if all 10 initial messages are
lost).

> For NSTART, we already have the following: 
> 
>   "NSTART will also need to be increased from the default
>    (1) to get faster transmission rates."

It would enhance readability if that were mentioned in the congestion
control section.

It may help to draw the parallel to the MAX_PAYLOADS of the
non-confirmable case, or to talk more about the hybrid transmission
(CON only after some blocks; does that have a name? see also comment
around "seems to imply that the full exchange").

Does DOTS have an altered default here? Without having *anything* about
non-1 NSTART, the all-CON case may not even be worth having in an
example, as there's nothing even referenced where it could make sense.

Best regards
Christian

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