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

[Æstrid Smith <[e-mail]>]

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