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

[[e-mail]]

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

De : Martin Duke [mailto:[e-mail]]
Envoyé : mardi 4 mai 2021 17:28
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Martin,

Please see inline.

Cheers,
Med

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



On Fri, Apr 30, 2021 at 4:48 AM <[e-mail]<mailto:[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?
[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
> 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.
[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.