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

[[e-mail]]

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:[e-mail]]
> Envoyé : mercredi 23 décembre 2020 06:01
> À : [e-mail]
> Cc : [e-mail] WG ([e-mail]) <[e-mail]>; [e-mail]
> 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.