Reviewer: Colin Perkins Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. Thank you for preparing such a clearly written, precise, specification. On the whole, this is very good. I just have some minor issues to consider. Section 4.1 says “To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request (FETCH, for example), the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar request so that the server knows that the client supports this Q-Block functionality” – It would be useful to enumerate what are “similar” requests. Section 5: “Such messages must not be treated by the client as a fatal error“ - I was surprised this is not a normative MUST NOT. Section 7.1: “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 (Section 3.2).” - The way this is phrased is difficult to parse. I can interpret it as saying that the transmission rate *does* need to be faster, so implementations need to increase NSTART and tune the other parameters. Alternatively, I can interpret this as saying that *if* the transmission needs to be faster, then NSTART and the other parameters need to be tuned in some as-yet-unspecified way. The text would benefit from being rephrased to clarify which meaning is intended. What happens when NSTART is increased beyond 1, and how the other parameters are tuned, is unclear. The text would be better if it either cross-referenced to the definition of how the parameters are to be tuned, or explicitly stated that this is not yet supported and will need to be defined in some future extension. In Section 7.2, I’m not convinced by the argument to set MAX_PAYLOAD to 10 for similar reasons to RFC 6928. The types of link layer that CoAP runs over are very different to those measured to support the increase in TCP’s initial window. An argument based on typical properties of links and buffer space in networks used by CoAP would be more convincing (I accept that using MAX_PAYLOAD of 10 is not going to do any significant harm, even if it is higher than optimal). Section 7.2 also notes that “PROBING_RATE and other transmission parameters are negotiated between peers”. It would be appropriate to give some guidance on what are the bounds for safe values that can be negotiated for these parameters. Section 7.2 says: > As the sending of many payloads of a single body may itself cause > congestion, it is RECOMMENDED that after transmission of every set of > MAX_PAYLOADS payloads of a single body, a delay is introduced of > NON_TIMEOUT before sending the next set of payloads to manage > potential congestion issues. and the following paragraph has guidance for reducing MAX_PAYLOADS if persistent congestion occurs “for at least a 24 hour period and it is known that there are no other network issues over that period”. It’s not clear how an implementation will know about other network issues, and I would suggest that even if there are such issues, backoff would be appropriate given persistent congestion. Finally, is there are mechanism for gradually recovering MAX_PAYLOADS to its original value, if persistent loss ceases for some period? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
