[Sip] loop detection measurements (was Fwd: [Sipping] comments on loop detection anddraft-campen-sipping-stack-loop-detect-00)

[Robert Sparks <[e-mail]>]

Copying forward an older thread from SIPPING in case those  
participating in the fork-loop-fix conversation here hadn't seen it.

RjS


Begin forwarded message:

> From: Thomas Froment <[e-mail]>
> Date: May 19, 2006 8:56:59 AM CDT
> To: Jeroen van Bemmel <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Sipping] comments on loop detection anddraft-campen- 
> sipping-stack-loop-detect-00
>
> Jeroen van Bemmel wrote:
>
>> Thomas,
>>
>> Very interesting to have some numbers here
>>
>> 260/305 ~ 15% less calls/sec with loop detection. That would be ~  
>> 15% CPU, iff it is at 100% for the whole test - is it? (you say  
>> 13%, so perhaps you already compensated for this - I just want to  
>> understand how you came to this conclusion)
>
> You are right, when doing a test, CPU is not busy at 100%, it is  
> approximately between 85 and 90%.
> It is to notice we perform this kind of tests on our implementation  
> for a long time (based on sipstone, http://www.sipstone.org/),
> and I am really confident in injector system and in the results and  
> in general...
>
>>
>> RFC3261 is wrong in many aspects of loop detection.
>
> Is it documented somewhere? did you find a bug describing these  
> problems?
>
>> Could you run the same test, but this time only including the  
>> request URI and the topmost Route header (if any) in the hash?
>
> The current version *already* includes the usage of request URI and  
> the topmost Route header (only!) ... I did not even try to
> test the previous algorithm....
>
>> ----- Original Message ----- From: "Thomas Froment"  
>> <[e-mail]>
>> To: <[e-mail]>
>> Sent: Friday, May 19, 2006 12:43 PM
>> Subject: [Sipping] comments on loop detection anddraft-campen- 
>> sipping-stack-loop-detect-00
>>
>>
>> Taking into account draft-ietf-sip-fork-loop-fix-01.txt which  
>> recommends
>> the support of RFC3261 loop detection algorithm (instead
>> of the Max-Forwards mechanism), I would like to make some comments:
>>
>> 1/ The loop detection mechanism described in RFC 3261 seems  
>> confusing in
>> some points:
>>
>> - Section 16.6, §8 (when sending the request, adding the loop  
>> detection
>> hash on branch parameter) says:
>>
>> " Loop detection is performed by verifying that, when a request  
>> returns to a proxy,
>> those fields having an impact on the processing of the request  
>> have not changed.
>> The value placed in this part of the branch parameter SHOULD  
>> reflect all of
>> those fields (including any Route, Proxy-Require and Proxy- 
>> Authorization header fields).
>> This is to ensure that if the
>> request is routed back to the proxy and one of those fields
>> changes, it is treated as a spiral and not a loop (see Section
>> 16.3). (...)"
>>
>> First of all the "*fields having an impact on the processing of  
>> the request have not changed*" is confusing
>> for some people, because you really need to have a deep knowledge  
>> of SIP protocol to be sure on this point. (And
>> what about SIP extensions like Service Route?)
>>
>> Then "any Route" is, in my opinion confusing, is it really any  
>> Route or only top most Route?
>> I imagine this is only the top most route, and it would match the  
>> statement "
>> fields having an impact on the processing of the request", am I  
>> wrong?
>>
>> Third, the last paragraph is even more confusing:
>> "A common way to create this value is to compute a
>> cryptographic hash of the To tag, From tag, Call-ID header
>> field, the Request-URI of the request received (before
>> translation), the topmost Via header, and the sequence number
>> from the CSeq header field, in addition to any Proxy-Require"
>>
>> - Here, no Route header is mentionned anymore (neither Proxy- 
>> Authorization), should be clarified...
>> - the "topmost Via header":  this assertion is FALSE, if you take  
>> the "branch parameter" of Via Header, to compute your hash,
>> you will never detect any loop, since the generated branch will  
>> always be different !
>>
>> I first tried to find a bug in database, and only found one  
>> problem related to loop detection:
>> http://bugs.sipit.net/show_bug.cgi?id=648
>> "branch hash calculacation needs explicit comment for loop- 
>> detecting proxies"
>> Which is not pointing out the problem...
>>
>> Correct wording of the second paragraph may look like:
>> "A common way to create this value is to compute a
>> cryptographic hash of the To tag, From tag, Call-ID header
>> field, the Request-URI of the request received (before
>> translation), the topmost Via header *without branch parameter*,  
>> the sequence number
>> from the CSeq header field, in addition to *the top most Route*  
>> and any Proxy-Require or Proxy-Authorization header(s)*"
>>
>>
>> 2/ Looking at "draft-campen-sipping-stack-loop-detect-00", we also  
>> decided to bench the *existing* RFC 3261 algorithm
>> to be able to evaluate if an optimization is needed.
>> It is to mentionned, this bench was performed on a really  
>> optimized SIP stack and the loop detection, as well,
>> has been really carefully coded in order to minimize processing  
>> and memory usage
>> (just to anticipate objections like "is your algorithm really well  
>> coded?): as an illustration, loop detection is not performed if
>> a request is recognized as being a retransmission, and an  
>> optimized MD5 implementation is used as hash algorithm...
>>
>> Doing a simple proxying scenario,
>> using in injector the following "CALL ATTEMPT PER SECOND" (CAPS)  
>> scenario:
>>
>> injector
>> INVITE --------------> Proxy (under test) ---------------> server  
>> (UAS test)
>>
>> 100 TRYING  <---------- Proxy (under test)
>> 180 RINGING <---------- Proxy (under test) <-------------- server
>> 200 OK      <---------- Proxy (under test) <-------------- server
>>
>> ACK ------------------> Proxy (under test) ------------->  server
>> BYE ------------------> Proxy (under test) ------------->  server
>>
>> on a basic configuration,
>> WITHOUT loop detection, result is ~ 305 CAPS
>> WITH loop detection, result is ~ 260 CAPS
>> It means, ~13% of CPU is used for this fonction for a basic  
>> proxying scenario...
>>
>> We will try to provide the figures if we decide to implement draft- 
>> campen-sipping-stack-loop-detect-00
>> algorithm but, at first, it seems valuable to think of clarifying  
>> and/or optimizing current RFC 3261 algorithm...
>>
>> Thomas
>>
>>
>>
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
>
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip