Subject: [Sipping] Comments on lawrence-maxforward-problems

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 27 Dec 2005 19:15:24 -0500

On Sun, 2005-11-06 at 10:14 -0500, Jonathan Rosenberg wrote:
> I also like the suggestion for inclusion of the request message in the 
> body of the response for diagnostic purposes. One thing though - lots of 
> folks use a SIP request with Max-Forwards of 0 as a single-hop ping to 
> detect whether the downstream element is alive. Its really a waste to 
> always include the request body in the response for these, as its not 
> needed - this is truly a forced attempt at an error response.

- It's true that including the rejected request from a single-hop
"traceroute" request is inefficient, but it seems to me that such
requests are going to be rare compared to the audio packets, so the
overhead of including the rejected request should not be a problem.

- While restricting the sorts of registrations or forwarding allowed
could reduce infinite-loop problems, it strikes me that this is a
situation where any set of restrictions loose enough to allow people to
do what they want in practice will always allow inadvertent infinite
loops.  (Sort of like the expressive power of programming languages vs.
the ability to write infinite loops.)

- One thing that should be tidied up in the draft is the example formula
for the Max-Forwards for outgoing messages.  The current language has a
number of deficiencies.  The correct formula for equal-weighting of the
outgoing requests is:

    If the received request has Max-Forwards M and the proxy wishes to
    send it to N targets, then it can use

	    floor((M-1)/N)

    as the Max-Forwards on the generated requests.

    (If N = 1, this reduces to M-1.)

    In any case, the sum of the Max-Forwards on the outgoing requests must
    be less than the Max-Forwards on the incoming request.

- It seems that we can generalize the idea of reusing the Max-Forwards
quota when doing serial forking.  The rule that "the sum of the Max-
Forwards of the forward requests must be less than the Max-Forwards of
the received request" is then relaxed to "the sum of the Max-Forwards of
the un-answered forwarded requests must be less than the Max-Forwards of
the received request".

This means that Max-Forwards is no longer a limit on the total number of
requests generated during forwarding, but it remains a limit on the
total number of requests generated during forwarding that are in process
at any one moment.

Thus, this mechanism prevents the original example from flooding the
network with 2^70 requests at the same time.  But if the forking in the
example is made serial, it could still generate 2^70 requests over (a
very long) time.  However, this shouldn't be a significant problem
because any request that would cause flooding is stretched out over a
long time, which causes its transaction to time out.

It should also be possible to mitigate the problem of depth limitation
by having a proxy automatically turn parallel forking into serial
forking if it receives an inadequate Max-Forwards for parallel forking.
(It remains to be seen exactly how to do this.)

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP