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

["Spencer Dawkins" <[e-mail]>]

Hi, Christian (J),

Ah, your note was very helpful. thank you for continuing to follow up 
when we weren't together yet. I've been responding to a vague uneasy 
feeling, and this note helped me understand my own concerns.

The behavior of applications potentially attempting to set up TCP 
connections very aggressively is what concerns me. Think, "close the 
connection, wait some minimal period of time before trying to reopen 
it, what's the minimum period of time, and is there a backoff at the 
application level?"

I would be concerned about large numbers of clients reopening TCP 
connections through a NAT (for instance) trying to restart.

I agree with the rest of what we're talking about here.

Spencer

----- Original Message ----- 
From: "Christian Jansson" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>; "Christian Stredicke" 
<[e-mail]>
Cc: <[e-mail]>
Sent: Friday, November 12, 2004 4:00 AM
Subject: RE: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]



>From: Spencer Dawkins [mailto:[e-mail]]
>
>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.


When sending the CRLF over TCP you should not get anything back if the
connection is still there. If the TCP connection is down or fails 
while
sending the CRLF on the other hand you will get a notice from your IP
stack of the failure. Then that socket should be closed, and the UA 
may
try to set up a new connection if wants to.


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


I'm not sure how often keep-alives have to be sent over TCP to ensure
that NAT/FWs do not remove the state. Preferabely NAT/FWs never remove
the state, but I have heard that it happens. Does anyone have a
reference to test statistics of NAT/FWs behavior? The keep-alive 
default
interval should probably be set just below the shortest of all 
detected
values. My guess is that the value will be around 5 minutes. Sending a
TCP packet with CRLF every 5 minutes can't really be a big source for
congestion. The keep-alives would also not be sent if any other 
traffic
had been sent to or from the UA.

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

Given that the keep-alives are spaced with a couple of minutes, and 
that
this interval is much greater than the TCP error timeouts, I do not 
see
the problem. If those keep-alives would have been sent every 10 
seconds
I would have agreed on the problems you describe.

/ Christian Jansson




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip