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

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

Thanks Astrid (sorry for butchering the spelling of your name but I don't have an 'ae' character on my keyboard). 
On receipt of UNABLE_TO_DELIVER, diameter client would still retransmit  on a different next-hop peer (if available), just that the dest-host is removed so that the peer can make the decision where to deliver this message (based on the realm routing).
The assumption is that the servers (for example PCRFs) are all synchronized (georedundancy), and then any can respond for the session in the retransmitted request. 
If the application servers are not synched, then this would be a problem indeed. But then, the problem would be if we leave the dest-host intact in the retransmit  while the dest-host is truly down.

RFC 4006  6.5 allows for backup destinations. There, it is alluded that the client may have two destination hosts configured, and use one until 3002 is received. When 3002 is received (and some other config conditions are met), the second dest-host can be used. 
What I'm saying is that one can just remove the dest-host from the retransmit and the message will be naturally delivered via realm routing to some dest host (assuming georedundancy is supported).

It looks like that if vendors implement one behavior for this, it will address some scenarios, but it will break some other. Really no uniform solution.  
Kris

-----Original Message-----
From: Æstrid Smith <[e-mail]> 
Sent: Wednesday, April 3, 2019 1:25 PM
To: Poscic, Kristian (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request

Hi Kris,

Your second scenario, an Unable_To_Deliver reply, can be generated on predictive loop avoidance (6733 section 6.1.7) also.  Blacklisting the peer for that destination-host is a good choice in that scenario.  But I wouldn't think that clearing the destination-host is necessary, because if the message could be retransmitted on a different path it may eventually succeed.

If you're out of paths, though, as an ultimate fallback that seems reasonable.

But then, I work almost exclusively with the base protocol in context of a relay agent :) We don't touch the destination-host on any message, unless configured otherwise.  From my reading of rfc6733 section 6.1, there isn't much latitude to include or omit a destination-host on any particular message.
-- 
æstrid smith     -------------------
--<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
    ------------                     ------------------



On Sat, Mar 30, 2019 at 12:55:00PM +0000, Poscic, Kristian wrote:
> EXTERNAL MAIL: [e-mail]
> 
> 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

> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime