Subject: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 12:16:31 -0500

Drage, Keith (Keith) wrote:

> Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the
> text that allows pre-existing Route headers to be used in the initial
> transaction of a dialogue, or in a stand-alone transaction.
> 
> 	"8.1.1.7 Request-URI The initial Request-URI of the message SHOULD
> be set to the value of the URI in the To field. One notable exception is the
> REGISTER method; behavior for setting the Request-URI of register is given
> in Section 10. Another exception is the case of pre-existing Route headers;
> in that case, the procedures of Section 12.2.1.1 as they pertain to the
> Request- URI are followed, even though there is no dialog." 

Right. We'll add a bit more text to explain what a "pre-existing route" is.

> 
> A set of Route headers created using the Record-Route mechanism carries the
> mechanism to ensure that when the route traverses a spiral, all the URLs in
> the Record-Route headers are unique, and therefore that the set of Route
> headers is also unique.

Actually, I am not sure thats really needed anymore for routed requests. 
Here's why. Remember, the point of loop detection is to reject a request 
when you know that its processing will cause you do to the same thing to 
it you did last time. Proxy processing is not based just on the URI; in 
the case of Route headers, the overall processing is the same only if 
the Route set through the loop has not changed.

One of the things we have now in bis is that a proxy computes, as part 
of the via branch ID, a hash of those things in the request that affect 
its processing. Effectively, if this includes a hash of the route set, 
there is no need to ensure that the URI in the route set are not 
identical. Realistically I expect they almost always would be anyway, 
though.

I am beginning to wonder, however, whether or not this whole business of 
loop detection is worth the trouble. The Max-Forwards mechanism provides 
a sufficient way to ensure that they don't persist forever. The loop 
detection mecahnism is more efficient, but given the probability of 
occurence in a well-engineered network, I'm not sure its worth all the 
pain it causes, and it does cause pain. A proxy has to hash over a bunch 
of headers that it otherwise might be able to ignore...

Anyone for deprecating loop detection? A proxy that doesn't do it would 
have to insert max-forwards if not already present, that is the penalty. 
  We also need a minimum value for Max-Forwards, something like 20 is 
more than sufficient, I think.

This is has the nice side effect of making the branch ID just a pure 
transaction identifier, as it should be.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: Vijay Gurbani <[email-masked]>
Date: Tue, 08 Jan 2002 12:42:17 -0600

Jonathan Rosenberg wrote:
[...]
> Anyone for deprecating loop detection? 

Deprecating is fine since it has the side effect of making the branch ID a
pure transaction identifier.  I don't think it will have any effect on
spiraling -- in fact, if the branch ID is a pure transaction identifier,
a spiral will simply be counted as a new transaction (simply based on the 
branch ID in the topmost Via) at the receiving SIP server.

Only thing we loose is that at least with loop detection, unwanted requests 
are discarded right away, instead of lingering in the network for a while.

> A proxy that doesn't do it would have to insert max-forwards if not 
> already present, that is the penalty. 

I sense an ambiguity here in reading and parsing your statement -- are you 
saying that proxies should either (a) do loop detection, OR (b) insert a 
Max-Forwards if not present?  If so, I really think providing this choice 
will be a nightmare.  -06bis should simply not mention loop detection and 
state that a proxy MUST add a Max-Forwards header to downstream requests, if 
one was not present already.  Of course, the 482 response code should be 
maintained for backward compatibility.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Jan 2002 20:42:43 +0200

Hi,
 
>more than sufficient, I think.

Do we need to specify a minimum value in the spec? I think the value is
something which is very dependent on the size and architechture of the
network, and should be configurable. 

Also, are proxies allowed to change the value? For example, I may use
100 when I call from my SIP phone, but an administration proxy in my SIP
network may then decrease it to whatever value. Also, if I call from
network A to network B, network B's "border proxy" may also choose to
change the value when it receives the request.

Also, IF we choose to only use the MAX-Forwards header, I guess we would
have to make it MANDATORY - or at least make it mandatory for a proxy to
insert the header if it receives a request without it?

Otherwise I don't have anything against the proposal.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 14:16:51 -0500

> branch ID in the topmost Via) at the receiving SIP server.

Right.

> are discarded right away, instead of lingering in the network for a

Right. This is what I meant by loop detection being more efficient than 
max-forwards, but the cost is high.

> Max-Forwards if not present?  

No, my apologies. The "penalty" here is additional specification text 
and required behavior of a proxy.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 14:23:55 -0500

Christer Holmberg wrote:

>>have to insert max-forwards if not already present, that is the
>>
> penalty.
> 

That is a recipe for disaster. Big disasters.

Remember, calls go between domains that are frequently not in any kind 
of business relationship. I have no way of knowing what kind of network 
is downstream. So, we choose a value which is sufficiently large to 
cover all realistic cases. Having it configurable means it could be 
right today, but wrong tomorrow. Shall I have all my customers support 
calls get forwarded to you, Christer, so you can explain why a call 
yesterday won't work today because a different network provider 
installed a new proxy?

> change the value when it receives the request.

Yes, they can change it. But you need to be careful in that, if a proxy 
always ups it on every loop through it you get no protection at all. 
Really, it should only ever lower it, and only for very good reason. We 
should think about adding that to the spec.

> insert the header if it receives a request without it?

That is what I proposed, yes.

-Jonathan R.

---

From: "Neil Deason" <[email-masked]>
Date: Tue, 15 Jan 2002 12:31:18 -0000

> yesterday won't work today because a different network provider 

If we have no way of knowing what network SIP will run
over now, or in the future, what is guaranteed to
always be a large enough number? Though this will 
create inefficient network usage. It is unclear how 
B2BUAs would interact with Max-Forwards headers as they 
pass through their UAS|UAC state machine. RFC2543 UAs may 
(i.e. will) not typically add in Max-Forwards 
RFC 2543 Proxies certainly wont add it where omitted.

Cheers,
Neil
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

<snip>

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 19:48:44 -0500

> RFC 2543 Proxies certainly wont add it where omitted.

The same issues arise for IP networks. Their solution is to just have
a really big number, 255 in their case.

I would not object to a similarly large number, I think 70 should
easily suffice. You have to remember that these are going to be
extremely unlikely events, so there is little penalty to a larger
number in reality.

-Jonathan R.