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

[[e-mail]]

Hi Marco,

Thanks for this - and it is good to have another set of eyes checking things through.

Updates have been pushed to https://github.com/core-wg/new-block and the differences with the draft can be found at https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-new-block.txt 

Otherwise, please see inline.

Regards

Jon

> -----Original Message-----
> From: Marco Tiloca [mailto: [e-mail]]
> Sent: 07 January 2021 12:17
> To: [e-mail]; [e-mail]; draft-ietf-core-new-
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> 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.

[Jon] Fixed.
> 
> 
> *  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."

[Jon] The Q-Block1 option actually is not needed as it can be derived by the client from the remembered token (which is used to derive the Request-Tag.
OLD
The Q-Block1 Option from the same packet SHOULD be included.
NEW
The client will use the token to match the request to find what Request-Tag value is
currently being used.  Providing the highest received block number
will aid any troubleshooting.

> 
>    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.

[Jon] No change now needed.
> 
>    Since "SHOULD" is used, when is it still fine or expected to not include Q-
> Block1 in a 4.08 response?

[Jon] Q-Block1 is no longer needed.
> 
> 
> * 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?

[Jon] Agreed
> 
>    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.

[Jon] I think that it is useful for the client to have a hint about what is the latest block number received even if it does not make use it - it may help in debugging from packet captures etc. which is why I added in the SHOULD in section 4.  So, I would prefer to align this with section 4
OLD
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.
NEW
The token used in the response should be the token that was used in the highest block number received payload. The client can then derive the Request-Tag by matching the token with the sent request..

> 
>    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?
[Jon] We are now dropping the need for Q-Block1 in the response.
> 
> 
> * 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?
[Jon] Updated for clarification
OLD
        report of missing payloads under normal operating conditions. Note
        that the CoAP peer will not know about the MAX_PAYLOADS change until
NEW
        report of missing payloads under normal operating conditions. The newly
        derived value for MAX_PAYLOADS should be used for both ends of this
       particular CoAP peer link. Note
        that the CoAP peer will not know about the MAX_PAYLOADS change until
> 
> 
> * 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.

[Jon] Examples updated to include this information
> 
> 
> * 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.

[Jon] Examples updated to include this information
> 
> 
> * 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.
 
[Jon] Good catch - corrected.

~Jon
> 
> 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%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-
> block%2F&data=04%7C01
> >
> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980
> 9cf0
> >
> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown
> %7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0
> >
> %3D%7C2000&sdata=MlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j
> gTY%3D&am
> > p;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%2Fww
> w.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=04%7C01%7Cmarco.tiloc
> a%4
> >
> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09
> ecc4
> >
> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC
> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&
> amp;sd
> >
> ata=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
>