Subject: Feedback on draft-sigurdsson-anti-ddos-http-throttling

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Oct 2011 14:41:30 +1100

Hi Joi,

I just noticed your draft <http://www.ietf.org/id/draft-sigurdsson-anti-ddos-http-throttling-00.txt> and had a quick look through it.

One thing that stood out was your re-definition of the Retry-After HTTP header; modifying the semantics of an existing header is generally not a good idea (as doing so dilutes interop). If it does need changing, that needs to be done in consultation with the entire community, not unilaterally.

I'd suggest you define a different header; if you really need to use Retry-After, please engage with the HTTPbis WG (CC:ed).

Also, you'll need to register whatever headers you define; see RFC3864.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Jói Sigurðsson <[email-masked]>
Date: Mon, 10 Oct 2011 18:32:45 +0000

Hi Mark,

Thanks a lot for the feedback.

I was ambivalent about reusing the Retry-After header.  As far as I
can tell, the semantics are unchanged when encountered on a response
with a 503 status code, which AFAICT is the only status code it is
observed for per current HTTP standards.  The addition in this
Internet-Draft is to observe the header for responses with other
status codes.  My thought was that since implementations should ignore
unknown headers, this wouldn't dilute interop, but I wasn't sure.  It
sounds like the simplest route is to use a new header, but would love
your thoughts on the reasoning above before I go there.

I should note that the existing implementation does not actually
interpret Retry-After this way, it uses an X-header since there is no
standard yet.

I will look into registering the headers as you mentioned.  Thanks for
the reference.

Cheers,
Jói

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Oct 2011 15:23:02 +1100

> your thoughts on the reasoning above before I go there.

I'm mostly concerned because people have talked about using Retry-After for other purposes on other status codes; e.g., on a 202 Accepted, it might indicate how long to wait before polling a status resource, and so on. 

These other uses may or may not conflict with your re-purposing of Retry-After, and strictly speaking, it's already allowed on other responses, in that it isn't prohibited from occurring there; it's just that the semantics are not well-defined.*

One question -- I didn't see anywhere where Retry-After was used in your algorithm; it's referenced as a way for Ajax applications to control polling frequencies. However, this could be done by agreement between the client and server (e.g., using something in the response body, and/or another response header), correct?

Cheers,

* As a side note, I wonder if we can generalise retry-after semantics to apply to all responses where there's a Location header, as well as server-side errors...

---

From: Jói Sigurðsson <[email-masked]>
Date: Wed, 12 Oct 2011 17:33:57 +0000

Thanks Mark.  It sounds like it's safest to use a separate header
instead of Retry-After, e.g. Block-Retry-Until or some such (will
think about the naming a bit in the larger context of the I-D).

> One question -- I didn't see anywhere where Retry-After was used in your
> algorithm; it's referenced as a way for Ajax applications to control polling
> frequencies. However, this could be done by agreement between the client
> and server (e.g., using something in the response body, and/or another
> response header), correct?

When encountering a Retry-After header (or whatever header name we end
up with), the algorithm would set the release_time variable for the
throttling target in question to the indicated time, so all requests
to the throttling target until that time would be blocked.

The Ajax thing was an illustrative example, but indeed I think this
header might be most useful when providing a "web service" kind of
thing, where it's common for clients to poll on a regular basis.
You're right that there could be an agreement between client and
server that is implemented in the application layer of the client, but
this relies on all clients observing the agreement, and it adds an
implementation overhead to each client of each such service.  I
believe a mechanism in the protocol layer would be more useful, if it
becomes a widely-adopted standard.

Cheers,
Jói