Subject: Re: [core] Upload of draft for "BlockMinimumTime" option

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 22 Aug 2012 09:55:27 +0000

Thanks Bert,

this motivation would be useful to have in the draft; it's clear to me.

Esko

-----Original Message-----
From: Bert Greevenbosch [mailto:[email-masked]] 
Sent: Monday 16 July 2012 9:20
To: Dijk, Esko; [email-masked]
Subject: RE: Upload of draft for "BlockMinimumTime" option

Hello Esko,

Thank you for your comments.

> I miss a motivation (or use cases) in this draft why BlockMinimumTime is needed and why other approaches are not good enough.
> E.g., the server can just wait 200 or 300 ms (times from Examples section 7) before sending its response to the client achieving similar congestion control and overload prevention.

I think the main use case is for the server to be able to control the amount of requests it receives within a time period, thereby achieving better usage of its internal resources (memory, processor load, message buffers, etc.) and increasing reliability in responding to requests.

I think the server should perform open work as quickly as it can. That means, that if it has a response to a request available, it should send that response as soon as feasible. Waiting 200 or 300ms to slow down the client requires the server to maintain that response for 200 to 300ms, occupying resources that could have been used to handle requests from other clients instead. So although the delayed response solution indeed reduces the client's speed, it only does a partial job in resolving server overload congestion.

If however the server can explicitly signal the client's speed, then it does not to keep track of its own minimum time to respond to each request, and can handle requests as soon as possible, releasing its resources for other tasks sooner. This will benefit the whole system, as all clients have a better probability that their requests get handled and receive responses, whereas the server can fine-tune the requests to optimally use its resources.

What do you think?

Best regards,
Bert

From: Dijk, Esko [mailto:[email-masked]] 
Sent: 12 July 2012 15:47
To: Bert Greevenbosch; [email-masked]
Subject: RE: Upload of draft for "BlockMinimumTime" option

Hello Bert,
 
I miss a motivation (or use cases) in this draft why BlockMinimumTime is needed and why other approaches are not good enough.
E.g., the server can just wait 200 or 300 ms (times from Examples section 7) before sending its response to the client achieving similar congestion control and overload prevention.
 
regards,
Esko
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Monday 9 July 2012 7:41
To: [email-masked]
Subject: [core] Upload of draft for "BlockMinimumTime" option
 
Hello all,
 
I have just upload a draft that defines the "BlockMinimumTime" option:
http://datatracker.ietf.org/doc/draft-greevenbosch-core-block-minimum-time
 
The option allows the server and client to negotiate the speed in which the client sends requests in a block transaction.
 
Comments are welcome!
 
Best regards,
Bert

________________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.