Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING request processing?

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 6 Mar 2006 20:28:14 -0600

Inline.
Thx
Samir

I'm not aware of much distinction among the proposals.

The SIP 503 response works ok.  And after
draft-rosenberg-sipping-overload-reqs is resolved; hopefully the 503
response (or alternate solution) will work better.

The "double CRLF" and STUN mechanisms would likely cause less overload.
And if an overload causes the connection/binding to be suspect, the
subsequent SIP request could trigger a 503 when needed.

SS>> We need to wait for Next Register Refresh, INVITE or other SIP
request. And then do 503 for
     it. Will it not be too late to stop CRLF ? Or will there be new SIP
Event to tell client not 
to do STUN CRLF for specified time period. We are mixing so much STUN
with SIP. IMHO, load is caused by CRLF and it should be stopped there
with the response. STUN doesn't have mechanism for Retry-After as per
3489, so SIP PING with 503 is better in this case. Or add this logic in
STUN-bis ?

And depending upon how the mechanism is tied to the rest of the SIP
messaging over the connection, potentially nothing extra really needs to
be sent over the connection/binding as long as something is being sent
and received frequent enough.

_______________________________________________
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

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Tue, 7 Mar 2006 11:57:11 -0500

> draft-rosenberg-sipping-overload-reqs is resolved; hopefully 
> the 503 response (or alternate solution) will work better.
> 
> The "double CRLF" and STUN mechanisms would likely cause less 
> overload. And if an overload causes the connection/binding to 
> be suspect, the subsequent SIP request could trigger a 503 
> when needed.
> 
> SS>> We need to wait for Next Register Refresh, INVITE or 
> other SIPrequest. And then do 503 for it. Will it not be 
> too late to stop CRLF ? 

It depends upon how the "double CRLF" mechanism is defined.  I assume the
number of tries before the connection/binding is suspect would be similar to
using a SIP message mechanism (over connection oriented transport).  And
depending upon what needs to occur when the connection/binding is suspect,
all solutions might require a subsequent REGISTER (and hopefully none or
limited "retargeting" required when dialogs exist).

The evaluation would likely have to consider things like the following:

1) What are the ramifications of returning a 503?
(draft-rosenberg-sipping-overload-reqs presents some of the current
problems/limitations with sending a 503.)

2) What is the typical retry-after value returned when in overload
(especially when returning a 503)?

3) What is the likely device overloaded and why?  What is the trade off cost
of receiving, decoding, and replying with a SIP 503 versus receiving,
decoding, and replying using the "double CRLF" mechanism?

4) How many "double CRLF" and/or SIP request are sent before deeming the
connection/binding suspect?  And for the SIP messaging, is packet
fragmentation likely within the connection?

> IMHO, load is caused by CRLF and it should be stopped 
> there with the response.

See above.

> STUN doesn't have mechanism for Retry-After as per 3489, 
> so SIP PING with 503 is better in this case. Or add this 
> logic in STUN-bis ?

The SIP request solution has both the benefit and curse of sharing the SIP
overload solutions (503 with retry-after and solution of
draft-rosenberg-sipping-overload-reqs).  And it has the benefit of
potentially using a 500 with retry-after for usage when the mechanisms
interval can potentially be extended a little without it impacting other
dialogs and requests.

I still have no strong opinion concerning what to use over UDP.  STUN and
the sip request solutions both have their advantages and disadvantages.  And
STUN is potentially a little better if most worried about the capacity of
the devices/pipes between the 2 SIP devices.

For connection oriented transports, the "double CRLF" appears to be the most
efficient if it reasonably satisfies the requirements.

And it would be nice to document and/or define some recommended solutions
for use when the "double CRLF" and STUN mechanisms (if chosen) are not
supported by one or both of the devices.