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

[Thomas Froment <[e-mail]>]

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