Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response)

From: <[email-masked]>
Date: Wed, 23 Dec 2020 08:51:19 +0000

Hi Christian, 

Thank you for the review. 

Will focus on your first comment in this reply to ease tracking issues. 

The text we have in the draft does not preclude No-Response (or any solution that will be endorsed by the WG in the future): 

      Note: A delay of ACK_TIMEOUT after every transmission of
      MAX_PAYLOADS blocks may be observed even if the peer agent is able
      to handle more blocks without experiencing an overload.  This
      delay can be reduced by using CON for the MAX_PAYLOADS packet to
      trigger sending the next set of data when the ACK is received.
      Nevertheless, this behavior is likely to create other timeout
      issues in a lossy environment (e.g., unidirectional loss as in
      DDoS pipe flooding).  The use of NON is thus superior but requires
      an additional signal in the MAX_PAYLOADS packet to seek for a 2.31
      (Continue) from the peer if it is ready to receive the next set of
      blocks.

If both endpoints support No-Response, they can use it as a "signal in the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence. 

As we don't recommend No-Response (for reasons echoed in your message), it is not worth to include much more details on how No-Response can be used.  

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Christian Amsüss [mailto:[email-masked]]
> Envoyé : mercredi 23 décembre 2020 06:01
> À : [email-masked]
> Cc : [email-masked] WG ([email-masked]) <[email-masked]>; [email-masked]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hello new-block authors, hello CoRE,
> 
> I've finally managed to have another look at the document (and it's
> still the 22nd *somewhere*...).
> 
> My over-all summary is that while this document has matured quite a
> bit (and turned out better than I had expected for the special-
> purpose blocks it is), I think that the topic of response
> suppression and congestion control sections still have to be
> sharpened, and the examples could pick a more realistic balance
> between going all-NON and all-CON (or explain why that's something
> that wouldn't be done even though the text reads like that's what's
> expected to be used but maybe it's just me).
> 
> 
> Except for the first item (which is coming back to the notes for the
> WGLC), all should be more or less sequential in the document (with
> forward/back references as needed).
> 
> * On the downref to No-Response: I don't see the downref as too big
> an
>   issue. It's a bit odd that that document didn't go through the
> CoRE
>   WG, but my impression is that it's widely used (on a "when the
> library
>   I maintain broke it people filed issues" level), and both OSCORE
> and
>   groupcomm-bis (which is to replace RFC7390) reference it. It's an
>   informative reference because they don't mechanically depend on
> it,
>   but it shows how well No-Response has been taken up.
> 
>   (Frankly, I'd support a retroactive adoption. I don't suppose we
> can
>   do that with "adults"?).
> 
>   From how I understand Q-Block to be intended to work, No-Response
> does
>   not cover all of the behavior (as it's timeout based); still, that
>   document lays good groundwork for what's done here in a rather
> precise
>   way (see comment on "For Confirmable transmission, the server MUST
>   continue" later on) where this document needs the examples to be
> fully
>   understood.
> 
>   Based on the later text on MAX_TRANSMIT_SPAN, why not at least
>   acknowledge the equivalence? Maybe like this:
> 
>   > The behavior of endpoints following this draft can equivalently
> b
>   > described in terms of the No-Response option {{?RFC7967}}:
>   >
>   > For a message with a Q-Block1 option with M=1 that is followed
> by
>   > another message on the same Request-Tag within MAX_TRANSMIT_SPAN
> [
>   > or MAX_BLOCK_JITTER, see later ], the default value for No-
> Response
>   > is 8 (suppressing the 4.xx code that would be returned due to
> the
>   > incomplete request); an explicitly set No-Response option would
>   > override that."
> 
>   although I'd still advocate just using No-Response for the whole
>   definition even if No-Response is not typically expressed.
> 
>   (I'm not really sure what the correct response would be for an
>   individual non-terminal request if it were to be answered due to
> an
>   explicit No-Response:0 -- might be 2.31 Continue that's just not
>   used in this specification because it's always suppressed? I'll
> come
>   back to that -- but then it'd rather be No-Response: 10).
> 

_________________________________________________________________________________________________________________________

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: Christian Amsüss <[email-masked]>
Date: Wed, 23 Dec 2020 10:51:45 +0100

Hello Med,

> The text we have in the draft does not preclude No-Response (or any
> solution that will be endorsed by the WG in the future): 
> 
> If both endpoints support No-Response, they can use it as a "signal in
> the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last sentence. 
>
> As we don't recommend No-Response (for reasons echoed in your
> message), it is not worth to include much more details on how
> No-Response can be used.  

The only reason for No-Response I echo in my mail is the downref, and
merely showing how these can interoperate does not create a normative
reference. It's quite a stretch to assume people would read "requires an
additional signal" as "could use No-Response".

Working group documents time and again have outward references like "One
way of doing this is being explored in [draft-...]", which is clearly
non-normative, but at the same time allow the reader to get at least
*some* indication of how things are meant to be used.

What makes things worse here is that as long as this specification does
not mention No-Response at all, it is not ensured that it interoperates
well at all with No-Response; thus even if a reader can make the jump,
they'd have to figure out on their own that it's probably best if
No-Response overrides the response behavior of Q-Block.

>       The use of NON is thus superior but requires

I missed that in the part where I'm asking for whether 2.31 would be
produced. That paragraph really opens more questions than it answers: If
Q-Block is intended to be usable with something to signal that now would
be a good time for a response, then this almost contradicts the "2.31
(Continue) Response is not used in the current version" statement.

Either this is a possibility already planned here, then the 2.31 cases
should be properly described, even if it's just with a "but requires
additional signaling, which for example can be achieved by combining
this with No-Response:0". Or it's not planned out here, then the 2.31
mentioned in the quoted note is more of a note on future updates of
Q-Block that would be necessary to leverage that combination (but I
don't see any such document happening).

Best regards
Christian

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

---

From: <[email-masked]>
Date: Wed, 23 Dec 2020 14:09:37 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 23 décembre 2020 10:52
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked] WG
> ([email-masked]) <[email-masked]>; [email-masked]
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block (No-
> Response)
> 
> Hello Med,
> 
> The only reason for No-Response I echo in my mail is the downref,
> and merely showing how these can interoperate does not create a
> normative reference. It's quite a stretch to assume people would
> read "requires an additional signal" as "could use No-Response".
> 
> Working group documents time and again have outward references like
> "One way of doing this is being explored in [draft-...]", which is
> clearly non-normative, but at the same time allow the reader to get
> at least

[Med] Simply adding a pointer would work for me. We can go for the following change: 

s/an additional signal in the MAX_PAYLOADS packet/an additional signal in the MAX_PAYLOADS packet (e.g., [RFC7967])

> 
> What makes things worse here is that as long as this specification
> does not mention No-Response at all, it is not ensured that it
> interoperates well at all with No-Response; thus even if a reader
> can make the jump, they'd have to figure out on their own that it's
> probably best if No-Response overrides the response behavior of Q-
> Block.

[Med] Here is where I disagree. As we don't recommend any solution (including No-Response), it is not up to this document to discuss how to graft the various pieces.    

> produced. That paragraph really opens more questions than it
> answers: If Q-Block is intended to be usable with something to
> signal that now would be a good time for a response, then this
> almost contradicts the "2.31

[Med] That statement is factual. It is meant to remind that 2.31 is legal and that it is there as a provision for any future optimization that would require it. 

> 
> Either this is a possibility already planned here, then the 2.31
> cases should be properly described, even if it's just with a "but
> requires additional signaling, which for example can be achieved by
> combining this with No-Response:0". Or it's not planned out here,
> then the 2.31 mentioned in the quoted note is more of a note on
> future updates of Q-Block that would be necessary to leverage that
> combination (but I don't see any such document happening).
> 
> Best regards
> Christian
> 
> --