Subject: RE: [SIP] Discussion of Default Timers

From: "Kevin Summers" <[email-masked]>
Date: Tue, 2 Jan 2001 12:30:18 -0600

With regards to (3), this timer really should be configurable (our
implementation allows it to be). A pretty important attribute to be able
to control, in my mind.

Kevin

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 11:55 AM
To: Dean Willis
Cc: IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers

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

Dean Willis wrote:
> 
> 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

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

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

---

From: [email-masked]
Date: Tue, 2 Jan 2001 14:13:21 -0700

I would imagine that 'six proxy' architectures will eventually fall by the
wayside. Today, even, I'd imagine that for most networks, the majority of
those six proxies are either ALGs controlling FWs or stateless proxies that
are thrown in to achieve greater scalability or availability.

Whether or not we will always consider a SIP ALG to be a proxy, I doubt that
the ALG function will be going away anytime soon - ALGs will always be a
source of latency as long as the FW/NAT function is considered useful at the
edges of a VoIP network (though the ALG cost will not be realized in
intradomain gateway-to-gateway calls, for example). Stateless proxies used
for load sharing or fault tolerance, however, will go away, I think; they'll
be replaced by hardware load-balancers, or what have you, that will provide
scale and availability at near-router costs in latency. So, I suppose from
my perspective it is realistic to adopt the 'deploy fewer proxies'
philosophy in the long term.

In the short term, a full second or more of post-dial delay is not uncommon
for international calls in the PSTN today. We are talking about signaling
latency, not media latency. Media latency is widely reputed to be audible
and annoying after around 250ms. Signaling latency becomes problematic only
when the cross office max is so vast that the user becomes frustrated, hangs
up and tries the call again, which generally won't happen until some serious
time has passed. That much said, I do think SIP's timers are reasonable
sized, considering that the cost of not re-transmitting when a packet has
been lost to a recoverable network error is, of course, increased post-dial
delay (for that admittedly small percentage of calls). So I suppose I like
the '100' option as a short-term solution. Sending 100 is generally a
configurable option on proxies in my experience. It generates some
additional busywork for the network, but certainly less so than reprocessing
INVITEs.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 10:26 AM
To: IETF SIP (E-mail)
Subject: [SIP] Discussion of Default Timers

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.

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

---

From: "Gross, Gerhard" <[email-masked]>
Date: Tue, 2 Jan 2001 14:56:15 -0800

Another possible source of signaling latency
can come from policy management and AAA.
During call setup, one or more policy/AAA servers
may need to be accessed for policy decisions,
authentication tokens, etc. Most policy decisions
will likely be handled intra-domain, only adding
a small amount of latency. Inter-domain signaling,
such as that which may be needed for AAA (clearing-
house access) is probably not negligible.

Gery

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 02, 2001 1:13 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [SIP] Discussion of Default Timers
> 
> 
>

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 3 Jan 2001 00:37:38 -0500

> 836ms round trip.

50ms for a stateless proxy is also rather bad. If a proxy needs that much
time to process a message, it's likely to be performing some fairly advanced
logic, hence the extra overhead of becoming stateful should be rather
minimal. I guess that's equivalent to your option 2.

---
Igor Slepchin

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2001 14:53:38 -0600

Has there been any consideration or thought to introducing network
selectable timers?

Just off the top of my head, but it seems that it wouldn't be too difficult
to just TELL the UA how long their timers should be on a per call basis. For
instance, if you send an INVITE to your local SIP proxy, the proxy could
send back appropriately estimated timers for that call that the UA then uses
for the duration of that context.

That way, you have a default setting specified in the RFC, and if the proxy
knows that you're likely to unnecessarily retransmit (maybe it's been
datafilled to know that some outbound routes take a long time to process, or
that network traffic is high right then) it can direct the UA to fine-tune
it's timers to use when signalling to the proxy for THAT call context.

Also, and I don't know where everyone's expertise lies, so I may be
preaching to the choir here, please keep in mind tremendous latentcies
involved in wireless applications (and I'm not talking wireless ethernet
either, I'm talking cellular). There is no way any packet is going to get to
a cell phone or other cellular device in even remotely the latentcy figures
I've seen discussed on here. If you can transmit a packet from a SIP proxy
to a SIP UA sitting on a PDA or cell phone in 10ms you'd be internationally
famous. It might take several hundred ms just to get a raw UDP packet from
the edge of a wireless data network out to the mobile station under some
standards.

In that context, I would recommend longer timers, but for a LAN situation
that could degrade performance, which is why I bring up sending the timers
appropriate for that network scenario up.

If I know I'm calling Poland from Dallas, I also know to expect a longer
than normal time that I'll have to wait for the call to go through. If I'm
calling someone at their desk down the hall, I'm not going to wait as long.

Thoughts?

Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 12:36 PM
To: David Frascone; IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers

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

----- Original Message -----
From: "David Frascone" <[email-masked]>
To: "IETF SIP (E-mail)" <[email-masked]>
Sent: Tuesday, January 02, 2001 12:49 PM
Subject: Re: [SIP] Discussion of Default Timers

> 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.
>
> On Tue, Jan 02, 2001 at 11:26:09AM -0600, Dean Willis wrote:
> >
2543.
the
6ms/1000km,
total of
Everybody
expiration

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2001 15:47:18 -0600

Ah... Should have read further back into the thread than I did.

If I read 2543 correctly, it already allows for timers on the clients to be
autonomously extended (but not shortened) by the client without any server
interaction.

I guess I would recommend that we consider adding the following (along the
lines of the retry-after header):

----<snippet start>----

response-header ...
                | Context-Timers

Header field              where       proxy ACK BYE CAN INV OPT REG
-------------------------------------------------------------------
Context-Timers           100,18x        -    -   -   -   o   -   o

Context-Timers

The Context-Timers response-header field MAY be included to RECOMMEND to a
client or server on a per-hop, per context basis, to use timer values
different than the default SIP values on a 1xx response from an INVITE.
These timers would then be considered to be in effect for the remainder of
that call context. The remaining time left of any pending timers upon
processing the response would be deducted from the values specified in the
response, and the timers updated with the result.

Additionally, this response-header MAY also be included as part of a final
200 response to a REGISTER in order to update the timer lengths
semi-permanently over all call contexts for that registration period. Timers
received in 1xx class responses take precendence over those received in
response to a registration.

Context-Timers = "Context-Timers" ":" (( 1# (Timer-name "=" length) )
*(";"))

timer-name = RFC defined timer string
length = timer interval in ms.

Example:

Context-Timers: T1=800;T2=1200

Would update timers T1 and T2 to 800ms, and 1200ms, respectively. Note, that
if the length of the timer specified is SHORTER than the default minimums
specified in the RFC, that the value is discarded and ignored.

----<snippet end>----

Start throwing darts... I would think this sort of arrangement would keep
everyone happy by letting them have their proxies tell the subtending UAs
whatever values are appropriate to use in that network at that moment
(perhaps even for that particular call). For instance, if the proxy knows
that it's slow, or that it's going to have to go off and do something
special with this request, it can tell the UA to hold on a bit longer than
normal. If the network architecture itself is slower (wireless access) then
it can tell UAs who might have migrated from a LAN connection that they need
to give the system a bit more time to do things now, etc...

Again, off the top of my head, so if there's errors in the syntax or
reasoning, I'm not surprised. Just throwing something out there for
consideration.

Brian Stucker
Nortel Networks

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 11:55 AM
To: Dean Willis
Cc: IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers

/sean

2543.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 3 Jan 2001 18:35:20 -0500

-----Original Message-----
>From: Brian Stucker [mailto:[email-masked]]
>Sent: Wednesday, January 03, 2001 4:47 PM
>To: Sean Olson; Dean Willis
>Cc: IETF SIP (E-mail)
autonomously 
>extended (but not shortened) by the client without any server interaction.

Correct. This is the purpose of the Timestamp header. The client places it
in a request, and its mirrored in the response. The client can use the
measured RTT to adjust its timer. The information can be cached or
remeasured as needed. This solves the problem that has been discussed in
this thread.

>I guess I would recommend that we consider adding the following (along the
lines of the 
>retry-after header): 

There is no need for this header, as far as I can tell. I don't see why the
server would tell the client what to do here.

What is needed is a way for the server to measure the RTT to the client and
back; thats possible by allowing the Timestamp header to be placed in the
final response, and then have it reflected back in the ACK. This is not in
rfc2543. It can be added to bis if people feel strongly about it. 

Henning wrote:
> 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.

I think you will see much more than two. In large, deployed networks,
hierarchy is introduced in order to provide manageability and better scale.
Many of the providers I have spoken to are deploying several layers of
proxies in order to build out their networks. Furthermore, SIP calls may
traverse proxies that provide specific services, increasing the count. A
good way to get a feel for the likely count is to count how many message
transfer agents an email passes through; these are akin to proxies in their
role as routing devices. You will probably see that it is many.

Jon Peterson wrote:
Stateless 
> proxies used

I think that depends on how you want to do the balancing. A proxy is
different than a hardware load balancer in that it can perform smarter
SIP-layer-aware processing. For example, a good stateless SIP proxy might
divide up phone calls and route them amongst gateways based on phone
prefixes. In some sense, this is load balancing, and in others, its not.
Hardware load balancers are useful for creating a large "virtual" proxy that
appears to the SIP network like a single proxy, although its constructed
with many actual proxies, each hiding behind a load balancer. This is
because hardware balancers are only good at distributing load across
homogenous devices. When the devices you want to load balance across are not
homogeneous, and the routing decision becomes application specific, you want
a proxy, not a hardware load balancer.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 3 Jan 2001 17:51:47 -0600

I can think of a reason you might not get the information you need with a
timestamp header. What if the proxy suspects (by some algorithm, possibly
averaged timestamps) that a particular route or set of routes is going to
exceed the default timers that the client may be using? It would be nice to
tell the client as fast as possible (ie. on a provisional response) that
outbound legs beyond the proxy are likely to take awhile to process a
request.

Take the example a UA sitting on a LAN sends an INVITE to his local proxy,
and the proxy forwards that INVITE to another proxy that serves a wireless
network which sends it off to the wireless UA.

The timestamp (if I understand how you're using it correctly) would either
report one of two conditions:

1. The timestamp would bounce back in the 1xx response to the LAN UA and
show a short time interval (say 20ms) round-trip, which wouldn't correctly
characterize the actual time it's going to take for the entire signalling
path to complete.

2. The timestamp would bounce back from the wireless UA, possibly AFTER the
timers had expired on the LAN UA.

It would be useful if instead, the wireless network proxy could tell the LAN
proxy, "Hey, I'm slow, here's some reasonable timers to use for this call"
which the LAN proxy could then send back to the LAN UA to adjust their
settings.

-or-

If the LAN proxy through some method of discovery (datafill, network
analysis, etc.) had enough reason to believe that the call would take awhile
(i.e. routing to a .ch domain from a .uk domain; or any requests that are
routing to a known wireless data network) tell the UA immediately in the
provisional 1xx response.

According to the copy of RFC-2543bis02 that I'm looking at, the timestamp
will only take care of the first leg, and only by letting the client time
the request (which he could do without the header anyhow). It doesn't appear
to me that it helps with downstream adjustments. Maybe I'm reading it wrong.

I could see where it would be pretty useful to let proxies signal the
current network condition outside of the local network to the client.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, January 03, 2001 5:35 PM
To: Stucker, Brian [RICH2:WI41:EXCH]; Sean Olson; Dean Willis
Cc: IETF SIP (E-mail)
Subject: RE: [SIP] Discussion of Default Timers

-----Original Message-----
autonomously 

lines of the 

Jon Peterson wrote:
Stateless 

-Jonathan R.

---

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 9 Jan 2001 14:56:12 -0600

Any thoughts on this from anyone? I really do think this would be something
useful to add to the specification to help SIP networks deal with traffic
conditions, network latentcy, etc. in a very effective and targeted manner
without much complexity.
 
Brian

-----Original Message-----
From: Stucker, Brian [RICH2:WI41:EXCH] 
Sent: Wednesday, January 03, 2001 3:47 PM
To: Sean Olson; Dean Willis
Cc: IETF SIP (E-mail)
Subject: RE: [SIP] Discussion of Default Timers

----<snippet start>---- 

response-header ... 
                | Context-Timers 

Context-Timers 

Example: 

----<snippet end>---- 

Brian Stucker 
Nortel Networks 

-----Original Message----- 
From: Sean Olson [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, January 02, 2001 11:55 AM 
To: Dean Willis 
Cc: IETF SIP (E-mail) 
Subject: Re: [SIP] Discussion of Default Timers 

/sean 

2543. 

> 3) Change the default timers. 
<http://lists.bell-labs.com/mailman/listinfo/sip>  

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