Re: [core] Mirja Kühlewind's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Mirja,

I believe I have addressed your DISCUSS and COMMENTs in
draft-ietf-core-block-20.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Specifically:

>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> This is only a minor point, requesting to spell out implicit assumptions
>>> explicitly. However, I think it's important to address this before
>>> publication.
>>>
>>> It is not clear in the main part of the doc that this extension to does
>>> not change the message transmission method as specified in RFC7252
>>> (Stop-and-wait retransmission). With my initial ready I assumed that this
>>> extension would allow the sending of back-to-back messages. Only by
>>> looking at the examples, it got clear to me that this is not the case. 
>> I'm wondering how we managed to create that expectation.
> 
> I guess by not talking about it at all (and Spencer and me being overly sensitive to this topic) :-)
> 
>> As I said in the response to Spencer's comment, block-wise transfers are
>> strictly layered on top of RFC 7252 CoAP.  Maybe there is some
>> introductory text needed that emphasizes this early on.
> 
> Yes, please add something similar as what you’ve written in your response to Spencer, (early) in the doc. Thanks!
> 
>> Implementations that I know run completely lock-step.  Theoretically, an
>> implementation could pipeline requests for further blocks after the
>> initial exchange (which needs to be lock-step so a common block-size can
>> be determined; also, a Size2 option would be needed to determine the
>> number of requests to be sent).  NSTART (Section 4.7 of RFC 7252) puts a
>> hard limit on the parallelism here, and the default value of NSTART
>> (without advanced congestion control) is 1, so we are back to lock-step.
> 
> Okay, the problem with not talking about this at all is that all these value in rfc7252 are only recommendation. There are no restricting max values which are defined like 'MUST NOT be larger than X'. Therefore my fear would be that people could assume that this extension, as it supports sending or larger data, could provide a reason to increase the default values.
> 
> Would it make sense to say something like: Using this extension MUST NOT lead to changes in the transmission behavior (e.g. other default value than specified in RFC7252).  ?
> 
>>> Further, this document does not say anything about reliability. Do block
>>> message need to be transmitted reliable (as Confirmable)? If not, this
>>> extension could still lead to back-to-back sending and then further
>>> guidance on congestion control would be needed.
>> Block-wise transfers can be sent in NON messages.  That would not be a
>> particularly wise choice in general, as the delivery probability for the
>> whole body decreases exponentially (section 2.8 outlines one specific
>> use case for using NON in the first block only, though).
> 
> Again, I don’t think this is spelled to anywhere and really should.
> 
>> NON messages can not simply be sent back-to-back in CoAP, see section
>> 4.7 of RFC 7252.
> 
> Please correct me if I’m wrong but looking at section 4.7 this might not be well enough defined to be fully applicable and save for a case where you send a large message with several blocks as NON (even though this is in general not recommended). Note, 4.7 is explicitly saying "Further congestion control optimizations and considerations are expected in the future“. Please double-check and consider giving further recommendations in this doc!

All this should be addressed by the new paragraph right in the introduction.

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I agree with others that reduncy makes the doc harder to read, especially
>>> regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and
>>> MUST in one section and combine the Usage guidance with the examples?
>> The usage guidance (section 2.5?) is more normative than just an
>> example.  Moving all interoperability requirements into one section
>> might create even more duplication of text.
> 
> Might still be worth trying to remove redundancy where possible and double-check all MUST and SHOULD. Thanks!

Ben identified a particularly atrocious use of SHOULD in Section 2.4, I
have fixed that.  Apart from that, I tried to refrain from major surgery
-- this document has been around for a while, been tested in four
plugtests, etc.  Risks vs. benefit.

>>> Further, please also add a reference for ETag in section 2.4.
>> I have added a reference to Section 5.10.6 of RFC 7252 in the editor's
>> draft.

Done.

Grüße, Carsten