RE: [Sip] PING/PONG

["Christian Stredicke" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Spencer Dawkins
> Sent: Wednesday, November 10, 2004 5:01 PM
> To: [e-mail]
> 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip