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

From: [email-masked]
Date: Tue, 04 Feb 2003 10:03:17 +0100

I agree wid Dean,

I think the use of TCP doesn't introduce any lose!!!

Furthermore I think also SCTP is a good chance, especially 
in the Instant Messaging transmission.

Dean, where are you found datas and information on 3G network delay?

Sal

> Eric chewed on:
> > I'll bite :-)
> > 
> > How long will it take to setup a call in a 
> > far-from-the-antenna 3G scenario using TCP?  That is, at 
> > 14.4kb/s, I'm looking at least 3RTT's just to say "INVITE".
> 
> Well, consider that you should be using a long-lived TCP session established
> back when you turned your phone on. Consequently, there's little further
> overhead for TCP -- just some ack fields in the TCP headers on the INVITE,
> 200OK, and ACK. There's probably a final null-ack TCP packet on the ACK
> message, but that's after call setup has completed.
> 
> Given this, the constraint is still the three-way handshake of SIP, which
> means you have at least 3 RTTs whether you use UDP or TCP. 
> 
> So, let's say each request, using compression, is 400 bytes (that's 3200
> bits). At 14.4, that makes a total serialization delay of 222 ms per each
> mobile link. Two mobile links give us 444ms. Add 150ms of core network
> delays (50ms each hop), and we're at 372ms. Not too shabby so far.
> 
> 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.
> 
> So much for the math. The problem is, current 3G systems have a lot more
> transmission latency than one would think based on the bandwidth. Assuming
> there's an active connection, it still tends to be a couple of hundred ms
> before a mobile can actually send anything. Consequently, real world
> performance with today's system adds another 2 seconds or so to the call
> setup. We're working on that from the network side. On the other hand,
> that's still not any worse than the 10-15 second call setup dealys I always
> have on my TDMA phone . . .
> 
> Now, lets think about the specific impact of TCP vs UDP here. The BIG delays
> in SIP setup happen if a request or response gets lost and we use the SIP
> backoff timers to resend. TCP, giving us a smoother-running network, is less
> likely to give us a network in which packets get lost. Furthermore, its
> recovery timers (especially in the wireless-tuned TCP) are likely to give
> smoother, quicker recovery than does SIP in the event of a loss-burst. So,
> all in all, I don't think we lose anything by using TCP to the mobile, and
> we potentially gain quite a bit. Server-to-server operations have to think
> about head-of-line blocking issues, and that's wehre SCTP comes in as a
> better alternative.
> 
> --
> 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: Wed, 5 Feb 2003 19:26:05 -0600

> 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