Re: [core] WG Last Call on draft-ietf-core-new-block

[Marco Tiloca <[e-mail]>]

Hi,

Thanks for this revision and for addressing my comments already in
version  -03.

Please, see below some more comments on this version -04.

Best,
/Marco


* s/There are one or more missing CBOR encoded missing block
numbers./There are one or more CBOR encoded missing block numbers.


*  Section 4 now includes the new paragraph: "The token to use for the
response SHOULD be the token that was used in the highest block number
received payload.  The Q-Block1 Option from the same packet SHOULD be
included."

   Consistently, the example in Figure 5 should also have QB1:3/0/1024
in the 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08
response with Token T:0xe4.

   Since "SHOULD" is used, when is it still fine or expected to not
include Q-Block1 in a 4.08 response?


* When commenting the example in Figure 5, Section 9.1 reads: "The Token
just needs to be one of those that have been received for this
Request-Tag, so the client can derive the Request-Tag."

   Should this not be aligned with the SHOULD used in Section 4 about
using the Token from the same packet conveying the highest block number?
  
   You explained in your mail that the client keeps tracking all Tokens
in the burst anyway, so maybe it's better to rather align the text in
Section 4 with what suggested here in Section 9.1, i.e. responding with
any of those Token values is just fine.
  
   In such a case, the Q-Block1 option included in the 4.08 response has
still to be the one from the request conveying the highest block number.
Correct?


* The new text in Section 6.2 says: "... and the situation re-evaluated
for another 24 hour period until there is no report of missing payloads
under normal operating conditions."

   When that happens, I suppose MAX_PAYLOADS is right away restored to
the intended value, i.e. it is not incremented by 1 to start another
24-hour period evaluation. Correct?


* Section 6.2 says: "The request that the client sends to acknowledge
the receipt of all the current set of MAX_PAYLOADS payloads SHOULD
contain a special case Q-Block2 Option with NUM set to the first block
of the next set of MAX_PAYLOADS payloads and the M bit set to 1."

  Is it possible to reflect this in the example of Figure 6? It would
require the body to have more than MAX_PAYLOADS blocks thus resulting in
more bursts, which would be inherited by the examples in Figure 7 and
Figure 8.


* In Section 9, it would be good to have the parameters defined in
Section 6.2 and their values reflected in the examples, when applicable.
E.g., MAX_PAYLOADS is at least 4 in these examples; the asked
retransmissions are presumably due sometimes to MAX_PAYLOADS compared
against the value of the latest received Q-Block1/Q-Block2, while
sometimes to NON_RECEIVE_TIMEOUT.


* In the example in Figure 6, shouldn't the first request from the
client have the M bit set to 1 in the Q-Block2 option, i.e. as
QB2:0/1/1024 ? As per Section 3.4, that would indicate that the request
is in fact for the block 0 and for all of the remaining blocks within
the body.


On 2021-01-06 16:24, [e-mail] wrote:
> Hi Christian,
>
> Once again, thank you for the comprehensive review.
>
> Responses part 2.  A new version (-04) of the draft has been published and
> can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=MlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7jgTY%3D&reserved=0
>
>
> Part 1 responses were covered in the main by version -03, so you may want to
> look at the -02 to -04 differences.
>
> The Congestion Control section has been re-written to simplify how things
> work and has a new set of definitions. There is a separation of Confirmable
> and Non-Confirmable Congestion Control with the stated assumption that all
> of a body is sent as Non-Confirmable or Confirmable.
>
> Otherwise, see inline.
>
> Regards
>
> Jon
>
>> * The list of pros and cons (with the cons being almost trivial) does
>>   not explain to the reader why these are not a replacement; I suggest
>>   to add:
> [Jon] Another disadvantage addition
> NEW
> To reduce the transmission times for CON transmission of large bodies,
> NSTART needs to be increased from 1, but this affects congestion control
> where other parameters need to be tuned  (Section 4.7 of [RFC7252]).  Such
> tuning is out of scope of this document.
>
>> * "If the client transmits a new body of data with a new Request-Tag
>>   to": Processing parallel requests is something Request-Tag opens up. I
>>   don't see why there's a MUST to that; the server certainly MAY drop
>>   the old request, but it may just as well process them in parallel.
> [Jon] The intent here was that garbage collection would take place sooner
> than later - especially when running in a lossy environment and the client
> has updated information to transmit. I agree that Request-Tag enables the
> possibility of sending multiple block requests with different payloads, and
> so there is a possibility that the client starts sending body A, then
> decides to send body B and terminate A, but a packet from B arrives before a
> packet from body A is received and so things fail as A does not complete.
>
> OLD
>    If the client transmits a new body of data with a new Request-Tag to
>    the same resource on a server, the server MUST remove any partially
>    received body held for a previous Request-Tag for that resource.
> NEW
>   If a server receives payloads with different Request-Tags for the same
> resource, it should continue to process all the bodies as it has no way of
> determining which is the latest version, or which body, if any, the client
> is terminating the transmission for.
>
>   If the client elects to stop the transmission of a complete body, it	
>   SHOULD "forget" all tracked tokens associated with the body's	
>  Request-Tag so that a reset message is generated for the invalid	
>  token in the 4.08 (Request Entity Incomplete) response.  The server	
>  on receipt of the reset message SHOULD delete the partial body.
> END
>
>> * "If the server receives a duplicate block with the same Request-Tag":
>>   Why? Being silent is the default on nonterminal blocks alredy, but in
>>   a situation like figure 5 if the 2.04 is lost, that rule would make
>>   it impossible for the client to ever get a successful response.
>>
>>   A better rule here may be to say that it processes it all the same
>>   (and if the payload is distinct from the first transmission's payload,
>>   it should err out.)
> [Jon] Fair point
> OLD
>    If the server receives a duplicate block with the same Request-Tag,
>    it SHOULD silently ignore the packet.
> NEW
>    If the server receives a duplicate block with the same Request-Tag,
>    it SHOULD  ignore the payload of the packet, but MUST still respond as if
> the block was received for the first time.
>> * "If the server receives multiple requests (implied or otherwise) for
>>   the same block, it MUST only send back one instance of that block.":
>>   This might be read as "ever" rather than "per incoming request", where
>>   probably the latter is meant.
> [Jon] This text has already been updated following another review
> "OLD
> If the server receives multiple requests
>    (implied or otherwise) for the same block, it MUST only send back one
>    instance of that block.
> NEW
> If the request includes multiple Q-Block2
>    Options and these options overlap (e.g., combination of M being set
>    (this and all the later blocks) and being unset (this individual
>    block)) resulting in an individual block being requested multiple
>    times, the server MUST only send back one instance of that block.
>    This behavior is meant to prevent amplification attacks."
>
>> * "The ETag Option MUST NOT be used": This is more a factural than a
>>   normative statement; it *can* not be used there as the server would
>>   respond thusly. It may be used, but then that indicates that the
>>   client is trying to verify a freshness. (However, the client should
>>   not *start* sending an ETag once it learned the current resource's
>>   ETag when still attempting to pull out more blocks, but that's also not
>>   a normative requirement but a consequence of those two requests not
>>   being matchable any more.)
> [Jon] OK
> OLD
>    The ETag Option MUST NOT be used in the request as the server could
>    respond with a 2.03 (Valid Response) with no payload.  If the server
>    responds with a different ETag Option value (as the resource
>    representation has changed), then the client SHOULD drop all the
>    payloads for the current body that are no longer valid. 
> NEW
>    The ETag Option should not be used in the request for missing blocks as
> the server could respond with a 2.03 (Valid Response) with no payload. It
> can be used in the request if the client wants to check the freshness of the
> currently cached body response.
>
> If the server detects part way through a body transfer that the resource
> data has changed and the server is not maintaining a cached copy of the old
> data, then the body response SHOULD be restarted with a different ETag
> Option value. Any subsequent missing block requests MUST respond using the
> latest ETag Option value.
>
>  If the server responds during a body update with a different ETag Option
> value (as the resource representation has changed), then the client should
> treat the partial body with the old ETag as no longer being fresh. 
> END
>> * "then the client SHOULD drop all the payloads for the current body":
>>   "Drop" is overly prescriptive; the client may well keep them, but
>>   just can't consider them fresh any more. (If the client has ample
>>   caching abilities, they might come in handy if the resource goes back
>>   to that ETag state). Same for later "the client MUST remove any
>>   partially received".
> [Jon] See previous response, otherwise
> OLD
>    If the server transmits a new body of data (e.g., a triggered
>    Observe) with a new ETag to the same client as an additional
>    response, the client MUST remove any partially received body held for
>    a previous ETag.
> NEW
>    If the server transmits a new body of data (e.g., a triggered
>    Observe) with a new ETag to the same client as an additional
>    response, the client should remove any partially received body held for
>    a previous ETag for that resource as it is unlikely the missing blocks
> can be retrieved.
>> * "For Confirmable transmission, the client SHOULD continue to": As
>>   above in the other direction, that's not news.
> [Jon] Again, we are not looking for a response (well, a request in this case
> as needed by Block2), just an ACK
> OLD
>    For Confirmable transmission, the client SHOULD continue to
>    acknowledge each packet as well as issuing a separate GET, POST, PUT,
>    FETCH, PATCH, or iPATCH for the missing blocks.
> NEW
>    For Confirmable transmission, the server continues to acknowledge	
>   each packet, but a response is not required (whether separate or	
>   piggybacked) until successful receipt of the body or, if some of the	
>   payloads are sent as Non-confirmable and have not arrived, a	
>   retransmit missing payloads response is needed.
>> * "If there is insufficient space to create a response PDU": I don't
>>   understand what that means. (Where are request options reflected
>>   back?).
> [Jon] This was triggered by a question by Michael Richardson " So, given a
> Christmas-Tree-Packet (largest packet, every possible option space used,
> every extension turned on...) how much data can I get back? :-)" and not
> fully thought through.
> It could happen though with Location-Path, Location-Query, Q-Block2, ETag,
> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE  in response to
> a POST.
> OLD
>    If there is insufficient space to create a response PDU with a block
>    size of 16 bytes (SZX = 0) to reflect back all the request options as
>    appropriate, a 4.13 (Request Entity Too Large) is returned without
>    the Size2 Option.
> NEW
>    If there is insufficient space to create a response PDU with a block
>    size of 16 bytes (SZX = 0) to send back all the response options as
>    appropriate, a 4.13 (Request Entity Too Large) is returned without
>    the Size1 Option.
>
>> * "If the client requests missing blocks, this is treated as a new
>>    request.": I don't think the client should even make these follow-up
>>    requests Observe, as it already has an ongoing observation. They'd be
>>    sent on a different token too, so setting Observe would be opening
>>    observation up on that token, which AFAIU is not intended. (Figure 7
>>    example looks good to me in that respect.)
>>
>>    (It may make sense to ask the client to keep Observe to make the
>>    requests matchable just for the sake of staying in atomic-request
>>    mode. Either way, the server should then not accept that observation
>>    as it's not for a block 0.)
> [Jon] The intent here was that just a new Token should be used.
> OLD
>    If the client requests missing blocks, this is treated as a new
>    request.  The Observe value may change but MUST still be reported.
>    If the ETag value changes then the previously received partial body
>    should be destroyed and the whole body re-requested.
> NEW
>    If the client requests missing blocks, this is treated as a new
>    Request and the Observe Option MUST NOT be included.   If the ETag value
> changes, then the previously received partial body
>    should be considered as not fresh and the whole body re-requested.
>
>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be
>>   matched by the token to a unique request that already had a
>>   Request-Tag, and the client needs to have kept that token around
>>   matched to the transfer to make sense of it.
>>
>>   No need to move that value around between subsystems, and just
>>   dropping it from here would also remove the need for the "If the
>>   client does not recognize the Request-Tag" clause (which would
>>   otherwise need clarification as to what it'd mean if it recognizes it
>>   but it doesn't match what the request was for).
> [Jon] Good question - it does make sense for the Request-Tag to be tracked
> alongside the Token in the client.
> OLD
>    The data payload of the 4.08 (Request Entity Incomplete) Response
>    Code is encoded as a CBOR Sequence [RFC8742].  First is CBOR encoded
>    Request-Tag followed by 1 or more missing CBOR encoded missing block
>    numbers.
> NEW
>    The data payload of the 4.08 (Request Entity Incomplete) response
>    is encoded as a CBOR Sequence [RFC8742].  There are one or more missing
>    CBOR encoded missing block numbers.
>
> OLD
>        ; This defines an array, the elements of which are to be used
>        ; in a CBOR Sequence:
>        payload = [request-tag, + missing-block-number]
>        request-tag = bstr
>        ; A unique block number not received:
>        missing-block-number = uint
> NEW
>        ; This defines an array, the elements of which are to be used
>        ; in a CBOR Sequence:
>        payload = [+ missing-block-number]
>        request-tag = bstr
>        ; A unique block number not received:
>        missing-block-number = uint 
>
> OLD
>    A 4.08 (Request Entity Incomplete) Response Code returned with
>    Content-Type "application/missing-blocks+cbor-seq" indicates that
>    some of the payloads are missing and need to be resent.  The client
>    then re-transmits the missing payloads using the Request-Tag and
>    Q-Block1 to specify the block number, SZX, and M bit as appropriate.
>    The Request-Tag value to use is determined from the payload of the
>    4.08 (Request Entity Incomplete) Response Code.  If the client does
>    not recognize the Request-Tag, the client can ignore this response.
> NEW (option presentation has been reformatted)
>   4.08 (Request Entity Incomplete)
>
>   This Response Code returned with Content-Type "application/	
>   missing-blocks+cbor-seq" indicates that some of the payloads are	
>  missing and need to be resent.  The client then retransmits the	
>   missing payloads using the same Request-Tag, Size1 and Q-Block1 to	
>  specify the block number, SZX, and M bit as appropriate.	
>  
>
>  The Request-Tag value to use is determined from the token in the	
>  4.08 (Request Entity Incomplete) response and then finding the	
>  matching client request which contains the Request-Tag that is	
>   being used for this Q-Block1 body. END
>> * "limit the array count to 23 (Undefined value)": 23 is the maximum
>>   length of a zero-byte length indication, not indefinite-length (31).
>>   Both using 23 and 31 here makes sense (up to 23 to have definite
>>   length that can be updated in-place, or exceeding that switch to
>>   indefinite length if they still fit), but the paragraph seems to be
>>   mixing them up.
> [Jon] OK
> OLD
>       Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23
>       (Undefined value) so that the array data byte can be updated with
>       the overall length once the payload length is confirmed or limited
>       to MAX_PAYLOADS count.
> NEW
>       Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the array
> count to
>       23 so that the initial byte with the array major type and data length
> in the additional information can be updated with the overall count once the
> payload count is confirmed.  Further restricting the count to MAX_PAYLOADS
> means that congestion control is less likely to be invoked on the server.
>
>> * "Each new request MUST use a unique token": Like above, this is
>>   stating something that's not intended to be changed.
> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token values
> are acceptable.  Hence this statement.
>> Congestion Control:
>>
>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected
>>    to PROBING_RATE.": That is unexpected here. At most one such
>>    response is sent to each request message, so why is additional
>>    congestion control needed?
> [Jon] The intention here was that in the previous paragraph that it was not
> the individual packets that are subject to PROBING_RATE, but a single body
> comprising of multiple packets is subject to PROBRING_RATE - and hence
> limiting any individual responses to PROBING_RATE rather than the
> potentially full set of responses
> OLD
>    PROBING_RATE parameter in CoAP indicates the average data rate that
>    must not be exceeded by a CoAP endpoint in sending to a peer endpoint
>    that does not respond.  The body of blocks will be subjected to
>    PROBING_RATE (Section 4.7 of [RFC7252]).
> NEW
>    PROBING_RATE parameter in CoAP indicates the average data rate that
>    must not be exceeded by a CoAP endpoint in sending to a peer endpoint
>    that does not respond.  The single body of blocks will be subjected to
>    PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
> If the wait time between sending bodies that are not being	
>  responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the	
>  gap time is limited to NON_PROBING_WAIT.
>
> Note: For the particular DOTS application, PROBING_RATE and other
> transmission parameters are negotiated between peers.  Even when	
>  not negotiated, the DOTS application uses customized defaults as	
>  discussed in Section 4.5.2 of [RFC8782].
> END
>>    On the other hand, *ever* NON request is subject to PROBING_RATE, so
>>    why point out the body of blocks and "GET or similar" particularly?
> [Jon] It is only GET or FETCH.  The intention here is to not request bodies
> of data at too high a rate.
> OLD
>    Each NON GET or similar request using Q-Block2 Option is subjected to
>    PROBING_RATE.
> NEW
>    Each NON GET or FETCH request using Q-Block2 Option is subjected to
> PROBING_RATE.
>> * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS,
>>   this is (rather implicitly) introduced as the package count up to
>>   which it is OK to exceed PROBING_RATE temporarily (but after that it
>>   kicks in all the harder by requiring to wait until complete-sent-bytes
>>   over PROBING_RATE has expired). If that holds, at that time a much
>>   larger delay than just ACK_TIMEOUT is needed to get a response from
>>   the server: About 3 hours (see later note on parameters).
> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT).  See re-write of
> Congestion Control section.
>>   This is the crucial point in the document, and for it a recommendation
>>   alone is not good enough. The protocol can be run with a vastly
>>   increased PROBING_RATE (however externally determined) and from the
>>   point of MAX_PAYLOADS just observe it. Or it has to get feedback from
>>   the server; a single 4.08 is probably enough to kick off another
>>   vollley of blocks. (How many? MAX_PAYLOADS for every response?).
>>   Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any
>>   good.
> [Jon] See re-write of Congestion Control section where things should now be
> simpler and more logical.  There is an introduction of new variable
> definitions.
>> * "For NON transmissions": This seems to imply that the full exchange of
>>   a body is either NON or CON; I don't see where that'd come from. I'd
>>   have expected to read something like "Each individual request can be
>>   NON or CON independent of the others. In particular, it can be
>>   convenient to send the ultimate payload...".
> [Jon]The DOTS environment will only be using NON.  To make Congestion
> Control simple,
> the expectation is that all transmissions are NON or (not recommended) are
> all CON. The draft now generally records this expectation.
>> * "If a Confirmable packet is used, then the transmitting peer MUST wait
>>   for the ACK": Why? A NSTART > 1 would give it leisure to still
>>   transmit.
> [Jon] Text has been removed in the clean-up.
>> * General on congestion control: It may help implementors if this were
>>   split up into newly introduced rules and concepts (that is,
>>   MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS
>> en
>>   block again after having only even one response from the last round,
>>   and probably the recommended parameters of the "Also on parameters"
>>   comment), and another subsection on how Q-Block behaves well when
>>   observing these.
> [Jon] Should now be covered in the updated Congestion Control section.
>> Caching:
>>
>> * "are not part of the cache key": How about "are removed as part of the
>>   block assembly and thus do not reach the cache"?
> [Jon] OK.
> OLD
>    As the entire body is being cached in the proxy, the Q-Block1 and
>    Q-Block2 Options are not part of the cache key.
> NEW
>    As the entire body is being cached in the proxy, the Q-Block1 and
>    Q-Block2 Options are removed as part of the
> block assembly and thus do not reach the cache.
>> * "When the next client completes building the body": If the proxy
>>   chooses not to let them happen in parallel (which it may, see above on
>>   parallel requests, although the server might still not support it and
>>   cancel one of them), why bother letting the first finish just to abort
>>   it? (IOW: If the proxy does not intend to see both through, which it
>>   could if it held back the second until the first is through on the
>>   uplink, it could just as well err out of one of them early, but it may
>>   also rather see both through.)
> [Jon] It has to be assumed that traffic to/from the origin client and origin
> server may not both support Q-Blockx and potentially may have a different
> SZX.  Thus passing a request or a response through at the block level
> introduces a new set of challenges (but not impossible to fix).  To keep
> this simple, my thinking was that the passing through can only take place at
> the body level.  Again, the arrival of packets is not necessarily
> sequential, so client A's body may start transmitting to the origin server
> first, but client B's body starts to arrive first - the same being true for
> the proxy as a client may stop transmitting for whatever reason (restart,
> network loss etc.).  However this is covered by the above update "  If a
> server receives payloads with different Request-Tags for the same resource,
> it should continue to process all the bodies".
>
> OLD
>    and the new body representation transmission starts with a new
>    Request-Tag value.
> NEW
>    and the new body representation transmission starts with a new
>    Request-Tag value.  Note that it cannot be assumed that the proxy will
> always receive a complete body from a client.
>> * Examples:
>>
>>   * Figure 5: The ... between e3 request and response indicate the
>>     MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose there
>>     should be the same kind of delay between the failed e5 transmission
>>     and the e4 response.
> [Jon] Agreed and added in
>>   * If the second burst had 3 requests out of which 2 made it, is there
>>     any guidance for which of them the 4.08 would come back on? (In the
>>     end, none of them is terminal).
> [Jon] The client should tracking all Tokens of the burst (hence
> implementation note about bottom 32bits unique and top 32 bits matching
> block number for ease of tracking) for a response and so it will make no
> difference at to which token is used for the 4.08 response.  From an
> implementation perspective, it probably is easier to track the last opaque
> token that has the same Request-Tag. 
> OLD
>    missing ones in one go (Figure 5).  It does so by indicating which
>    blocks have been received in the data portion of the response.
> NEW
>    missing ones in one go (Figure 5).  It does so by indicating which
>    blocks have been received in the data portion of the response. The Token
> just needs to be one of those that have been received for this Request-Tag ,
> so the client can derive the Request-Tag.
>>   * If that e4 response gets lost, does the whole mechanism recover from
>>     it in any way?
> [Jon] In this example, if e4 and e5 get lost, there will be no
> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whether
> it sends the request again or gives up.  See 9.1
>   "Under high levels of traffic loss, the client can elect not to retry
>    sending missing blocks of data.  This decision is implementation
>    specific."
>>     Generally, the all-NON and all-CON examples don't look to me like
>>     what I'd be doing with this spec; the mixed "a CON every
>>     MAX_PAYLOADS" appears much more realistic.
> [Jon] It is unsafe to use CON in the  (potentially lossy) DOTS environment
> (up to 93 secs timeout per payload with the defaults).  Hence why we are
> separating out the NON / CON usage.
>>   * Figure X: The request ahs M unset and thus indicats a request for
>>     just that block. If more than one is expected, it should say
>>     QB2:0/1/1024.
> [Jon] With Figure 7, with the M bit set, block 3 would get returned for a
> second time.  Draft-ietf-core-new-block-03 also has a Figure 8 which does
> exactly what you describe.
>> * New Content Format: I think this needs a media type registration to go
>>   with it first; based on that, a content format can be registered.
> [Jon] Med has responded to this and draft updated.
>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not
>> sure
>>   they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defined
>>   in terms of reliable transmission, but used for NONs as well. (So is
>>   the alternative ot 2x ACK_TIMEOUT).
> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in a NON
> environment. Hence re-write of Congestion Control section defining new
> variables that can be used for NON.
>>   For the purpose of delaying a 4.08 or a follow-up GET, it may make
>>   more sense to define a new parameter based on MAX_LATENCY and the
>> time
>>   it takes the sender to pump out the options (which I don't think we
>>   have a good factor for, but may even be negligible here).
>>
>>   Could read like this:
>>
>>   > The timing parameter MAX_BLOCK_JITTER is introduced, and by default
>>   > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH.
> [Jon]  Lets plug in some numbers here.  MAX_LATENCY = 100, MAX_PAYLOADS =
> 10, MTU = 1280bytes and BANDWIDTH = 1Mbps.
>
> [Jon] MAX_BLOCK_JITTER = 100 + (10 * 1280 * 8)/(1 000 000) = 100.1.  So
> BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes
> MAX_BLOCK_JITTER 200 seconds.
>>   >
>>   > With Q-Block2, a client can ask for any missing blocks after not
>>   > having received any further response for the duration of
>>   > MAX_BLOCK_JITTER.
> [Jon] 100+ seconds delay is way too much time to wait for any missing blocks
> in my opinion.
>
> [Jon] RFC7252 also states (and the intention is that recovery works well)
> " as MAX_LATENCY is not
>       intended to describe a situation when the protocol works well, but
>       the worst-case situation against which the protocol has to guard."
>>   >
>>   > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTER
>>   > unless all blocks have been received. Only then it evaluates whether
>>   > to respond with a 2.0x code, a 4.08 with payload, or not at all
>>   > (because it responded to a later request).
> [Jon] I am not convinced that this is necessarily the way to go.  The new
> Congestion Control more cleanly handles this.
>>   This also brings me back to the earlier matter of 2.31: What is a
>>   server supposed to send when no packages were lost, but it's pasing
>>   the timeout and wants to help the client flush out more packages by
>>   confirming something? It says 4.08 in 3.3, but it's not like there's a
>>   hole in the contiguous range. Does it need to send 4.08 enumerating
>>   all (or at least some) numbers between the first unreceived and what's
>>   indicated by Size1? Or can it just send 2.31 and the client knows all
>>   it needs to know b/c the response came to the largest block that was 
>>   sent and 2.31 indicates that everything is good up to that point?
> [Jon] The previous draft states (under Congestion Control) that the client
> waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS
> blocks.  The server should wait for "two times ACK_TIMEOUT " (3.3) before
> indicating issue.  Apart from perhaps having a new name for ACK_TIMOUT I
> think that these are reasonable values for Non-Confirmable - and are used in
> the new Congestion Control section.
>
> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a signal
> to say that all of the current MAX_PAYLOADS payloads of a body have been
> received, so allowing the client to continue transmitting the next set of
> MAX_PAYLOADS payloads without the need to wait any longer.
>> * Also on parameters: This document is describing flow control stuff
>>   around a situation CoAP was not originally designed for. Wouldn't it
>>   make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY,
>>   ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that
>>   PROBING_RATE will be left to 1 byte/second for any DOTS application
>>   using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS
>>   burst would mark that connection as unusable for about 3 hours if they
>>   all get lost), so better give justifiable numbers here than rely on
>>   implemnetors to come up with unreviewed numbers or disregard
>>   PROBING_RATE altogether.
> [Jon] Answered by Med, and some new text added.
>>   I don't know if it needs additional justification, but an increased
>>   N_START may be justifiable there.
> [Jon] It may be, but tuning the other associated parameters is really out of
> the cope of this draft. This text has been added
> NEW
> Congestion control for CON requests and responses is specified in	
>  Section 4.7 of [RFC7252].  For faster transmission rates, NSTART will	
>   need to be increased from 1.  However, the other CON congestion	
>   control parameters will need to be tuned to cover this change.  This	
>   tuning is out of scope of this document as it is expected that all	
>   requests and responses using Q-Block1 and Q-Block2 will be Non-	
>   confirmable.
>> * Somewhere (never comes up but I think it should): When CONs are used,
>>   a 4.08 (or 2.31?) response to a later request can indicate to the
>>   client that an earlier CON request has been processed successfully. If
>>   the client can match that up (and it should be able to), then it can
>>   (and should) cancel that particular CON request.
> [Jon] I think that this is covered by my update above with the text
> " NEW
>    For Confirmable transmission, the server continues to acknowledge	
>   each packet, but a response is not required (whether separate or	
>   piggybacked) until successful receipt of the body or, if some of the	
>   payloads are sent as Non-confirmable and have not arrived, a	
>   retransmit missing payloads response is needed."
>
> And in my previous part 1 response (updated)
> NEW
> For Confirmable transmission, the server continues to acknowledge	
>  each packet, but a response is not required (whether separate or	
>  piggybacked) until successful receipt of the body or, if some of the	
>   payloads are sent as Non-confirmable and have not arrived, a	
>   retransmit missing payloads response is needed.
>> Best regards
>> Christian
>>
>> --
>> There's always a bigger fish.
>>   -- Qui-Gon Jinn
> _______________________________________________
> core mailing list
> [e-mail]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=tEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se