Subject: [Sip] 3-way handshake bad!

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 17 Nov 2003 15:01:13 -0000

All,

For context, see IETF 58 minutes.  There was a suggestion that the
non-INVITE avalanche problem be solved by using a 3-way handshake.  I just
want to flag that this idea can have unfortunate consequences during
congestion.

Firstly, consider a server under load.  The 3-way handshake requires the
following.

server processes request - #1
server sends response - #2
server processes request/handshake - #3.

By adding the 3rd step, we have _doubled_ the number of requests to be
handled by the server increasing the load and increasing the chances it
becomes congested.

As per my earlier e-mail, for TCP, the chances of the initial request
completing can be either 1.0 or 0.0 depending on the congestion.  Increasing
the congestion at the server, increases the chance of requests failing.
For UDP, there is a 1/x (x >= 1) chance of the request being received and
processed by the server.  Similarly, there is a 1/x chance of the 3rd
request/handshake reaching the server.  This means the chances of the 3-way
handshake completing are
1/(x^2).  So adding the third step greatly affects the chances of the 3-way
handshake completing.

Paul D.Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

_______________________________________________
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: "David R. Oran" <[email-masked]>
Date: Mon, 17 Nov 2003 10:18:36 -0500

> want to flag that this idea can have unfortunate consequences during
I made that suggestion. I disagree that it has unfortunate congestion 
consequences. See below. Note however, that it may be unproductive to start 
an extended dialog on this subject since such a change to SIP may be too 
radical at this stage in the protocol's evolution. We need to weigh this 
against the efficacy-versus-radicality tradeoffs of other possible ways to 
ameliorate the problems.

> handled by the server increasing the load and increasing the chances it
Not really. The processing of an ACK transaction is not nearly as expensive 
as processing of the actual request. All it requires is transaction 
matching and state cleanup (if any). This had better be blindingly fast in 
any reasonable SIP server or you have a lot of worse things to worry about, 
including DoS attacks from legitimate authenticated/authorized sources.

(Aside: I actually have a patent disclosure filed on how to do DoS 
prevention by SIP servers where the relative costs of transaction matching, 
authentication, authorization, and state-creation are taken into account).

> completing can be either 1.0 or 0.0 depending on the congestion.
For a single signaling hop this is more-or-less true, but assumes a number 
of things, including whether the server is programmed to back-pressure the 
TCP connection (causing HOL blocking) or is maintaining internal request 
queues from which requests might get dropped on overflow. For multi-hop 
signaling, TCP is of little help especially when multiplexing is happening.

> Increasing the congestion at the server, increases the chance of requests
> failing. For UDP, there is a 1/x (x >= 1) chance of the request being
> received and processed by the server.  Similarly, there is a 1/x chance
> of the 3rd request/handshake reaching the server.
This is true only if all requests have equal costs, and if ACKs have equal 
costs to requests. This is demonstrably not the case.

> This means the chances
> of the 3-way handshake completing are
> 1/(x^2).  So adding the third step greatly affects the chances of the
> 3-way handshake completing.
>
I believe this logic is flawed.

Cheers, Dave.

> Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]