Re: Last Call: draft-ietf-sipping-overload-reqs (Requirements for Management of Overload in the Session Initiation Protocol) to Informational RFC

Matt Mathis <mathis@psc.edu> Thu, 08 May 2008 21:44 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEF23A6B9E; Thu, 8 May 2008 14:44:52 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3E43A68BA; Thu, 8 May 2008 14:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYCEJT1bYhm2; Thu, 8 May 2008 14:44:48 -0700 (PDT)
Received: from mailer1.psc.edu (mailer1.psc.edu [IPv6:2001:5e8:1:3a::64]) by core3.amsl.com (Postfix) with ESMTP id 6D4A13A6B9E; Thu, 8 May 2008 14:44:48 -0700 (PDT)
Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.14.2/8.13.3) with ESMTP id m48Lijvt012628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 May 2008 17:44:45 -0400 (EDT)
Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id m48LiiMR007916; Thu, 8 May 2008 17:44:45 -0400
Date: Thu, 8 May 2008 17:44:44 -0400 (EDT)
From: Matt Mathis <mathis@psc.edu>
To: ietf@ietf.org
Subject: Re: Last Call: draft-ietf-sipping-overload-reqs (Requirements for Management of Overload in the Session Initiation Protocol) to Informational RFC
In-Reply-To: <20080429233307.8FE333A6967@core3.amsl.com>
Message-ID: <Pine.LNX.4.64.0805081741180.5023@tesla.psc.edu>
References: <20080429233307.8FE333A6967@core3.amsl.com>
MIME-Version: 1.0
Cc: sipping@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I reviewed draft-ietf-sipping-overload-reqs-02 at the request of the transport 
area directors.  Note that my area of expertise is TCP, congestion control and 
bulk data transport.  I am not a SIP expert, and have not been following the 
SIP documents.

I have serious concerns about this document because it explicitly excludes the 
only approach for coping with overload that is guaranteed to be robust under 
all conditions.  Although I know it is considered bad form to describe 
solutions while debating requirements, I think a sketch of a solution will 
greatly clarify the discussion of the requirements.

The only robust overload signal is the natural implicit signal - silently 
discarding excess requests.  Explicit overload messages (code 503) should be 
optional, and must have an explicit rate limit.  The error message may be 
cached (e.g. in proxies, etc) but must not be required to be cached.  All 
retransmissions in all parts of the protocol must back off exponentially 
(which I am told is already true for SIP).

Sending additional messages to explicitly indicate overload is intrinsically 
fragile.  If the overload management mechanism consumes any shared resource 
that might be needed to complete other calls, then there exists some operating 
point where any additional requests will cause a decline in the number of 
successfully completed calls.  This is likely to be regenerative, with each 
successive error using more resources and preventing more calls, until the 
throughput crashes to zero.  This phenomena was readily apparent in all of the 
plots shown in the tsvwg meeting at IETF 71.

Note that if the explicit overload management mechanism is very complicated, 
the situation that triggers this failure might also be very complicated. 
Asserting that this hazard does not exist is probably equivalent to proving 
that explicit overload notifications never cause additional calls to fail, for 
all combinations of implementations under all operating conditions.  It would 
not be an easy task to prove that the standards are sufficient to guarantee 
this for all possible implementations.

My specific objections to the document are as follows: Requirement 6 calls for 
explicit overload messages and forbids silently discarding requests, since 
they are not unambiguous in their meaning.  Requirement 15 seems to provide a 
loophole (allowing complete failures) but seems to forbid using it as the 
preferred mechanism.  Requirement 8 does not make sense without explicit 
notification.  Requirements 7, 8 and 9 should note that they can be (are 
already?)  equivalently satisfied by properly structured exponential 
retransmission backoff timers in SIP itself.

I would like to point out that TCP, IP and several other transport protocols 
have evolved in the same direction as I am advocating for SIP: the only robust 
indication that an error has occurred is connection failure.  Error messages 
are cached and sometimes accelerate timers (e.g. retransmit now, or go to the 
next IP address now), but do not change basic protocol behavior.  Error 
messages are most often rate limited at the sender and the saved error codes 
are used to provide a clue why something failed, but the fact that it failed 
most likely comes from a timer, not the message itself.  The number of error 
massages that are required for correct operation is declining (note that 4821 
makes ICMP can't fragment optional), and may be zero.

Rate limiting all errors messages and treating them as advisory improves 
robustness in several ways: fraudulent messages have less impact, error 
messages can not be used an DDOS attack magnifiers, and overload is addressed 
implicitly by silently discarding requests.

Note that the normal, non-crisis, behavior has not changed significantly: 
error message are sent, cached and reported to the application.  However, in a 
crisis, the error reporting degrades gracefully, while the throughput goes 
flat, without any negative slope.  This is where SIP (and all other protocols) 
should strive to be.

Treating all errors as soft should have been an Internet Architectural 
Principle.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf