Subject: RE: [Sip] 3-way handshake bad!

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 21 Nov 2003 14:04:29 -0000

Neither of these are ISUP examples, they are DSS1. 

Morever, for setup in both protocols (ISUP and DSS1), the three message sequence is not a handshake (A --> B, B --> A, A --> B) and is not necessrily end to end, in most countries the ACM or CALL PROCEEDING is more likely returned link by link.

For teardown, the handshake is always link by link, and in DSS1, it is not a handshake. It only has functionality in one direction (although is specified in both directions to keep it symmetrical), and it is there because of the point - multipoint interface that is allowed in DSS1.

regards

Keith

> -----Original Message-----
> From: Pugaczewski, Jack [mailto:[email-masked]]
> Sent: 17 November 2003 15:16
> To: Paul D.Smith; [email-masked]
> Subject: RE: [Sip] 3-way handshake bad!
> 
> 
> Question:
> 
> Why is a 3-way handshake bad ?  ISUP has used it successully for call
> setup and call teardown:
> 
> Call Setup:    Setup -->; Call Proceeding <--; Connect <---
> Call Teardown: Disconnect -->; Release <--; Release Complete -->
> 
> 
> 

_______________________________________________
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: "Paul D.Smith" <[email-masked]>
Date: Mon, 24 Nov 2003 16:51:20 -0000

Jack,

As you say, a 3-way handshake per-se is not bad.  In the SIP case though, I
believe it can have poor characteristics during network/server congestion.
Since it seemed that it had been proposed as a possible solution to certain
SIP problems and possibly become the new "handshake of choice", I wanted to
alert readers to the downsides.

The title was a little "shocking", but was very much intended to be read
within the SIP context of the mailing list.

Regards,
Paul DS.

-----Original Message-----
From: Pugaczewski, Jack [mailto:[email-masked]]
Sent: 21 November 2003 08:20
To: SIP (E-mail)
Subject: RE: [Sip] 3-way handshake bad!

Question:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
D.Smith
Sent: Monday, November 17, 2003 9:01 AM
To: [email-masked]'
Subject: [Sip] 3-way handshake bad!

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: "Paul D.Smith" <[email-masked]>
Date: Mon, 24 Nov 2003 16:51:51 -0000

David,

I take your point about not wishing to start a long thread on something that
may not happen.  I just want to clarify a couple of my assertions below as I
think you may have misunderstood my reasoning.

Thanks,
Paul DS.

Paul D.Smith
Network Protocols Group 

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: 17 November 2003 15:19
To: SIP (E-mail)
Subject: Re: [Sip] 3-way handshake bad!

--On Monday, November 17, 2003 3:01 PM +0000 "Paul D.Smith" 
<[email-masked]> wrote:

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

[PDS] Agreed.

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

[PDS] My contention is not that ACK processing is as slow as INVITE.  It is
that no request, ACK or otherwise, can be processed by the SIP stack until
it has been accepted by the IP layer.  During congestion, and when using
UDP, it is the rate at which ALL requests/responses can be processed by the
SIP/IP stacks that determines the chance of an ACK (or any other SIP request
or response) being accepted and processed.  I therefore contend that the
time taken by the SIP stack to process the ACK, which having an overall
affect on the chances of any SIP request being accepted, has no bearing on
the chances of the ACK even being accepted.

[PDS] The only possible exception to this might be if an ACK were
sufficiently smaller than any other request/response such that it might be
able to be accepted when there were insufficient resources for larger
datagrams to be received.  I suspect that in most stacks, the relative sizes
of the datagrams has little bearing.

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