Subject: [Sipping] comments on loop detection and draft-campen-sipping-stack-loop-detect-00

From: Thomas Froment <[email-masked]>
Date: Fri, 19 May 2006 12:43:04 +0200

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Thomas Froment <[email-masked]>
Date: Fri, 19 May 2006 15:56:59 +0200

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" 
> <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, May 19, 2006 12:43 PM
> Subject: [Sipping] comments on loop detection 
> anddraft-campen-sipping-stack-loop-detect-00
>
>
> for some people, because you really need to have a deep knowledge of 
> SIP protocol to be sure on this point. (And
> - 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,
> 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
> It is to mentionned, this bench was performed on a really optimized 
> SIP stack and the loop detection, as well,
> (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...
>
> 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
>
>
>
>
>