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

"Poscic, Kristian (Nokia - US/Mountain View)" <> Wed, 03 April 2019 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43A7D120150 for <>; Wed, 3 Apr 2019 10:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G_nULxh2B-ND for <>; Wed, 3 Apr 2019 10:38:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94870120143 for <>; Wed, 3 Apr 2019 10:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P9DvMQyrjEzAi9spbN238b1kXV9zt/agcMNwAJs2nYM=; b=Sp4ucjXRBJriVQNLsv2OyQddM7RN+FfRbs6Gpcn3GORPxWPvmSSn8hplaN5cQ8zZqZvmJTyC/RO1Jau2zWr+Q1aYBd45yuso0AAexjaH7mbBIxpLpHx5w9rM/qQsmx3Z1QlF8nauN2LvLva93NgNSW5LmlTAHUYcSkGZPR5sPJQ=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 17:37:58 +0000
Received: from ([fe80::21b1:c7ad:ab85:b8a5]) by ([fe80::21b1:c7ad:ab85:b8a5%3]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 17:37:58 +0000
From: "Poscic, Kristian (Nokia - US/Mountain View)" <>
To: "" <>
Thread-Topic: clearing of the Destination-Host AVP in the retransmitted request
Thread-Index: AdTmh7TwzN1E6HnzRjKZFmd70UeSTADu888w
Date: Wed, 03 Apr 2019 17:37:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b37a354c-9240-4ce8-f14e-08d6b85b1d14
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5462;
x-ms-traffictypediagnostic: AM6PR07MB5462:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0996D1900D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(136003)(39860400002)(189003)(199004)(478600001)(6246003)(7736002)(53936002)(9686003)(6306002)(74316002)(6506007)(55016002)(236005)(54896002)(5640700003)(14454004)(186003)(26005)(71200400001)(71190400001)(102836004)(76176011)(52536014)(476003)(2906002)(86362001)(11346002)(6916009)(446003)(486006)(81166006)(81156014)(1730700003)(8936002)(8676002)(68736007)(105586002)(25786009)(5660300002)(229853002)(2351001)(106356001)(99286004)(7696005)(6436002)(316002)(53546011)(97736004)(33656002)(14444005)(256004)(4743002)(66066001)(2501003)(3846002)(6116002)(790700001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5462;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 59NJoKdfcJKcw0VhBTUthYh8QK6mLj4tFcmmLFqzzFr5UYQdMjAMR0jgFZSnhLFvHLzA2IiLbmXJjjWOqrURmLUCJPeJ8Z+8m0KcfodykkM+c4OyXfJgRSuaYYKIi9O4wmrAnKap2iWMRyPn70pvQMi8Nh3NyP02blNXiF9uVIzcQZbWViMVd9Zw0a4fM8TrA53zvmAWSJrq3P53p8O+yTNbGNaHaw6CUjI40/4mJbyHOmUFfu9QmN+LYo1YkFljIsu/U2wejQp0/hIycYeFNBKfleEM7/m+KC19ANaxQTxQEocr+XCZuBd5mCBxQaNEAPuQk/QVX1xv5VEOJquYulVCkPLR11nKMMBu2UH3435nhBSBKC4DYioDqKbZ9Dm20fBpuU5z4+RnyCmrytbjEbzK11vWbLmsf882Z2JGRrE=
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5493F12A2AE745CA60268D8DED570AM6PR07MB5493eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b37a354c-9240-4ce8-f14e-08d6b85b1d14
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 17:37:58.8419 (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: AM6PR07MB5462
Archived-At: <>
Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2019 17:38:05 -0000

Ok, I'll take it that crickets on this thread are related to the following text in section 5.2 of RFC 7068.

The issues with error responses described in [RFC6733<>] extend beyond

   the particular issues for overload control and have been addressed in

   an ad hoc fashion by various implementations.  Addressing these in a

   standard way would be a useful exercise, but it is beyond the scope

   of this document.

From: Poscic, Kristian (Nokia - US/Mountain View)
Sent: Saturday, March 30, 2019 7:55 AM
Subject: clearing of the Destination-Host AVP in the retransmitted request

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.

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