Subject: RE: [Sip] Default value for Timer C (was #282)

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Jan 2002 15:32:33 -0500

(first version of this got caught in a list administrator trap for
 length - here's a shorter version. Apologies if both end up getting
 through)

------
I just realized I had fallen a little too deeply into the minimum value =
only deployed value
trap. 

Timer C needs to exist - a proxy element can't be expected to hold state
forever, it has
to have some point where it knows it can safely discard. If we don't discuss
that in the
specification, implementations will address it with local policy,
potentially to the ruin
of interoperation.

Elements in real networks will tune this value (the spec should clearly
point out that this MUST
be configurable). So, a provider could set up a system that would let you
work with AA
for 45 minutes (or even all day) if they wanted to (at least the proxies
wouldn't break the service).
Market pressures will eventually drive them providers to use values that
enable the applications
that people are willing to pay for.

So, I have to come back to the very starting point for this thread. Why do
we need a minimum
value? I think the 3 minutes we've negotiated so far has really been in the
spirit of a recommended
value, not a minimum.

We only need to specify a minimum if use of the protocol with a smaller
value will cause really
bad things to happen to the network (this is the motivation for the minimum
values for T1 yes?).
This is different metric than having really bad things happen to
applications running on the
network.

If the value is set to, say 32 seconds, bad things don't happen to the
network. There may be some
domains of control where its known that calls will complete fast or not at
all, and its perfectly
reasonable for intermediaries to discard state after 32s. If we make 3
minutes a minimum, we force
them to keep state longer than they need it, or be noncompliant, neither of
which makes much
sense given that they are satisfying the needs of their application.

So, I propose that we take what we've learned from the discussion so far and
state the following:
* Timer C must be configurable
* A recommended value for Timer C is 3 minutes
* A minimum value for Timer C is ? 

We haven't really been working to answer that last question - we've been
focusing on when
applications break, not when the protocol breaks the network. So, is a
normative minimum
really necessary? If somebody sets Timer C to zero, an INVITE transaction
will never complete,
which clearly breaks the protocol, so a minimum is needed. If the timer is
around the transmission
delay, the transaction can complete (though a race condition exists). So,
some value larger than
the transition delay is necessary. How much bigger? Probably not much.
Jonathan's originally
suggested 32 seconds. I think it could be much shorter - remember the metric
- what breaks the
network, not what breaks the applications. I propose the minimum be an RTT.

RjS

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 16:27:21 -0500

> applications running on the

No, we need to define minimums in order to guarantee interoperability. 
Relying on "if its wrong, the market pressures will make you crank it 
up", is not the right answer. That could be applied, in theory, to 
almost any aspect of the spec (for example, having max-forwards never be 
greater than three, which means a max of three hops. Its good for the 
network (less traffic), but bad for apps. I would rather not field these 
customer support questions. It should work.).

Bob has proposed some interesting ways to signal for more time:

> 1) Modify the FSMs to restart Timer C for every 1xx response and then
> have
> the UAS send a 1xx periodically to maintain the transactions in the
> proxies.

This one is nice, since it has the effect of requring insertion of 
traffic to refresh state. This helps make it immmune from DoS attacks, 
which your second proposal below is.

> 
> 2) Include the "expected time" the UAS will take to answer the call in
> the
> 1xx response and the proxies would set their Timer C accordingly. This
> would
> still require the UAS to retransmit the 1xx response if the call was not
> answered in time, but the proxies would only have to reset the timer
> when
> they saw the "expected time" value.

Well, a malicious UAS could set the value to infinity and blow out the 
state in proxies.

Another approach is the one I had proposed - do nothing. Let the proxies 
discard state, and I think it still works OK. Any comments on that?

-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

---

From: [email-masked]
Date: Tue, 8 Jan 2002 15:47:09 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> This one is nice, since it has the effect of requiring insertion of 
> traffic to refresh state. This helps make it immune from DoS 
> attacks
> ...

Yes. I'd like to avoid this approach, in part because it makes
firewalling far too difficult. I like ignoring the firewall issue
as much as the next guy, but it seems like the Bob's solution (1),
above, is much cleaner -- and it helps with the firewall case as well.

/a

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 8 Jan 2002 18:19:59 -0500

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
<snip>
> discard state, and I think it still works OK. Any comments on that?

Maybe I am missing something, but my reading of Section 16 requires that a
stateful proxy send a final response when all of the client transactions
have been terminated. This would result in a non-2xx final response being
sent to the UAC (namely 408).

Lines 2351-2357:
     A stateful proxy MUST send a final response to a response
     context's server transaction if no final responses have
     been immediately forwarded by the above rules and all
     client transactions in this response context have been
     terminated.

     The stateful proxy MUST choose the "best" final response
     among those received and stored in the response context.

     If there are no final responses in the context, the proxy
     MUST send a 408 (Request Timeout) response to the server
     transaction.

If this is correct, there needs to be a way to retain the state in the
proxy.

cheers,
(-:bob