Re: [Sip] PING/PONG
Klaus Darilion <klaus.mailinglists@pernau.at> Mon, 15 November 2004 21:35 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12731 for <sip-web-archive@ietf.org>; Mon, 15 Nov 2004 16:35:06 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CToXD-0002dc-Ci for sip-web-archive@ietf.org; Mon, 15 Nov 2004 16:37:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CToKb-0003HN-Gs; Mon, 15 Nov 2004 16:24:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTnlU-0002IQ-Fq for sip@megatron.ietf.org; Mon, 15 Nov 2004 15:47:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01212 for <sip@ietf.org>; Mon, 15 Nov 2004 15:47:52 -0500 (EST)
Received: from viefep15-int.chello.at ([213.46.255.19]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnnL-0007fh-Ro for sip@ietf.org; Mon, 15 Nov 2004 15:50:02 -0500
Received: from [192.168.2.21] (really [62.178.216.203]) by viefep15-int.chello.at (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041115204658.YUJU4582.viefep15-int.chello.at@[192.168.2.21]>; Mon, 15 Nov 2004 21:46:58 +0100
Message-ID: <419915BE.2060703@pernau.at>
Date: Mon, 15 Nov 2004 21:46:54 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Stredicke <Christian.Stredicke@snom.de>
Subject: Re: [Sip] PING/PONG
References: <B52FDDEC7CBE9D40B36FE900C9AD78B4176AB8@merenge.intern.snom.de>
In-Reply-To: <B52FDDEC7CBE9D40B36FE900C9AD78B4176AB8@merenge.intern.snom.de>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
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>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: 7bit
You should also consider the guidelines in the draft http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-00.txt which will hopefully soon implemented in NAT routers. regards, klaus Christian Stredicke wrote: > Hi Spencer! > > You just mentioned another way of keeping TCP connections alive. Thats > good! > > So far we have: > > - CRLF (frequenly used today, but not indicated by user agent) > - STUN (same as CRLF) > - PING/PONG or whatever (tbd, maybe superflous) > - OPTIONS (big overhead, but compatible) > - REGISTER (same as OPTIONS, but even bigger overhead) > - TCP low-level (how can this be addressed by the application?) > - No refreshing ("legacy device") > > Lets have a way to indicate these options and let the SBC decide what > method it likes/supports. > > CS > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Spencer Dawkins >>Sent: Wednesday, November 10, 2004 5:01 PM >>To: sip@ietf.org >>Subject: Re: [Sip] PING/PONG >> >>Call me old-fashioned, but I'm requesting a point of clarification >>about PING/PONG. >> >>As I should have said in the working group session when we discussed >>this, I have no interest in chatting about UDP versus TCP. If you >>choose UDP, I assume you did it for a reason, and the discussion at >>the working group session makes sense to me. >> >>Having said that, >> >> >>>With UDP, the PING will create a new NAT binding and the server can >>>update >>>its mapping for the UA. >>> >>>With TCP, if you want to be able to detect that the NAT binding is >>>gone on >>>the order of a transaction timeout, you would need to send a PING >>>every 32 >>>seconds or so. Given that NAT bindings for TCP live longer than >>>that, I >>>don't see what the CRLF buys you. >> >>it seems to me that if you have chosen to use TCP for some >>reason, you >>need to at least consider living with TCP behavior on retries. >> >>The TCP protocol is extremely persistent, uses exponential backoff >>(typically to a maximum of 60-64 seconds per retry), and in most >>vanilla implementations will not declare a connection unusable for >>something like 10-15 minutes. >> >>If a path is lost, for any reason, TCP will use this behavior (the >>behavior that allows the Internet to survive the World Wide Web >>today). >> >>If you are using TCP and you don't like this behavior, and you don't >>get a response back when you wanted to get a response back, the >>application choices are: >> >>- sit on your hands and wait for the TCP connection to fail, >> >>- close the TCP connection and open another one, or >> >>- close the TCP connection, sit on your hands for some period >>of time, >>and open another one. >> >>The second choice (immediate retry) requires that you reset the TCP >>connection (one packet), send a SYN to open a second TCP connection >>(one packet), and potentially ACK an incoming SYN/ACK (one packet), >>and then resend your application message (could be piggybacked but >>most TCP stacks will use a separate packet). >> >>Immediately sending up to four new packets when you detect >>loss of one >>packet, with the possibility that the single-packet loss is due to >>network congestion, seems too aggressive. >> >>Sitting on your hands and letting TCP retry doesn't seem much worse >>than sitting on your hands and then setting up a new TCP connection. >> >>Are we assuming that network congestion is not an issue any more? >> >>Thanks for any guidance you can provide! >> >>Spencer >> >> >> >>_______________________________________________ >>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 >> >> >> > > > _______________________________________________ > 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 > > _______________________________________________ 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
- [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Christer Holmberg (JO/LMF)
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Bob Penfield
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Chris Boulton
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Spencer Dawkins
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Klaus Darilion
- Re: [Sip] PING/PONG Jonathan Rosenberg
- [Sip] How to get old messages on archives!! vikram bhuskute
- RE: [Sip] PING/PONG Christian Stredicke
- Re: [Sip] PING/PONG Jonathan Rosenberg
- RE: [Sip] PING/PONG Steve Langstaff
- RE: [Sip] PING/PONG Christian Stredicke
- RE: [Sip] PING/PONG Steve Langstaff
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Charles Eckel
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks
- Re: [Sip] PING/PONG Jonathan Rosenberg
- Re: [Sip] PING/PONG Robert Sparks