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

loretosa@vodafone.it Thu, 06 February 2003 10:05 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10918 for <sip-archive@odin.ietf.org>; Thu, 6 Feb 2003 05:05:44 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16AC7x18566 for sip-archive@odin.ietf.org; Thu, 6 Feb 2003 05:12:07 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16ABhp18545; Thu, 6 Feb 2003 05:11:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AAdp18480 for <sip@optimus.ietf.org>; Thu, 6 Feb 2003 05:10:39 -0500
Received: from gsp05-c21d3.vodafone.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10818 for <sip@ietf.org>; Thu, 6 Feb 2003 05:03:44 -0500 (EST)
From: loretosa@vodafone.it
Received: from vodafone.it (127.0.0.1) by gsp05-c21d3.vodafone.it (NPlex 5.1.046) id 3E390D3F00000713; Thu, 6 Feb 2003 11:06:57 +0100
X-CNS-Auth: <username="loretosa", uid="8:18", UMCluster="2", DSUhost="DB">
Date: Thu, 06 Feb 2003 11:06:57 +0100
Message-Id: <h9vtfl$IfjJzgyTAs7xbCLxOHlRWajh2eNBqIyp@vodafone.it>
Subject: Ri: RE: [Sip] Extension to Assure Congestion Safety
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
To: dean.willis@softarmor.com
To: eburger@snowshore.com
Cc: sip@ietf.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16AAdp18481
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip