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

From: "Eric Burger" <[email-masked]>
Date: Thu, 30 Jan 2003 10:44:40 -0500

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".

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, January 16, 2003 11:26 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Extension to Assure Congestion Safety
> 
> 
> On Thu, 2003-01-16 at 06:36, [email-masked] wrote:
> > Hi
> > 
> > are there news about the Congestion problem ?
> > I read some weeks ago that work is frozen. 
> > But your draft expires at the end of January. 
> > Will be some change in new release? If it will be resubmitted.
> > 
> > About the change with TCP as Transport Protocol default,
> > someone can tell me some news?
> > 
> 
> Thanks, Sal. Actually, we haven't talked much about this 
> lately, and we
> probably should.
> 
> When conversation last stopped, we had just realized that although we
> could use this sort of mechanism in the forward direction, it 
> doesn't do
> anything about the reverse direction.
> 
> So, let's say somebody S/MIME signs a 200 OK, making it perhaps 4KB in
> size (That doesn't necessarily happen, but it MIGHT if they include
> their cert). Since this is a response, it MUST follow the 
> path laid out
> in the Via header field, even if this takes it across non-congestion
> safe UDP links.
> 
> Is this a problem that we should worry about?
> 
> If so, can we address it short of jut deprecating UDP? 
> 
> One approach that came up is essentially tagging the Via 
> values so that
> we know which are congestion safe. Under this approach, the 
> receiving UA
> would be able to recognize that the large response it is generating
> could not be returned safely. What should it do then? Could such a
> mechanism be made backward compatible?
> 
> How much additional triggerwork are we willing to put into 
> the protocol
> just to continue accommodating UDP? I know a number of people believe
> that a lot of the complexity of SIP stems from its concurrent support
> for UDP and TCP, and that we'd be better off just ripping the UDP out
> and consequently greatly simplifying the state machines than 
> adding more
> complexity to the core protocol.
> 
> So, we don't really have a group consensus about where to go 
> with this,
> and we need one. 
> 
> Ladies, gentleman, and those to whom these terms are irrelevant, the
> floor is open for discussion.
> 
> --
> 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
> 
_______________________________________________
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: Thu, 30 Jan 2003 12:50:19 -0600

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

---

From: "KumarS" <[email-masked]>
Date: Thu, 30 Jan 2003 22:03:47 -0800

Hi All,

I am looking for Re-Invite supported SIP implementation.
May I get any pointer to Re-Invite (rfc 3261) implemented downloadable
SIP code.

Thanks in advance
Suman
-- 
  KumarS
  [email-masked]

-- 
http://fastmail.fm - A no graphics, no pop-ups email service