Subject: [Lwip] Coap load management

From: Hui Deng <[email-masked]>
Date: Thu, 5 Jan 2012 15:49:33 +0800

Hi Carsten,

In the CoAP-HTTP proxy model, there is a common situation that too
many requests from HTTP enabled web may overwhelm some constrained
node. So we believe the coap-http proxy should do something to manage
the load from the web to the constrained network.

In order to achieve this goal, the proxy creats a thread for each of
the request from the web, and initiates a semaphore for the
interactive control. If the number of requests exceeds a certain
threshold, the proxy will deny the request or set up a timeout-able
waiting scheme for the request.

The pseudo code is as below, and we would like to test this in our lab
environment.

1）simply reply with "service unavailable" if currently no resource can
respond.
Http_CoAp_thread(char* pnodename,...)
{
   rethandle=createevent(pnodename);// creat the semaphore
   if(ERROR_ALREADY_EXISTS == rethandle)// if it is busy
       {//reply with "Service Unavailable"
           sethttpstate(httpbuf,503,"Service Unavailable");
           sendhttp(socket, httpbuf);
           releaseresource();
           return;
       }
   else
       {
           ……//handle the coap request
           setevent(rethandle);// release
       }
       return;
}

2)waiting mode
Http_CoAp_thread(char* pnodename,...)
{
   rethandle=createevent(pnodename);// create the semaphore
   if(ERROR_ALREADY_EXISTS == rethandle)// if alreay exist
       {
           // wait per policy
           retdw=waitforsignleobject(rethandle,xxx);
           if(retdw==EVENT_OK)// get the access permit
               {
                   goto eventok；
               }
           else// timeout
               {//Reply with "Service Unavailable"
                   sethttpstate(httpbuf,503,"Service Unavailable");
                   sendhttp(socket, httpbuf);
                   releaseresource();
                   return;
               }
       }

eventok:
        ……//handle the coap request
       setevent(rethandle);// release
       return;
}
By the way, would that be possible to add those information to the basic
guidance document? thanks

Best regards,

-Hui

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jan 2012 14:53:27 +0100

Hi Hui,

the obvious way to handle great client GET load at an intermediary is to set up a cache.
This makes sure the origin servers don't get requests from this one proxy more often than with a period of approximately max-age.
(Using an observation relationship on the CoAP side, this can be further optimized.)

To me it seems the load shedding mechanisms you describe create approximately the same amount of state as a cache would, with the drawback of introducing unpredictable 500 responses.  A cache also already includes the logic you sketch in (2), as a pending cache entry will inhibit further requests.

So to me it seems a short discussion of the benefit of and implementation techniques for caching intermediaries would be the best way to approach this subject.  A useful contribution would be to dig through the massive amount of literature in this space and select a small subset that is useful for LWIG.  (There even is a Wikipedia category: http://en.wikipedia.org/wiki/Category:Reverse_proxy -- most of these do way more than we need here, though.)

What do you think?

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 16 Jan 2012 15:48:13 +0100

Dear Hui,

Some considerations about resource caching at an HTTP-CoAP (HC) proxy
are also present in sections 4.2.1 and 4.2.2 of the http-mapping-02
draft (http://tools.ietf.org/html/draft-castellani-core-http-mapping-02#section-4.2.1).

Best,
Angelo

On Mon, Jan 16, 2012 at 14:53, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip