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

["Poscic, Kristian (Nokia - US/Mountain View)" <[e-mail]>]

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<https://tools.ietf.org/html/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
To: [e-mail]
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).
Thanks,
Kris