Subject: [Sip] draft-ietf-sip-fork-loop-fix-01 : deprecate spiralling for forking proxies

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 16 May 2006 19:34:20 +0200

Consider the following alternative as a solution to the exponential message problem: deprecate spiralling for forking proxies

"A proxy that forwards a request to more than one destination MUST NOT forward it to an element (i.e. host/port/transport) which is already in the via list of that request"

This avoids loops caused by forking (even before they materialize), avoids potential HERFP issues, is easy to implement and more efficient than digest-based loop detection.

Regards,

Jeroen

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 21:45:41 -0400

On Tue, 2006-05-16 at 19:34 +0200, Jeroen van Bemmel wrote:
> Consider the following alternative as a solution to the exponential
> message problem: deprecate spiralling for forking proxies

That's probably not a good idea.  We see quite a lot of instances where
requests spiral, sometimes intermixed with forking.

But I don't think the computational load is as high as people imagine.
First off, everybody agrees that the load for processing one passage of
any particular message is o(N), where N is the number of Via's in the
message.  But processing a SIP message is already o(N), because its
bytes have to be copied.  So the asymptotic behavior is no worse than it
is now.

The second question is how big is the constant, how much work does it
take to compute the digest?  The digest doesn't have to be
cryptographic, because it is assumed that nobody in the loop path from
the proxy to itself is rewriting the digests.  (If a malicious agent was
in the loop, it would be suffering from exponential load, too.)  So the
digest can be a simple hash, which is as fast to compute as any ordinary
string operation.  Of course it is not a unique encoding of the control
fields of the message, but that's OK, since one can append the control
fields themselves, or append a pointer to the proxy's internal record of
the transaction for the transit of the message, to check in the rare
cases where the hash collides.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 29 May 2006 08:40:06 +0200

Dale,

> requests spiral, sometimes intermixed with forking.

Such legitimate cases, if they exist, could be converted into non-spirals by 
using either one of DNS aliases, additional IP addresses per interface, or 
separate ports for the first, second and in general Nth pass

> bytes have to be copied.  So the asymptotic behavior is no worse than it

I agree, and others have also pointed out that N tends to be small in 
practice.

> cases where the hash collides.

You can make the hash collission arbitrarily unlikely by increasing the 
number of bits in the hash. You already have a pointer to the proxy's 
internal record (Via branch id of the previous iteration) but that does not 
work for stateless proxies

But since you're pointing it out: for a forking proxy, which by definition 
must be stateful, it could be specified that when forking it needs to go and 
check any previous record it has of the transaction: iterate over the via 
headers, when found lookup the transaction using that via's branch, and 
compare the set of fields that are supposed to show some change

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 29 May 2006 14:52:30 -0400

On Mon, 2006-05-29 at 08:40 +0200, Jeroen van Bemmel wrote:
> must be stateful,

I think you can make a forking proxy that is not stateful, by burying
the needed information in the Vias that the proxy constructs.  Not that
that would be a very useful thing.

Dale