Re: Ri: RE: [Sip] Extension to Assure Congestion Safety

[Dean Willis <dean.willis@softarmor.com>]

On Thu, 2003-02-06 at 04:06, loretosa@vodafone.it wrote:
> thanks for informations.
> 
> but i'd like some papers/articles about latency in the
> internal nodes of IP Multimedia Subsystem like CSCF...
> and the others servers...
> where have you found the following informations? 
> 
> "Now, add aother 50 ms each for the P-CSCF, I-CSCF, S-CSCF, I-CSCF, S-CSCF, P-CSCF processing and we get another 300 ms for each hop, or 900ms. Add a little more for topology hiding gateways and the like, and we're at around 1800 ms."
> 
> best regards
> Sal

Well, there aren't a lot of "real" P-, S-, or C- CSCFs out there in the
wild, so my best suggestion would be to work from the performance of SIP
proxies used in wireline environments. 

These tend to have proxy transaction times ranging from just a few ms
(say, 8-10ms) for simple stateless "pure proxy" operations, up to around
250ms for complex operations such as topology hiding. Of course, if
external operations, such as database lookups, firewall behavior
modification, or Java garbage collection happen to occur, the times can
become much longer. Also relevant are things like "just exactly what are
you measuring", which can include things like serialization delay and
OS-level context changing. I would typically be inclined to measure the
time from when an incoming message is presented "on the wire" to a proxy
(fully serialized in), to when the outgoing message starts to appear "on
the wire" coming out. Of course, it's easier to measure times between
ingoing and outgoing as they cross an external monitoring point on a
shared ethernet hub, which isn't quite the same thing.

Since the functionality differs between CSCF types, and differs further
within a type based on design, configuration, and the hosting processor,
using 50ms is, at best, a horrible oversimplification. However, I
believe the number to be of the right order of magnitude for use in
assessing the performance differences between UDP and TCP. I would
certainly suggest more precise estimation if one were trying to do
real-world capacity planning.

--
Dean
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip