< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] back pressure


These are my 10 seconds thoughts ... sure some of them are wrong ... this is
a hard topic

A good test for all this stuff is if a proxy is totally bombarded and
overloaded then the traffic drops to a normal level, how fast the proxy
recover. Should be something like 10 seconds.

On 8/6/04 2:04 PM, "Jason Fischl" <jason@xxxxxxxxxxxxxx> wrote:

> Here is my proposed code for applying back pressure from the TU. It is a
> very simple approach. If the TU fifo gets above a certain size, start
> sending 503 messages with Retry-After header in them. TU back pressure only
> applies to incoming requests from the wire (excluding ACK).
> 
> Topics for discussion:
> - will it work at all?
Not sure - if the app using the stack empty the fifo after every select, it
will not work 

> - how big should the fifo be before backpressure is applied?
The trick is to do it in time not message count - It should be a few seconds
deep.  

> - how long should Retry-After be? currently random between 32 and 64 seconds
You need to keep track how long you have been in a congested state and make
the retry time an function of that. If c is congestion time, retry between c
and 2c might be a good start.

You might want to change both the drop and retry time based on method.
Register might be high priority, INVITE and SUB medium, and message and NOT
low. 

> 
> Additional places to add backpressure:
> - Transports should reject with 503 if the mStateMachineFifo is above a
> certain size
Likely very hard to do much faster than doing at TU fifo level.

> - If they get really behind, they should drop the request on the floor
yes. but note now you will get the retransmissions

> - Transport backpressure probably needs to apply to all incoming messages
> (not just requests)
I don't think so - the way to reduce responses is to reduce the number of
requests. it's bad to fail something after you have done most the work

> - SipStack will also reject application send with 503 if the
> mStateMachineFifo is above certain size. Note: this is the same fifo that
> the transports use.
Hmm - and the application will do what? Not sure this will help much, the
application is likely to rate limit itself. I could be very wrong here.

> - what do we do if the Transports are behind on transmitting messages? Could
> just drop them on the floor and signal a failure to the transaction. Need to
> think about the impact on a proxy.
this should only happen for connection oriented transports. For other types,
would want to reduce accepting requests.

If a TCP connection to device X backs up so we can't write to it, we should
503 the transaction trying to write to it regardless of how busy we are.

> 
> 
> void
> TransactionState::process(TransactionController& controller)
> {
>    Message* msg = controller.mStateMacFifo.getNext();
>    assert(msg);
> 
>    TransactionMessage* message = dynamic_cast<TransactionMessage*>(msg);
>    SipMessage* sip = dynamic_cast<SipMessage*>(message);
> 
>    RESIP_STATISTICS(sip && sip->isExternal() &&
> controller.getStatisticsManager().received(sip));
> 
>    // !jf! this is a first cut at elementary back pressure. hope it works :)
>    if (sip && sip->isExternal() && sip->isRequest() &&
>        sip->header(h_RequestLine).getMethod() != ACK &&
>        controller.isTUOverloaded())
>    {
>       SipMessage* tryLater = Helper::makeResponse(*sip, 503);
>       tryLater->header(h_RetryAfter).value() = 32 + (Random::getRandom() %
> 32);
>       tryLater->header(h_RetryAfter).comment() = "Server busy";
>       Tuple target(sip->getSource());
>       delete sip;
>       controller.mTransportSelector.transmit(tryLater, target);
>       return;
>    }
> 
> ....
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel