Re: [Sip] Loop detection; Not a bad thing to have

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

inline.

Sachin Shenoy wrote:
> Hi,
> Loop detection was made optional in RFC 3261. Now it seems
> that, due to a problem with its processing at stateless proxies,
> loop-detection cannot be performed correctly (as it is given in RFC
> 3261) at stateless proxies.
>  
> I think loop detection is not a bad thing to have. Our problem with
> loop detection is not because loop detection itself has problems.
> It is because we tried to overuse the branch-id parameter
> for too many things.
I disagree. Your assessment is quite at odds with my recollection of the 
history here.

The problems we had with loop detection were that it became increasingly 
unclear about what a loop was, as opposed to a spiral. Initially (in 
rfc2543), a loop was any request that arrived at the same proxy (there 
were no spirals). It became clear that this was broken, so we had to 
consider changes in the request URI. Then, we ran into cases were other 
fields would change, such as Route headers, and those had to be taken 
into account as well. Real implementations were frequently getting this 
wrong, hampering interop and proper functioning of applications. As we 
began to realize that more and more headers might need to be taken into 
consideration, it became clear that properly doing loop detection was 
simultaneously ill-defined and complex to implement (potentially 
requiring hashes of the entire message).

That is coupled with the fact that such loop conditions will probably be 
rare in deployed networks. Unlike IP routing, SIP routing is 
considerably more static, and I consider the likelihood of real loops a 
rare one outside of a lab. Thus, its appropriate to handle them in a way 
which perhaps consumes more resources, at the cost of much lower 
complexity, and more importantly, proper operation in the normal case. 
Thats the max-forwards mecahnism. It is much easier to implement, always 
correct in the normal case (i.e., it won't mis-detect loops), and much 
more interoperable.

In other words - this is good engineering practice. We don't worry about 
optimally solving a corner case, we optimize for the baseline case.



> The purpose of branch-id parameter has
> changed over time, but there seems to have been little or no
> attempt to redesign mechanism of loop-detection w.r.t. these
> changes.
>  
> I suggest removing the loop detection part from the branch-id
> parameter and placing it in a new parameter. Having loop detection
> done using a separate parameter would avoid it from interfering
> with branch-id's primary use as transaction identifier. 
I am at a loss as to why you believe this will solve all the ails of 
loop detection. It is very easy to combine the functions of unique 
identification along with the change-detection functions of loop 
detections. You merely include a transaction ID as part of the long hash 
you are already doing. I fail to see why that is hard.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip