Subject: [SIP] Discussion of Default Timers

From: "Dean Willis" <[email-masked]>
Date: Tue, 2 Jan 2001 11:26:09 -0600

I've started to wonder about the retransmission timers recommended in 2543.

The basic assumption is that VoIP networks will have round-trip times of
less than 500ms. This seems to be a valid assumptio for the medai path, but
remember -- with SIP, the SIGNALING path is not necessarily thesame as the
MEDIA path. And the timers apply to the SIGNALING path.

Many of the architectures I'm seeing have three thousand kilometers, ten
routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of
836ms round trip. With default settings, the originating UA is going to
resend its INVITE after only 500ms unless response is received. Everybody
wants to use stateless proxies for performance reaons. So, nearly every
INVITE gets sent twice. This can be severely detrimental to the function of
a proxy that is operating at near peak capacity -- in fact, it basically
cuts the peak capacity of a proxy in half whenever proxy chains are
configured in such a way that T1 is regularly exceeded.

There are a couple of alternatives that come to mind:

1) Deploy faster proxies.
2) Deploy 100-generating proxies at all levels to prevent timer expiration
due to downstream latency.
3) Change the default timers.

Thoughts?

--
Dean Willis

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 02 Jan 2001 12:44:33 -0500

> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of

If you have a router that takes 10 ms, you should ask for your money
back (or, better yet, donate it to a networking museum). Obviously, you
can have queues longer than that; I would hope that in the long run,
some form of diff-serv marking will basically make signaling
queueing-free. Thus, with an alternate architecture of two proxies and
fast routers, we get 18 ms speed-of-light and 100 ms for proxies.

> wants to use stateless proxies for performance reaons. So, nearly every

It would be interesting to see how much performance is actually lost by
keeping transaction state. My perception is that our proxy spends most
of its (wall clock) time waiting for external lookups (DNS, location
database), which would presumably not depend on stateless vs.
transaction-stateful.

> 3) Change the default timers.

Which obviously comes at a cost of significantly longer call setup
delays if the first packet gets lost.

4) Use fewer proxies. I have a hard time seeing why you really need more
than two (outbound and inbound) proxy in most cases. This should be true
for email as well (there are two hops to the list and two from the list
to me), although there seem to be companies where email hops along
internally for various Notes/Exchange/IBM Profs translators and who
knows what else.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Sean Olson <[email-masked]>
Date: Tue, 02 Jan 2001 11:55:13 -0600

I agree that this is a problem and it is aggravated in the
case of wireless access where latencies are even larger.

Regarding the alternatives you list:

1) Faster proxies -- this is basically chasing rainbows. The processing
   delay can only be cut down so much and it is prone to break when
   new topologies introduce additional proxies

2) More statefull proxies -- This seems like a reasonable approach
   for many deployments (enterprise and GSTN gateways in particular)
   but of course can't be fixed by standardization, i.e. we can't
   mandate this (at least in the SIP spec)

3) Changing the default timers -- I like this approach but I think
   it isn't realistic given the current implementations. How many
   implementations hard-code this value I wonder?

I would recommend a combination of alternatives 2 and 3 for 
most architectures. Perhaps this could be part of a larger set
of recommendations in a BCP?

/sean

---

From: David Frascone <[email-masked]>
Date: Tue, 2 Jan 2001 12:49:46 -0600

Hmmm, I think your router lag is a bit off.  Doing a ping from Dallas, TX to
somewhere in China (www.hackersquest.gomp.ch) yeilds ~160ms round trip time.

And, I'm 24 hops from there.  24 * 10ms would be 240 ms of router lag alone.

So, I think your calculations are a bit off.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 2 Jan 2001 12:36:01 -0600

Well, those are the rough rules of thumb we used in network design just a
few years ago. Routers often perform much better these days -- assuming you
don't hit head of line blocking, small pipe serialization delay, an OSPF MST
recalc, a sluggish store-and-forward firewall,  congested MAE, or some other
annoyance  en-route. 10ms per router does represent a useful outer bound for
planning purposes. 3ms is probably closer to mean.

And the particular destination you listed www.hackersquest.gomp.ch is
hanging right off the uunet backbone -- 180 ms from my uunet-connected
router. There are worse routes.

But in any case, I have seen trial deployments where large numbers of T1
expirations occur.

Even if network transit time is only 180ms, a couple of proxies in between
can still easily push us over 500ms.

--
Dean