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

From: [email-masked]
Date: Thu, 06 Feb 2003 11:06:57 +0100

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

> > 
> > Dean, where are you found datas and information on 3G network delay?
> > 
> 
> Primarily from presentations to the 3GPP-IETF joint meeting last week in San
> Francisco, plus my own experience with a couple of CDMA 2000 1XRTT networks,
> as well was with GRPS over GSM TDMA  (which, despite some marketing
> programs, isn't really 3G). 
> 
> Don't get me wrong -- there are plenty of potential sources of delay here.
> But properly used TCP really isn't a major contributor.
> 
> There's a large body of work out there. I suggest starting with RFC 2757
> 
> ftp://ftp.rfc-editor.org/in-notes/rfc2757.txt
> 
> 
> And I'd like to point out ongoing work (just a tiny subset of what's going
> on).
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-12.txt
> 
> http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-tcp-frto-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-amit-quick-start-02.txt
> 
> http://www.ietf.org/internet-drafts/draft-ludwig-tsvwg-tcp-fast-timeouts-00.
> txt
> 
> http://www.ietf.org/internet-drafts/draft-gurtov-tsvwg-tcp-delay-spikes-01.t
> xt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-03.txt
> 
> The basic point is that there is a tremendous amount of effort going into
> understanding and improving TCP's behaviour over wireless networks, and
> trying to re-invent all of that here for SIP/UDP is sheer folly. Sure, UDP
> is potentially useful, especially for lightweight mobile-to-first-hop-server
> links, but probably just dangerous and pointless for server-server links. I
> propose that we DO NOT need to "fix" this in SIP -- we just need to limit
> the usage so that UDP is only used in the non-dangerous cases. This
> shouldn't be all that hard to do.
> 
> --
> Dean
> 
> _______________________________________________
> Sip mailing list  https://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
> 

 Per registrarti gratuitamente a Vodafone Mail vai su www.190.it 

_______________________________________________
Sip mailing list  https://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: Dean Willis <[email-masked]>
Date: 11 Feb 2003 18:23:01 -0600

> "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 th…

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.