Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

[Martin Duke <[e-mail]>]

On Fri, Apr 30, 2021 at 4:48 AM <[e-mail]> wrote:

> >
> > I can't reconcile (4.1) with the last sentence in (7.2).
>
> [Med] Why? 4.1 can be done with default CoAP setting. The purpose of this
> CON request is to determine support of the functionality. We made this
> change:
>
> OLD:
>    Congestion control for CON requests and responses is specified in
>    Section 4.7 of [RFC7252].  In order to benefit from faster
>    transmission rates, NSTART will need to be increased from 1.
>    However, the other CON congestion control parameters will need to be
>    tuned to cover this change.  This tuning is not specified in this
>    document given that the applicability scope of the current
>    specification assumes that all requests and responses using Q-Block1
>    and Q-Block2 will be Non-confirmable (Section 3.2).
>
> NEW:
>    Congestion control for CON requests and responses is specified in
>    Section 4.7 of [RFC7252].  In order to benefit from faster
>    transmission rates, NSTART will need to be increased from 1.
>    However, the other CON congestion control parameters will need to be
>    tuned to cover this change.  This tuning is not specified in this
>    document given that the applicability scope of the current
>    specification assumes that all requests and responses using Q-Block1
>    and Q-Block2 will be Non-confirmable (Section 3.2) apart from the
>                                                       ^^^^^^^^^^^^^^
>    initial Q-Block functionality negotiation.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

Does the functionality negotiation in (4.1) involve something other than
sending Q-Block options? If so, then (4.1) ought to clarify that it's what
you mean. If it's just a GET or whatever, then the text here is fine, but
there needs to be more on congestion control for confirmable messages.


>
>  Moreover, if
> > my reading of (4.1) is correct, it's not sufficient to declare
> > congestion control guidance out of scope when it's a mandated part of
> > the protocol.
> >
>
> >
> > - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the
> > same value as computed for EXCHANGE_LIFETIME", why are they different
> > variables?
>
> [Med] Because they refer to distinct aspects that may be tweaked
> separately: the timeout induced by PROBING_RATE and the one to observe for
> expired partial bodies.
>
>  Or is that they SHOULD have the same value but might not?
> > A normative word would be helpful here.
>
> [Med] Not sure a change is needed here given the definition of the two
> parameters.
>

But they can't be tweaked separately! The spec states that they are both
computed as EXCHANGE_LIFETIME. It does not allow for them to be set
separately.