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

[Zach Shelby <[e-mail]>]

Bert,

On Apr 28, 2013, at 11:58 AM, Bert Greevenbosch <[e-mail]> wrote:

> 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.

So far, we have found NSTART=1 to be more than sufficient for CoAP doing real deployments. At the same time, even with the most contained devices, we have not experienced problems with no delay between subsequent requests. If the server did want to slow down the request rate of a client, it can do so simply by inserting some delay before sending a response (and this happens naturally). Thus I am having problems understanding what this MRI mechanism brings us. Are you assuming NSTART>1? Before going as far as designing sophisticated mechanisms for dealing with NSTART>1, we should wait for real use cases (if any!). 

Now, there are other congestion related issues that would be useful for this WG to solve in the future:
	- Automatic adjustment of ACK_TIMEOUT using RTT estimation. Today you either use our 2 second default or configure this manually. 
	- Rate control to a group of destinations (e.g. a LoWPAN) and in particular automatic estimation of that rate. It is fairly easy for a non-contrained endpoint to overload a LoWPAN if it just considers NSTART=1 for each individual destination in the LoWPAN. 

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net