Re: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]

"Spencer Dawkins" <spencer@mcsr-labs.org> Thu, 11 November 2004 19:05 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 OAA12772 for <sip-web-archive@ietf.org>; Thu, 11 Nov 2004 14:05:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKHO-0001Xu-70 for sip-web-archive@ietf.org; Thu, 11 Nov 2004 14:06:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK99-00030U-AY; Thu, 11 Nov 2004 13:58:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSK5j-0002J2-75 for sip@megatron.ietf.org; Thu, 11 Nov 2004 13:54:43 -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 NAA11927 for <sip@ietf.org>; Thu, 11 Nov 2004 13:54:42 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSK6m-0001Iu-QO for sip@ietf.org; Thu, 11 Nov 2004 13:55:59 -0500
Received: from dfnjgl21 (unknown[130.129.135.144]) by comcast.net (rwcrmhc12) with SMTP id <2004111118535301400nkpgce> (Authid: sdawkins@comcast.net); Thu, 11 Nov 2004 18:53:54 +0000
Message-ID: <07ba01c4c81f$e92872a0$90878182@DFNJGL21>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: Christian Jansson <christian.jansson@hotsip.com>, Christian Stredicke <Christian.Stredicke@snom.de>
References: <B7192C0D8D60754DADA9E22294C57369631661@mailserver.hotsip.com>
Subject: Re: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]
Date: Thu, 11 Nov 2004 13:54:43 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spencer Dawkins <spencer@mcsr-labs.org>
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.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit

OK, I'm still confused here. Please help me.

The apparent choices include "Keep-alives for TCP should be CRLF 
(default-interval TBD)".

Sending keep-alives over TCP may be interesting, but I'm really 
confused about what you think is a reasonable action when you send a 
PING over TCP and don't get a PONG back.

If you change a status indicator on a user display that says "may have 
lost connectivity", that's fine. If you try to retransmit requests, 
I'm concerned.

My definition of "reasonable" includes "don't send multiple new 
packets into a network path that is not returning PONGs, when the 
problem may be that the network path is losing packets because it is 
already congested." Retransmitting requests requires exactly this 
(tear down existing TCP connection, because it's still retransmitting, 
open a new TCP connection, and then retransmit the request at the 
application level).

There is no way for the endpoints to know that loss is NOT due to 
congestion, and putting TCP-based "lost packet multipliers" in place 
in end systems that can't know they aren't facing congestion is not 
something I'm comfortable with.

If TCP isn't the right answer, using TCP and sending multiple new TCP 
packets when a connection won't PING/PONG isn't helpful.

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