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

From: "Sachin Shenoy" <[email-masked]>
Date: Mon, 30 Dec 2002 00:42:49 +0530

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. 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. All other 
mechanism remaining the same as given in RFC 3261, I think,
this will allow implementations to support loop detection without 
much trouble.
 
Thanks
Sachin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Dec 2002 11:50:16 -0500

inline.

Sachin Shenoy wrote:
> 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
> 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
[email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Sachin Shenoy <[email-masked]>
Date: Tue, 31 Dec 2002 13:19:15 +0530

Please find my comments inline.

>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 
>simultaneously ill-defined and complex to implement (potentially requiring 
>hashes of the entire message).

I have to admit I am quite unaware (ignorant) about these real-world problems.

>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.

I have to take your word on this (that loops are rare). But sure it creates 
havoc once
it happens. (Simple tests where request from UA looped between 2 proxies 
ran for more
than 10 minutes. Where re transmissions of original INVITE from UA, the 
"Too Many hops" response and ACK for this just kept on circulating).

>optimally solving a corner case, we optimize for the baseline case.

I agree with this. Then can we assume (or hope) that in future standard
loop detection would be deprecated?

>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 

Here I was trying to address (solve) a particular problem where stateless
proxies cannot do loop detection. (There was an earlier mail which stated the
problem subject:"[Sip] BranchID in CANCEL & INVITE"). Stateless proxies
have to maintain same branch for CANCEL & INVITE. Now if stateless proxies
try to do loop detection, the branch could turn out to be different for CANCEL
& INVITE. (Loop detection part calculated for CANCEL could be different from
the loop detection part calculated for INVITE). This is why I suggested moving
the loop detection part out of BranchId.

I mentioned this solution being quite unaware of the real problems plaguing
loop detection.

Again, if this is some feature that has lot of inherent problems with it, I 
think
it is better to take it off completely.

Thanks
Sachin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Dec 2002 09:41:17 -0500

inline.

> 
>> 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 
>> 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.
> 
> 
> I have to take your word on this (that loops are rare). But sure it 
> creates havoc once
> than 10 minutes. 

That should not happen. Max-Forwards should be preventing that.

> Where re transmissions of original INVITE from UA, the 

The INVITE should not be retransmitted once the final response has arrived.

It seems your problems are the result of faulty software, not an 
incorrect approach to handling loops.

>> 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.
> 
> 
> the loop detection part calculated for INVITE). 

Not for any valid loop detection algorithm.

CANCEL and INVITE will both share the same To, From, Call-ID, CSeq 
number, request-uri, route headers, and a whole bunch of other fields, 
pretty much anything that might be included in a loop detection hash 
(although i still feel that the whole process is brittle and unneeded). 
Max-Forwards is easier to deal with at a stateless proxy.

-Jonathan R.

---

From: "Sachin Shenoy" <[email-masked]>
Date: Wed, 1 Jan 2003 02:26:07 +0530

please find my comments inline.

> That should not happen. Max-Forwards should be preventing that.

Max-Forwards did work in this case. But didn't prevent the above mentioned
problem.

> incorrect approach to handling loops.

Let me check and confirm these figures again (will take sometime).
But if I remember correctly the time taken for the request to go 70
hops forward & the "Too May Hops" response to take 70 hops
backwards was enough for the retransmissions to fireup.(Maybe
the implementation chose to queueup too many messages rather than
dropping them and as a result was not able to flush them out
properly). As you said this could be the case of faulty software,
I have to double check it.

> Not for any valid loop detection algorithm.

I think this is a known bug in the RFC3261 and has already been logged in
bugzilla.

http://www.sipwg.org/sipwg/show_bug.cgi?id=659

> (although i still feel that the whole process is brittle and unneeded).

CANCEL & INVITE need not share Require & Proxy-Require fields according
to RFC 3261. RFC 3261 explicilty states that CANCEL MUST NOT have
Require & Proxy-Require (Section 9.1), while INVITE may have them. An
implementation choosing to use these fields for calculating the
loop-detection
part would end up having different value for the hash. Placing this hash in
branch would break the transaction matching rules where CANCEL &
INVITE should have the same branch-id's (Section 9.1).

From what I can see there are 2 ways to go.

1. Deprecate loop detection.
2. Keep loop detection.

1. Deprecate loop detection.
    A non issue for me (actually I am for this).

2. Keep loop detection.
    If we choose this, let us take full advantage of it. Let it be possible
    for stateless proxies to detect loops. Let us take the loop detection
    part out of branch-id (which will solve the above mentioned
    problem) or find some other solution to the problem.

Anyway, I fail to see any advantage of retaining the loop-detection
part in branch-id. If anything it can only cause problems.
Keep unrelated things separate -  A good design practice.
We don't want to worry about things interfering with each other.
(In this particular case transaction matching & loop-detection).

Again, I am also for the Max-Forward solution as it is much simpler and
straight forward as you point. But then, some consensus have to be reached
on what has to be done with the existing mechanism of loop-detection.
Implementators (like me) should be given a clear direction to proceed with.

Thanks
Sachin

>"9.1 Client Behavior
> ...
> The CANCEL request MUST NOT contain any Require or Proxy-Require header
> fields."

> "9.1 Client Behavior
> ...
> A CANCEL constructed by a client MUST have only a single Via header field
> value matching the top Via value in the request being cancelled.  Using
> the same
> values for these header fields allows the CANCEL to be matched with the
> request it cancels (Section 9.2 indicates how such matching occurs)."