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

Naveen Kottapalli <> Fri, 18 January 2019 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A43D7131151 for <>; Thu, 17 Jan 2019 23:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQzs3vCneXqQ for <>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E436131150 for <>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
Received: by with SMTP id p6so9822896lfc.1 for <>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=63uJt22TkbKhXAr/H2xqGL2c3nPk9AxJZzzjTaviSTI=; b=EzTnxQOZaYYBohYfv8PIwxWC5FF/gJ6sL+SdcNwCFl0v0tZpW/ZjeGhLEggJ8ByS7K Ov9zqcB2N0gCZagt4gBmMcviy0DlI+op6+vVUP8q1iDKDnYf0zq0IW4cugnN0E1yDSao o1cEHl/6F+Q120hwtLowDfbS63Uot6l6nagtT1DUn44akb1qdSDUwjKt0zasxG4Vv2Pr ZVnG6fU9z2O5G4afUiMFTes5cLBwn7/6x9DzOd0+YuMZPV7TUHQsJ5ljAnRctkC0uFvE JmSfyWU9bvvzryh+CJ2YBa5lFvL9yKrZ+n29PfQMGwlPqFz5l0/P5HZAVUZkRMz96fC0 36HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=63uJt22TkbKhXAr/H2xqGL2c3nPk9AxJZzzjTaviSTI=; b=Mac0IddxK0Zqgg2qoYUnfTnV/btTKE6dZytCT48bbjJRg71wEozpo0zOVkxKU8phjl IdPmi5bhycjl6PrObMJMfezB3M6rJ34Gm5+1MD6uo/YiezdkihgawbRrD1p1k/cUufjc FauiRFe3Xb+5kMkl6NkJwyNIessRBJxuTdAuqasbLBB0F1hs1cyeAgpbJfr/7XkgG4I9 ozUObWnWw4wX8s8uCWL6jUaSD8RsDeAhB6Hx9hgH0expyKpOHvbvr0GRHZ0ewo4VrLj6 +/RxqIJAPd9ydMZT3r/FbzUWkalJd0TFY6kMf7cKmMI7Yyhnvt67r294gYT3eoMwHzLg 1fRA==
X-Gm-Message-State: AJcUukeUv1NIHE+nLn+qE4UiIgtdDSwjbWmyOPXterpH4zBtW7Myf1vJ ii7if/gicLWgSH+py8kgCEgO3k118PBHMferjz8=
X-Google-Smtp-Source: ALg8bN5cYQ02NbGaB7mNKMsXK9jHUQ7K+3jAwbCG/XbwsbEfU4/LVk/8cxDFyPUMmKo/yYcEm6XUfIimC0n1et6jWTY=
X-Received: by 2002:ac2:51af:: with SMTP id f15mr2243127lfk.44.1547797574392; Thu, 17 Jan 2019 23:46:14 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Naveen Kottapalli <>
Date: Fri, 18 Jan 2019 13:15:59 +0530
Message-ID: <>
To: Wojciech Szczypta <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000009b2329057fb6b477"
Archived-At: <>
Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Jan 2019 07:46:20 -0000

Comments inline.


On Thu, 17 Jan 2019 at 23:24, Wojciech Szczypta <> 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*
> _______________________________________________
> DiME mailing list