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

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 9 Jul 2012 05:41:11 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Jul 2012 09:43:06 +0200

Hi Bert,

this is interesting.

Three observations pop up in my mind:

1) Clock accuracy and units.  When we need timers that are shorter than seconds, milliseconds come to mind.  However, many nodes have convenient clock sources only in power of two fractions.  I would propose to always give the nodes leeway to use either milliseconds or "mibiseconds" (1/1024 s) as their time base.  As we are typically not making any mandates with respect to clock accuracy, and embedded systems sometimes use RC oscillators for certain timing functions, that 24000 ppm deviation is probably allowable anyway. Saying this explicitly may remove one implementation headache.  (Just for today, I'm not going to add my ceterum censeo about pseudo-floating-point. :-)

2) Why just -block, and a single resource?  Background: When e.g. coap.me crawls a node, it rapidly reads all resources that are advertised.  Would it not be useful to give some pacing akin to your MinimumBlockTime in a resource directory?

3) (General observation:) A server can already slow down a client by just not sending responses very quickly.  (The client is not supposed to send a lot of parallel requests; see coap-10 section 4.7 and draft-bormann-core-congestion-control for more detail.)  So when is that the right strategy and when does the server want to make the client slow down?  There should be some discussion of this in a future version of this draft.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 12 Jul 2012 07:46:34 +0000

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,

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.

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 13 Jul 2012 07:43:05 +0000

Hi Carsten,

Thanks for your comments.

I think point (1) is OK, i.e. the unit can be both milliseconds and mibiseconds. Or maybe it better define the unit to be mibiseconds, as [x milliseconds] > [x mibiseconds], i.e. a client using milliseconds will not violate the block minimum time.

Point (2) is also interesting, the mechanism could also be used for different requests by the same client. Your example of a client browsing the server is a convincing argument.

Point (3) is more tricky. According to coap-10, a message is open until the related ACK is received. I am not sure though if the client has to wait with issuing the next request until it received an ACK, and if the server should use the ACK to slow down the client. In my view, the server should send the ACK as soon as possible, to indicate it received the CON request. If it cannot immediately deliver the response, decoupling of ACK and response is required, and piggybacking is not used. (Although I think that in the block GET case, most often the server already has access to the whole resource when sending the response to the first block request.)

I agree with the observation that the client should not open too much connections at once, i.e. it should avoid something similar to the "abuse of TCP" discussed in draft-bormann-core-congestion-control. Nevertheless, it is currently not mandatory for the client to wait for an ACK (or CON response if there was no piggy-backing as discussed above) before sending the next request. Therefore, the client can do multiple concurrent GETs within the same block transaction, and the "BlockMinimumTime" option can keep that within limits.

Indeed we can add some discussion on point (3) in a future version of the draft.

Best regards,
Bert

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: 09 July 2012 15:43
To: Bert Greevenbosch
Cc: [email-masked]
Subject: Re: [core] Upload of draft for "BlockMinimumTime" option

Hi Bert,

this is interesting.

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 16 Jul 2012 07:19:44 +0000

Hello Esko,

Thank you for your comments.

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

regards,
Esko

Hello all,

 
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.