Re: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt

[Bert Greevenbosch <[e-mail]>]

Hi Carsten,

Thank you for your feedback. Indeed I remember the discussions in Orlando.

I think the main use case of my flow control draft is reducing the server load based on limiting the communication within a client/server pair. As the solution limits the time between subsequent requests through a minimum request interval (MRI), it is useful for transactions that require multiple requests. Examples are block transactions and browsing transactions.

One of the discussion points in Orlando was about how the server can determine a good MRI. I would say the main issue is that when the server is overloaded, e.g. if it has to drop requests due to full buffers, it needs to increase the MRI, whereas if there is no problem, it can decrease the MRI or even set it to 0 if considered safe. Increasing the MRI could be something simple like multiplying by 2 (within bounds), whereas decreasing could be something like linear decrease. This would mimic TCP but other strategies could be possible as well.

<quote>
Just to build a very rough strawman for such an alternative metric: 
A server could ask a client to send the next request only after twice the time it took the client to obtain the previous response.
(This would figure in network load in a way that the server on its own cannot do.)
</quote>

Yes, that is an idea that deserves exploration. It means that the client would calculate the MRI by itself, whereas the server only indicates to the client the need to adjust the MRI, without signalling an explicit value of the MRI. This could e.g. be done through a new "slow-down" option.

With "doubling", do you mean doubling the MRI once or doubling the current MRI every time the client receives a "slow-down" option? If the latter, there should be an upper bound to the MRI. Also, one could consider linearly reducing the MRI if the "slow-down" option is not included. Since we want to prevent the server to maintain state, it cannot remember to whom it sent how many "slow-down" responses.

Simpler would be for the client to just double the last observed time between Request and Response (the former in above paragraph), but that would only reduce the number of requests per time unit to its half, which may or may not be enough reduction of the server load.

What are your thoughts?

<quote>
Another issue is the scope of the throttling: Is it for a single resource, this endpoint, the IP address, a prefix (say, a /64)?
(Wider scopes have more security implications.)
</quote>

Indeed if the server can signal explicit MRI values, then it can take more factors into account. It could e.g. take the multiplicity of clients it is talking to into account when choosing its MRI. Also if it signals the same MRI to all clients, it enforces fairness. However indeed there are security implications, as in this way clients would have influence on other clients' behaviour, although with a congested server this is the case more often than not. We need to consider whether the server's more extensive knowledge of the situation can lead to significantly better MRIs, and if that would justify the higher complexity.

Just some considerations for further discussion...

Best regards,
Bert


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: 2013年4月26日 18:37
To: [e-mail] ([e-mail])
Subject: Re: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt

Bert: Thanks for updating this.
I referred to the -00 in my reply to Martin Stiemerling's IESG comments.

There were some comments in the Orlando meeting that people didn't quite know when to use such an Option and how to find a good value to put in it.
(I think we need to check whether there is a better metric to use for throttling/load shedding than the elapsed time between two requests.)
It would probably help to look at the use cases in some more detail.  What specifically is a server trying to achieve by limiting the request interval?
What kind of metric aligns best with such an objective?

Just to build a very rough strawman for such an alternative metric: 
A server could ask a client to send the next request only after twice the time it took the client to obtain the previous response.
(This would figure in network load in a way that the server on its own cannot do.)

Another issue is the scope of the throttling: Is it for a single resource, this endpoint, the IP address, a prefix (say, a /64)?
(Wider scopes have more security implications.)

Grüße, Carsten


On Apr 26, 2013, at 11:23, [e-mail] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : CoAP Minimum Request Interval
> 	Author(s)       : Bert Greevenbosch
> 	Filename        : draft-greevenbosch-core-minimum-request-interval-01.txt
> 	Pages           : 8
> 	Date            : 2013-04-26
> 
> Abstract:
>   This document defines an "Minimum-Request-Interval" option for CoAP,
>   which can be used to negotiate the minimum time between two
>   subsequent requests within a single client and server pair.  It can
>   be used for flow and congestion control, reducing the consumption of
>   server and network resources when needed.
> 
> Note
> 
>   Discussion and suggestions for improvement are requested, and should
>   be sent to [e-mail].
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-greevenbosch-core-minimum-request-interval
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-greevenbosch-core-minimum-request-interval-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-greevenbosch-core-minimum-request-interval-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core