Subject: RE: [Sip] PING/PONG

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 9 Nov 2004 12:36:32 +0100

Hi,
 
I don't have anything PING, but no matter how short and effective (in the number of SIP headers etc) we make it it is still pretty "heavy" on the network.
 
I think we should, as I said yesterday, at least have a look at an option which "combines" CRLF and PING (or whatever method is used), ie a UA can send CRLF every X seconds, and PING every n*X seconds.
 
Of course, using a combined mechanism would mean that it would take longer to detect a NAT failure, in case the NAT binding goes done while the UA sends CRLF. 
 
But, we also have to remember, that eventhough PING would have a response (which CRLC does not have), due to the transcation timeout- and re-transmission timers it would still take a while (until the transcation expires) to figure out that the NAT binding has been closed.
 
Regards,
 
Christer Holmberg
Ericsson Finland

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christian Stredicke
Sent: 8. marraskuuta 2004 23:31
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] PING/PONG

Hello Cullen,
 
I think it is no harm if there is a PING message defined in SIP. I personally think it is overdue anyway. Implementors can then decide if they are using it or not. Lets leave that decision to the implementors!
 
But we have to consider who is sending keep-alive traffic. "IMHO" is it definitely better if the UA does this, because then e.g. usually it is ok to send CRLF keep alive or STUN.
 
We register with a header that incates (a) that the UA is able to do the refreshing and (b) what the proposed refresh time is. The UA can do all these tricky NAT measurement tricks and then propose the refresh time. Stupid UA may just propose a predefined value, e.g. 20 seconds. The registrar (or whatever is in the path) then can acknowlege the refresh role and leave the refreshing to the UA. Otherwise, it will send the refresh messages. In that case, it will probably use PING, cause it needs a response to keep the NAT alive in all cases - even if it is a "503 Not Implemented".
 
Christian

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Tue, 9 Nov 2004 07:33:23 -0500

----- Original Message ----- 
From: "Christer Holmberg (JO/LMF)"
> But, we also have to remember, that eventhough PING would
> have a response (which CRLC does not have), due to the
> transcation timeout- and re-transmission timers it would
> still take a while (until the transcation expires) to
> figure out that the NAT binding has been closed.
>

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.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 10 Nov 2004 16:24:42 -0500

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,

> 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