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