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

[[e-mail]]

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 : [e-mail]
> [mailto:[e-mail]]
> Envoyé : mercredi 23 décembre 2020 15:10
> À : Christian Amsüss <[e-mail]>
> Cc : [e-mail]; [e-mail] WG
> ([e-mail]) <[e-mail]>; [e-mail]
> 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:[e-mail]] Envoyé :
> mercredi
> > 23 décembre 2020 10:52 À : BOUCADAIR Mohamed TGI/OLN
> > <[e-mail]> Cc :
> > [e-mail]; [e-mail] WG
> > ([e-mail]) <[e-mail]>; [e-mail] 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.