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

From: "Christian Jansson" <[email-masked]>
Date: Thu, 11 Nov 2004 17:40:23 +0100

Let's step back and look at the requirements. 

We have a problem that UAs are placed behind NATs and FWs. Those NATs
and FWs give us two big problems:
Problem1. Machines from the outside cannot easily connect/communicate
with the UAs on the inside, at least not without initiative from the UAs
on the inside.
Problem2. Even though the UAs on the inside open up for communication
through the NAT/FW, the NAT/FW doesn't keep the state for as long as we
would wish.

This gives us two requirements:
Req1. Open up for two way communication through the NAT/FW
Req2. Ensure req1 for as long as it is needed for the UA on the inside.

There are also some facts:
Fact1. In almost all normal situations it will only be the UA that can
open up the NAT/FW for two way communication.
Fact2. It is the UA that knows for how long the two way communication
through the NAT/FW is needed.
Fact3. It is generally good to put less work on servers and let the UAs
do as much of the work as possible. 

>From fact1 I draw the conclusion that the UA must open up the two way
communication because it will be the only reliable solution.
Fact2 and fact3 together with the conclusion that the UA must fulfill
fact1 gives me a strong feeling that the UA should be the only one that
should do the job of fulfilling the requirements.

I understand that there could be other solutions where machines on the
outer side of the NAT/FW could partly fulfill req2, that is, they could
try to keep the communication path open. But such a machine cannot be
sure exactly when to stop, and, this is the big one, it can't do
anything if it detects that the communication path fails ... nothing! If
the UA on the other hand fulfilled req2 and detected a problem, it could
open up a new communication path and everything would start working
again.

I do not think we should fool UA implementers into thinking that they
can solve the NAT/FW problem by negotiating with another device on the
outside of the NAT/FW. I think it is better to write down how to open,
use, and maintain a two way SIP signaling path through NATs and FWs.

My suggested solution:
Follow what's in draft-jennings-sipping-outbound-00:
- Keep-alives should be sent by the UA.
- Keep-alives for TCP should be CRLF (default-interval TBD). 
- Keep-alives for UDP could be the SIP methods REGISTER, or a new
light-weight SIP PING method, to be able to get the rport and received
from the response, or STUN. Frequent REGISTERs seems to heavy-weight for
the servers. That leaves us with PING or STUN. PING advantage, it is
SIP, disadvantage, it is new. STUN advantage, have been around for a
while, disadvantage, it is not SIP.

/ Christian Jansson

_______________________________________________
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: "Spencer Dawkins" <[email-masked]>
Date: Thu, 11 Nov 2004 13:54:43 -0500

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