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

From: <[email-masked]>
Date: Wed, 3 Feb 2021 08:09:40 +0000

Christian, 

As a follow-up on this issue, we finally went with an approach that does not require No-Response. We do have the following to avoid extra delays, e.g., 

   For the server receiving NON Q-Block1 requests, it SHOULD send back a
   2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
   payloads to prevent the client unnecessarily delaying.  Otherwise the
   server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
   based on the repeat request count for a payload), before sending the
   4.08 (Request Entity Incomplete) Response Code for the missing
   payload(s).  If the repeat request count for a missing payload
   exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
   body and stop requesting the missing payloads.

Or 

   For the client receiving NON Q-Block2 responses, it SHOULD send a
   'Continue' Q-Block2 request (Section 3.4) for the next set of
   payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
   the server unnecessarily delaying.  Otherwise the client SHOULD delay
   for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat
   request count for a payload), before sending the request for the
   missing payload(s).  If the repeat request count for a missing
   payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the
   partial body and stop requesting the missing payloads.

Cheers,
Jon & Med

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : mercredi 23 décembre 2020 15:10
> À : Christian Amsüss <[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)
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Christian Amsüss [mailto:[email-masked]] 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 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.
> 
> [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.
> 
> >
> > >       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.
> >
> > 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.
> 
> [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
> >

_________________________________________________________________________________________________________________________

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 M. Amsüss <[email-masked]>
Date: Wed, 17 Feb 2021 00:53:39 +0100

Hello Med,

On Wed, Feb 03, 2021 at 08:09:40AM +0000, [email-masked] wrote:
> As a follow-up on this issue, we finally went with an approach that
> does not require No-Response. We do have the following to avoid extra
> delays, e.g., 

The need to indicate when a client wants confirmation has been avoided
by having timeouts on both sides, and relying more on MAX_PAYLOADS being
aligned.

For my taste, that makes unnecessary sacrifices in robustness over the
simple two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th
Q-Block2 from the client (and would completey avoid the risk of stalling
in a lossless situation).

(For the other direction, corective heuristics can easily be applied).

But given they are explicitly configured in the DOTS case where Q-Block
is used, so -- well. Food for a block-bis (or generalized additions that
allow block to be used that way).

That aside, in the interest of readers who try to understand the
ecosystem and the trade-offs involved, I think that at least a reference
to it in a statement like "was not chosen because of X" would be
helpful. The "Note that similar performance benefits" section would lend
itself to that. Text suggestion:

  [messages are provided in Appendix A.] Similarly, The No-Response option
  can be applied to Block1 requests, but offers no corresponding facility
  for Block2 responses.

BR
c

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

---

From: <[email-masked]>
Date: Thu, 18 Feb 2021 13:19:02 -0000

Hi Christian,

We have gone with adding to Section 1.1

" The No-Response Option was considered but was abandoned as it does not
apply to Q-Block2 responses. A unified solution is defined in the document."

Regards

Jon

> -----Original Message-----
> From: Christian M. Amsüss [mailto:[email-masked]]
> Sent: 16 February 2021 23:54
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked] WG
> ([email-masked])
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
(No-Response)
> The need to indicate when a client wants confirmation has been avoided by
> having timeouts on both sides, and relying more on MAX_PAYLOADS being
> aligned.
> 
simple
> two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th
in a
> lossless situation).
> But given they are explicitly configured in the DOTS case where Q-Block is
used,
> so -- well. Food for a block-bis (or generalized additions that allow
block to be
> used that way).
> 
> 
> That aside, in the interest of readers who try to understand the ecosystem
and
> the trade-offs involved, I think that at least a reference to it in a
statement like
> "was not chosen because of X" would be helpful. The "Note that similar
> performance benefits" section would lend itself to that. Text suggestion:
>