IETF Logo Mail Archive

Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

Ben Campbell <ben@nostrum.com> Fri, 14 February 2014 22:06 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9291A016A for <dime@ietfa.amsl.com>; Fri, 14 Feb 2014 14:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYeGqeQTs8iE for <dime@ietfa.amsl.com>; Fri, 14 Feb 2014 14:06:52 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C26931A01CD for <dime@ietf.org>; Fri, 14 Feb 2014 14:06:46 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1EM6gq9054101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:06:44 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
Date: Fri, 14 Feb 2014 16:06:42 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4AC97CE-10C3-401A-83CB-B60FD2B395D6@nostrum.com>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <41DC79BF-FFD9-4C17-B61D-8BDFE7D446A8@gmail.com> <18673_1392030932_52F8B4D4_18673_1082_2_6B7134B31289DC4FAF731D844122B36E4970F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0D5BD3F3-8797-4479-BC3D-61671D8D8AFF@gmail.com> <24932_1392032199_52F8B9C7_24932_4247_1_6B7134B31289DC4FAF731D844122B36E49718B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8EB36.9050501@usdonovans.com> <902CE93A-75C4-4A3F-AD76-DF9C03064BE1@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2DA9@DEMUMBX014.nsn-intra.net> <D4982697-ECA2-4118-8AFE-835A0B04EE46@nostrum.com> <087A34937E64E74E848732CFF8354B9209773173@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B2E9B@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097741D5@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B3009@DEMUMBX014.nsn-intra.net> <52FCC20F.5000900@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3556@DEMUMBX014.nsn-intra.net> <1! 0158_1392389206_52FE2C56_10158_1176_1_6B7134B31289DC4FAF731D844122B36E4A3A41@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B35D0@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NMCt0zwp95BOs3pqSkuMKy1ZczI
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 22:06:54 -0000

On Feb 14, 2014, at 8:59 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> I think that two points are mixed:
> 
> 1) For efficiency, a DOIC-enabled client should be able to mitigate (possible) overload situation even if explicit indication is not received from the network.
> 2) DOIC-enabled clients having a different behavior regarding support or not of DOIC by server.
> 
> if I agree with the first one, I disagree with the second one. The basic assumption is that a DOIC client will not throttle the traffic in absence of overload indication (explicit or implicit). And throttling will be performed as soon as an indication is received (explicit or implicit) if the client is designed for that (it supports DOIC or/and default behavior has been defined on reception of TOO_BUSY or non-response).
> 
> It is the only thing that matters today.

I disagree, for  reasons stated earlier. In summary, the requirement that reacting nodes be able to take different action depending on whether an opposite endpoint supports DOIC is a direct implication of requirements 16 and 18 of RFC 7068.

v2.23.0 | Report a Bug | By Email