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, 22 May 2008 16:17 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 982283A6AAA; Thu, 22 May 2008 09:17:14 -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 F27073A68B2; Thu, 22 May 2008 09:16:52 -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 4aLiqSafP1yh; Thu, 22 May 2008 09:16:52 -0700 (PDT)
Received: from mailer1.psc.edu (mailer1.psc.edu [IPv6:2001:5e8:1:3a::64]) by core3.amsl.com (Postfix) with ESMTP id 0F6473A6835; Thu, 22 May 2008 09:16:51 -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 m4MGGfg5001658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2008 12:16:41 -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 m4MGGf90003060; Thu, 22 May 2008 12:16:41 -0400
Date: Thu, 22 May 2008 12:16:41 -0400 (EDT)
From: Matt Mathis <mathis@psc.edu>
To: Jonathan Rosenberg <jdrosen@cisco.com>
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: <4834CFEC.7090404@cisco.com>
Message-ID: <Pine.LNX.4.64.0805221129130.5023@tesla.psc.edu>
References: <20080429233307.8FE333A6967@core3.amsl.com> <Pine.LNX.4.64.0805081741180.5023@tesla.psc.edu> <4834CFEC.7090404@cisco.com>
MIME-Version: 1.0
Cc: sipping@ietf.org, ietf@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-Archive: <http://www.ietf.org/pipermail/ietf>
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

Your rewording looks good.  One minor suggestion for REQ 15:

<t hangText="REQ 15:"> In cases where a network element fails, is so 
overloaded that it cannot process messages, or cannot communicate due to a 
network failure or network partition, it will not be able to provide explicit 
indications of the nature of the failure or its levels of congestion. The 
mechanism must properly function in these cases. </t>

>> 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. 
>
> True, and we absolutely need to utilize that. However, I do not believe this 
> eliminates the utility of explicit congestion indicators, as ECN provides 
> (for example), as a way to further improve performance.

Normally ECN only reduces latency.  My usual metric for performance is 
throughput, which is not generally improved by ECN.  But point taken.   And it
doesn't effect the document.


Thanks,
--MM--
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf