Re: [Sipping] comments on loop detection anddraft-campen-sipping-stack-loop-detect-00

[Thomas Froment <[e-mail]>]

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