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

[Naveen Kottapalli <[e-mail]>]

Comments inline.

Yours,
Naveen.


On Thu, 17 Jan 2019 at 23:24, Wojciech Szczypta <
[e-mail]> wrote:

> 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.
>
Naveen] Stack has to wait for STA to come back before deleting the session.

> 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.*
>
Naveen] I see that the specification is clear here.  It says that session
state MUST be freed upon receipt of STR (by server) and not after sending
STR (by client).

>
> 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
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>