[Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information

[Wojciech Szczypta <[e-mail]>]

Hello,

I have a problem with fail-over procedure interpretation described in RFC
6733.
We believe that Diameter stack implementation, that removes session
information after sending STR before it received the acknowledgment, does
not follow RFC 6733.

Scenario: a peer established connection with a Diameter server (using SCTP)
and the peer activated an user session on a Diameter server.
After some time the peer has to terminate the session, so it's initiating
the STR to Diameter server, but at the point of time, when peer sends the
message a network failure occurs, that causes STR never reaches the server
(and server never acknowledges the STR).

Our application is build on top of the Diameter stack.
When the application sends the message to the Diameter stack the connection
is up.
According to the Diameter stack, the link is still operational at the point
of time, when the message is passed down to the SCTP stack.
However the STR never reaches the destined Diameter server due to network
failure. In fact we can't even see the STR on the network interface.
We suspect a race-condition occurs, when SCTP stack receives the STR from
Diameter stack, the SCTP already knows that there is problem with connection
We see in the network capture that peer re-tries sending DWR and Diameter
server re-tries to SACK previous DWR and retries to send DWA to peer the
previous DWR.

The main problem is that since Diameter stack "thinks" the message was sent
successfully to the server it removes the session information without
waiting for the answer.
Since the session information is removed by the Diameter stack, there is no
way the application can request STR re-transmission, after the connection
is re-estbablished.
Any further AAR or STR requests are ignored by the Diameter stack.

The vendor providing the Diameter stack claims that their RFC 6733
implementation is correct and it's up to SCTP stack to take care of
re-transmission.
However the problem is not with the non-delivery of the STR but with lack
of possibility to request STR re-transmission, making this communication
unreliable.
We believe the Diameter stack implementation does not follow the RFC,
however our interpretation is that RFC 6733 isn't clear about what should
happen in case the STR is not be delivered or acknowledged.

The section 5.5.4.  Failover and Failback Procedures in the RFC 6733
focuses on the using alternate path (if possible), but it does look more
like a recommendation than hard requirement.

There is a section in RFC 6733 which  says:
* Session state (associated with a Session-Id) MUST be freed upon*
*   receipt of the Session-Termination-Request, Session-Termination-*
*   Answer, expiration of authorized service time in the Session-Timeout*
*   AVP, and according to rules established in a particular Diameter*
*   application.*

In our scenario session state was freed before receiving STA, so our
interpretation is Diameter stack implementation doesn't follow this part of
RFC - it shouldn't remove this information if it hasn't received the STA.
Note: We are not using Session-Timeout AVP, so we need to make sure that
STR was delivered and acknowledged by the Diameter server, otherwise the
dedicated bearer will not be removed.

Regards.

*Wojciech SzczyptaMotorola Solutions Systems Polska*
motorolasolutions.com