Re: draft-asveren-dispatch-http-overload

[Martin Thomson <[e-mail]>]

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 <[e-mail]> wrote:
> 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 <[e-mail]>
> Sent: Monday, April 30, 2018 1:55 AM
> To: Asveren, Tolga <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-asveren-dispatch-http-overload
>
>
>
> ________________________________
>
> NOTICE: This email was received from an EXTERNAL sender
>
> ________________________________
>
>
> 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 <[e-mail]> 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.
>>
>>
>>
>>
>> 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
>>
>>