Hi Jana et al,
I submitted now a new draft version with updates as discussed below, except for the last item, “when to start timer for back-off”. Carsten pointed out (in off-list discussion) that the issue of interpreting Max-Age time actually goes beyond the scope of this draft and should be considered for CoAP at large. Another document is planned that will clarify these aspects.
Cheers,
Ari
> On 21 Oct 2018, at 21.50, Ari Keränen <ari.keranen@xxxxxxxxxxxx> wrote:
>
> 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>>
