Dale R. Worley wrote:
The design goal in implementing loop detection is to detect and stop
infinite routing loops quickly. (The Max-Forwards mechanism will
always terminate them eventually.)
I agree that the design goal of loop detection should be to stop
uneccessary requests from utilizing the bandwidth and subsequent
processing power at intermediaries as they service a looped
request. The M-F mechanism neither detects loops quickly nor
does it terminate them in an expedient manner.
From a transactional viewpoint (and loop detection is a trans-
actional property to me) SIP has been designed such that each
request and response can be routed without knowing what happened
in the past, or what will happen in the future (the exceptions
are of course CANCEL and ACK to non-2xx, which must go to the
same downstream entity and thus require some a-priori knowledge
of a previous request. But there are heuristics to mitigate
even this). Each request or response in SIP is thus self-
contained. It seems incongruent to now say that a proxy cannot
authoritatively process a transaction because some other
intermediary holds a piece to a puzzle that it is not privy to.
In the most benign of circumstances, this may work as each proxy
contributes to the puzzle, but in the worst case, this will
cause a flood of requests to saturate the network (and the
proxies themselves) as each proxy leaves it to its downstream
neighbor to do the right thing.
The problem with loop detection is that it is difficult to construct
a heuristic that will successfully detect any significant number of
loops without blocking some legitimate non-loop request.
I am curious: can we state this with any certainity? It appears
that most proxies in SIPit do not support loop detection. For
those vendors that do have proxies supporting loop detection,
are there any cases where legitimate non-loop requests have been
blocked? It would be great to have a larger sample of people
asserting this. IMS systems tend to send the same request to
different application servers, so if this is indeed a problem,
I would expect that it would be a known problem there.
The position I am arguing for is that the only workable mechanism for
detecting and stopping loops is Max-Forwards -- any other rule will
be too restrictive and real-world applications will soon be hobbled
by it.
Absent some more hard evidence to support this, I, respectfully,
disagree. M-F already has demonstrated problems with it,
so I fail to see how it can be the only workable mechanism. This
will be akin to the SIP community consciously choosing something
that it knows to be flawed. While this may be an acceptable
compromise when there aren't any known alternatives, I don't
believe this is the case here. Hashing the normal suspects
-- Route header, R-URI, Proxy-Require, Proxy-Authorization, CSeq
number, To tag, From tag, Call-ID -- has not proved to be too
restrictive thus far, AFAIK.
Of course, this doesn't stop the exponential branching problem. That
requires a different mechanism.
Agreed.
- vijay
--
Vijay K. Gurbani, Ph.D. [EMAIL PROTECTED],research.bell-labs.com,acm.org}
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
