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

From: Martin Duke <[email-masked]>
Date: Mon, 3 May 2021 11:57:12 -0700

On Fri, Apr 30, 2021 at 4:48 AM <[email-masked]> 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.

---

From: <[email-masked]>
Date: Tue, 4 May 2021 09:01:04 +0000

Hi Martin,

Please see inline.

Cheers,
Med

De : Martin Duke [mailto:[email-masked]]
Envoyé : lundi 3 mai 2021 20:57
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

> 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:

NEW:

Does the functionality negotiation in (4.1) involve something other than sending Q-Block options?
[Med] No. All what is needed is to send the options in a CON message as per:

   To indicate support for Q-Block2 responses, the CoAP client MUST
   include the Q-Block2 Option in a GET or similar request (FETCH, for
   example), the Q-Block2 Option in a PUT or similar request (POST, for
   example), or the Q-Block1 Option in a PUT or similar request so that
   the server knows that the client supports this Q-Block functionality
   should it need to send back a body that spans multiple payloads.
   Otherwise, the server would use the Block2 Option (if supported) to
   send back a message body that is too large to fit into a single IP
   packet [RFC7959].

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

> same value as computed for EXCHANGE_LIFETIME", why are they different

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

> 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.
[Med] Ah, I see what confuses you. We made this change:

OLD:
   NON_PROBING_WAIT is used to limit the potential wait needed
   calculated when using PROBING_RATE.  NON_PROBING_WAIT has the same
   value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
   NON_PARTIAL_TIMEOUT has the same value as computed for
   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

NEW:

   NON_PROBING_WAIT is used to limit the potential wait needed

   calculated when using PROBING_RATE.  By default, NON_PROBING_WAIT has

   the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.

   By default, NON_PARTIAL_TIMEOUT has the same value as

   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

_________________________________________________________________________________________________________________________

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.

---

From: Martin Duke <[email-masked]>
Date: Tue, 4 May 2021 08:28:23 -0700

OK, we've reached understanding on the NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT
issue. Thank you for the edit.

I also now understand that essentially every connection will have a Q-block
exchange using CON. As this is an integral part of the protocol, I don't
believe it's sufficient for Sec 7.1 to declare congestion control
parameters out of scope, unless there's a normative reference to some other
draft that explains how to do it.

Thanks
Martin

On Tue, May 4, 2021 at 2:01 AM <[email-masked]> wrote:

> Hi Martin,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Martin Duke [mailto:[email-masked]]
> *Envoyé :* lundi 3 mai 2021 20:57
> *À :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> *Cc :* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Objet :* Re: Martin Duke's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> sending Q-Block options?
> *[Med] No. All what is needed is to send the options in a CON message as
> per:  *
>
>
>
> 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
> *[Med] Ah, I see what confuses you. We made this change:*
>
>
>
> *OLD:*
>
> *NEW:*

---

From: <[email-masked]>
Date: Tue, 4 May 2021 16:33:08 +0000

Re-,

We are not seeking for performance enhancement when determining Q-Block support. This why I indicated in my first reply that no change to the base CC is needed for that. We updated the text as follows:

OLD:
   With CoAP over UDP, the way a request message is rejected for
   critical options depends on the message type.  A Confirmable message
   with an unrecognized critical option is rejected with a 4.02 (Bad
   Option) response (Section 5.4.1 of [RFC7252]).  A Non-confirmable
   message with an unrecognized critical option is either rejected with
   a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of
   [RFC7252]).  To reliably get a rejection message, it is therefore
   REQUIRED that clients use a Confirmable message for determining
   support for Q-Block1 and Q-Block2 Options.

NEW:
   With CoAP over UDP, the way a request message is rejected for
   critical options depends on the message type.  A Confirmable message
   with an unrecognized critical option is rejected with a 4.02 (Bad
   Option) response (Section 5.4.1 of [RFC7252]).  A Non-confirmable
   message with an unrecognized critical option is either rejected with
   a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of
   [RFC7252]).  To reliably get a rejection message, it is therefore
   REQUIRED that clients use a Confirmable message for determining
   support for Q-Block1 and Q-Block2 Options.  This CON message can be
   sent under base CoAP congestion control setup specified in
   Section 4.7 of [RFC7252] (that is, NSTART does not need to be
   increased).

Cheers,
Med

Envoyé : mardi 4 mai 2021 17:28

OK, we've reached understanding on the NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit.

I also now understand that essentially every connection will have a Q-block exchange using CON. As this is an integral part of the protocol, I don't believe it's sufficient for Sec 7.1 to declare congestion control parameters out of scope, unless there's a normative reference to some other draft that explains how to do it.

Thanks
Martin

On Tue, May 4, 2021 at 2:01 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

Please see inline.

Cheers,
Med

De : Martin Duke [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : lundi 3 mai 2021 20:57
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

OLD:

NEW:

 Moreover, if

OLD:

NEW:

---

From: Martin Duke <[email-masked]>
Date: Tue, 4 May 2021 09:58:14 -0700

Wonderful, that is satisfactory. I will lift my discuss when the changes
land.

On Tue, May 4, 2021 at 9:33 AM <[email-masked]> wrote:

> Re-,
>
>
>
> We are not seeking for performance enhancement when determining Q-Block
> support. This why I indicated in my first reply that no change to the base
> CC is needed for that. We updated the text as follows:
>
>
>
> OLD:
>
> *Envoyé :* mardi 4 mai 2021 17:28
> OK, we've reached understanding on the
> NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit.
>
>
>
> I also now understand that essentially every connection will have a
> Q-block exchange using CON. As this is an integral part of the protocol, I
> don't believe it's sufficient for Sec 7.1 to declare congestion control