IETF Logo Mail Archive

[Dime] clearing of the Destination-Host AVP in the retransmitted request

"Poscic, Kristian (Nokia - US/Mountain View)" <kristian.poscic@nokia.com> Sat, 30 March 2019 12:55 UTC

Return-Path: <kristian.poscic@nokia.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201441201A4 for <dime@ietfa.amsl.com>; Sat, 30 Mar 2019 05:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 VxSD9CyPMwbF for <dime@ietfa.amsl.com>; Sat, 30 Mar 2019 05:55:11 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150104.outbound.protection.outlook.com [40.107.15.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115131201A3 for <dime@ietf.org>; Sat, 30 Mar 2019 05:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pq+lCs7bYR6JYiQuiU4AtdLhpaGa+U2nD5D2VKe1dK4=; b=QVFQ0d39YiBBVU1GqIHHfstXXywhTDSk6Oau5pDvMBgFJR2gguqnxAJhWavohckOltnKeIW+zNkd2VGYge6tqrbrMgKgX4Ps4OAzNNdupsldhsCh2bE0uw/3VCnbXI4Bd8BTqBqdJ3mt7GZQu7g0A7AODwvpglPH00Dv8zKtHak=
Received: from AM0PR07MB5490.eurprd07.prod.outlook.com (20.178.23.91) by AM0PR07MB4787.eurprd07.prod.outlook.com (52.135.152.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Sat, 30 Mar 2019 12:55:01 +0000
Received: from AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::51ef:1853:48c0:17de]) by AM0PR07MB5490.eurprd07.prod.outlook.com ([fe80::51ef:1853:48c0:17de%5]) with mapi id 15.20.1771.007; Sat, 30 Mar 2019 12:55:00 +0000
From: "Poscic, Kristian (Nokia - US/Mountain View)" <kristian.poscic@nokia.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: clearing of the Destination-Host AVP in the retransmitted request
Thread-Index: AdTmh7TwzN1E6HnzRjKZFmd70UeSTA==
Date: Sat, 30 Mar 2019 12:55:00 +0000
Message-ID: <AM0PR07MB5490C5A45B7C282661941E16ED5B0@AM0PR07MB5490.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kristian.poscic@nokia.com;
x-originating-ip: [135.245.20.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bd5a4b05-f7d5-44bc-173c-08d6b50eebcf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4787;
x-ms-traffictypediagnostic: AM0PR07MB4787:
x-microsoft-antispam-prvs: <AM0PR07MB4787DFBC762F7EA2B8AC9B0AED5B0@AM0PR07MB4787.eurprd07.prod.outlook.com>
x-forefront-prvs: 09928BEC91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(396003)(366004)(199004)(189003)(316002)(99286004)(7736002)(74316002)(25786009)(86362001)(478600001)(9686003)(54896002)(6306002)(6506007)(14454004)(106356001)(55016002)(53936002)(2501003)(2351001)(6916009)(102836004)(105586002)(52536014)(14444005)(5640700003)(186003)(4743002)(6436002)(5660300002)(1730700003)(486006)(81156014)(66066001)(790700001)(8676002)(6116002)(256004)(8936002)(2906002)(97736004)(7696005)(26005)(33656002)(3846002)(81166006)(71200400001)(71190400001)(68736007)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4787; H:AM0PR07MB5490.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: UipS9AtQhu0fJi0QBUwDbOiXmnfG2vplm+nfsq5vqWvExm3AdnRfx/n8Z+FMBiybdtSKK/5zc3zgX1DKd6/WW9/HQMctkN5249/V9v53HwTJ3mrRrc4EveBEUlT57f3TdfwOsi+uYBRBtW8QFVd1FxLIkCYhL+JH73HJ7KU1/5tf24k1M6VK4qAIjWFmvzfUzo9q6QeMClpIvfmB3ejlcCq+2MHebYlYCcQxHMQCd4M8aLdO+l8qZD0FJOsDHxRz/SAhm9xEGpO0drdLj8tIsz62GeUf65xuGybJ5Gh4qOEV0cg4EcWrkUkzM57rh5AU/q1dyT7+DzcxCS/jYn4QVQ+bUZzpbYgyvTHo4Gp4/K5o8yvAVVNnRKGy9v1RubFzF8kc1tGXTfiRJW4Rh2/vCO9WgVliviTlOodeKtlFg1w=
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5490C5A45B7C282661941E16ED5B0AM0PR07MB5490eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd5a4b05-f7d5-44bc-173c-08d6b50eebcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2019 12:55:00.8440 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4787
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/b_11AThiSZeBe1-1cWZ5sC2KWfQ>
Subject: [Dime] clearing of the Destination-Host AVP in the retransmitted request
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 30 Mar 2019 12:55:14 -0000

Can someone clarify in which case should a Diameter client (DC) clear the Destination-Host AVP in the *retransmitted* request message:


  1.  When the peer failover occurs - say the connection to node 1 fails  and DC retransmit the request in the pending queue to node 2? Section 5.5.4 in RFC 6733 is not specific about this, and it may even imply that the destination-host should not be cleared. Even though the clearing it may be beneficial.



  1.  When the client receives Diameter_Unable_to_Deliver (with E-bit set) error message, which indicates that the node to which the request is sent is unable to deliver the message to the destination-host (or realm). In this case it would be beneficial to blacklist this peer for this particular Diameter session. The application (Gx/Gy/NASREQ) could then retransmit, but it clearly does not make sense for Diam Base to send the message to the same peer. Should the destination-host be cleared in this retransmit? Some of this is mentioned in RFC 4006, sec 6.5, but again, it is not clear.


I assume that when the original request message times out (due to no answer received) and it is retransmitted after Tx timer expires, the destination-host is not cleared in the retransmit.

Also, should the CC-Req-Num be the same on retransmit, or should the client use a new one?

                                            +---------+
                                            |Diameter |
                      +---------------------|         |
         +---------+  |                     | Node 1  |
         |Diameter |--+                     +---------+
         |         |
         | Client  |--+                     +---------+
         +---------+  |                     |Diameter |
                      +---------------------|         |
                                            | Node 2  |
                                            +---------+


Note: Diameter Node 1 and Node 2 could be relay agents OR the home servers (say redundant PCRFs, each with it's own unique peer name).
I assume that DC should not make a decision on how to react based on the knowledge whether it has peering connection with the RA or the server.

This is in the context on plain Base, without any overload functionality (overload reports).
Thanks,
Kris

v2.23.0 | Report a Bug | By Email