Subject: draft-asveren-dispatch-http-overload

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 29 Apr 2018 17:50:18 +0000

I submitted draft-asveren-dispatch-http-overload-control to DISPATCH WG a while ago. It aims to specify a generic overload control mechanism for HTTP/HTTPS applications.

https://www.ietf.org/id/draft-asveren-dispatch-http-overload-control-00.txt

I thought it could be a good idea to herald it here as well as some folks may not be following DISPATCH WG.

I would appreciate any feedback about overall idea/need/alternatives/in general.

Thanks,
Tolga

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Apr 2018 15:54:30 +1000

This is the right working group, for sure.  However, I don't find the
introduction convincing.  Maybe I'm missing something.  How is
Retry-After inadequate?

As for the mechanism described, how does it not expose information
about the server configuration such that DOS could be more precisely
targetted?  What is the scope of the table?  What is the point of
multiple values?

On Mon, Apr 30, 2018 at 3:50 AM, Asveren, Tolga <[email-masked]> wrote:
> I submitted draft-asveren-dispatch-http-overload-control to DISPATCH WG a
> while ago. It aims to specify a generic overload control mechanism for
> HTTP/HTTPS applications.
>
>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 30 Apr 2018 15:25:44 +0000

Martin,

Thanks for the feedback/questions.

i- Why Retry-After is inadequate
Not that I am lazy but I think https://tools.ietf.org/html/rfc5390 (5.3.  The Off/On Retry-After Problem is probably the most relevant part for your question) already explains this better than I could do. It is for SIP but the same arguments would apply for any real-time application where response times matter.

BTW, the issues listed in RFC5390 and the mechanism defined in RFC7339 to deal with it are tested/observed/verified by a group consisting of multiple vendors while preparing these specifications.

ii- The goal of this mechanism is not to provide a solution against malicious attacks. It is meant to be used between well-behaving entities. Nonetheless I don’t think it makes DoS more likely nor does it leak information which significantly can increase efficiency of DoS. It is true that it conveys information about load status of a server but I think this can be deducted by an attacker anyhow (at least to some reasonable extent) by sending requests and checking the response times. So, a server should do whatever it does today when it suspects DoS activity. No changes are defined/assumed on that front.

iii- “The table” is specific for the application type. It has multiple values as most -if not all- real-time applications have the notion of regular/priority/emergency request types. The drop percentage for each could be different depending on server and current overload conditions.

Thanks,
Tolga

From: Martin Thomson <[email-masked]>
Sent: Monday, April 30, 2018 1:55 AM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-asveren-dispatch-http-overload

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 May 2018 09:44:47 +1000

Thanks for the responses.  It would be really helpful if the draft
explained this.

FWIW, I didn't interpret Retry-After in the way that 5390 does.  I
understood it to apply to the request, not the entire server.  But you
will observe that this off/on problem only causes the bursty traffic
pattern described there if there are relatively few clients.  Larger
numbers of clients will result in better distribution of retries.
That happens less often in HTTP than in SIP.

For the working group: Is the assumption that 503+Retry-After means
that the client should withhold all requests to the same server (I
assume that server ~=> origin in this case), the identified resource,
or is it just a single request?  Worth an http-core issue?

On Tue, May 1, 2018 at 1:25 AM, Asveren, Tolga <[email-masked]> wrote:
> Not that I am lazy but I think https://tools.ietf.org/html/rfc5390 (5.3.
> The Off/On Retry-After Problem is probably the most relevant part for your
> question) already explains this better than I could do. It is for SIP but
> the same arguments would apply for any real-time application where response
> times matter.
>
>
>
> BTW, the issues listed in RFC5390 and the mechanism defined in RFC7339 to
> deal with it are tested/observed/verified by a group consisting of multiple
> vendors while preparing these specifications.
>
>
>
> ii- The goal of this mechanism is not to provide a solution against
> malicious attacks. It is meant to be used between well-behaving entities.
> Nonetheless I don’t think it makes DoS more likely nor does it leak
> information which significantly can increase efficiency of DoS. It is true
> that it conveys information about load status of a server but I think this
> can be deducted by an attacker anyhow (at least to some reasonable extent)
> by sending requests and checking the response times. So, a server should do
> whatever it does today when it suspects DoS activity. No changes are
> defined/assumed on that front.
>
>
>
> iii- “The table” is specific for the application type. It has multiple
> values as most -if not all- real-time applications have the notion of
> regular/priority/emergency request types. The drop percentage for each could
> be different depending on server and current overload conditions.
>
>
>
> Thanks,
>
> Tolga
>
>
>