Thank you for the review Jana!
Please see inline.
> On 19 Oct 2018, at 3.57, Jana Iyengar <jri.ietf@xxxxxxxxx> wrote:
>
> Reviewer: Jana Iyengar
> Review result: Ready with Nits
>
> I've reviewed this document as part of the transport area review team's ongoing
> effort to review key IETF documents. These comments were written primarily for
> the benefit of the transport area directors. Document editors and WG chairs
> should treat these comments just like any other last call comments.
>
> This is a simple document that defines a new response code for CoAP servers to
> use when under overload. The response code ("4.29 Too Many Requests") is used
> as a flow control signal to indicate to a client that it needs to stop sending
> more "similar" requests. The amount of time that the client needs to back off
> is encoded in the response.
>
> This is a straightforward document and I see no major issues, but I have a
> couple of suggestions that might help implementers.
>
> 1. There should be text suggesting what a server MAY do if the client doesn't
> respect the backoff period indicated in the response. For instance, a server
> MAY drop all incoming requests from a client for an extended period of time if
> the client sends a request without waiting for the duration of the backoff
> period (or some such).
Simply dropping incoming requests results likely in retransmissions, which could be counter-productive for reducing load. I think the best way for the server is to answer with a different error code since if it is a well-behaving client, likely the reason for it to not respect the backoff is that it didn’t simply recognize the error code and understand what to do with Max-Age.
I’m thinking of adding text in “CoAP server behavior” section along the lines of:
If a client repeats a request that was answered with 4.29 before Max-Age time has passed, it is possible the client did not recognize the error code and the server MAY respond with a more generic error code (e.g., 5.03).
> 2. There should be some text suggesting that the server does not have to (and
> probably should not) respond to every incoming request during overload with
> this response. Even when the server wants to ask clients to back off, it does
> not need to do that on every incoming request from a client. For instance, a
> server can choose to respond to each client once in every estimated round-trip
> time.
So this would be mainly for the case when client sends multiple requests before it has a chance to receive the 4.29 to an earlier request? For that once every RTT seems indeed reasonable.
> 3. Is the expectation that the client waits for the back off time starting from
> when the response is received? That seems like the most obvious way to do it,
> but it might be useful to clarify precisely when the client's backoff period
> starts.
RFC7252 says that Max-Age is intended to be current at the time of transmission. But since the precision of Max-Age is at the level of seconds, starting a timer when response is received sounds like a fair approximation.
Cheers,
Ari<<attachment: smime.p7s>>
