Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information
Naveen Kottapalli <naveen.sarma@gmail.com> Fri, 18 January 2019 07:46 UTC
Return-Path: <naveen.sarma@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43D7131151 for <dime@ietfa.amsl.com>; Thu, 17 Jan 2019 23:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQzs3vCneXqQ for <dime@ietfa.amsl.com>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E436131150 for <dime@ietf.org>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id p6so9822896lfc.1 for <dime@ietf.org>; Thu, 17 Jan 2019 23:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CACP0BpouvmXnjzysGoqKzQxOughvtyRrQdU5+EmF1-jrOrjF8g@mail.gmail.com>
In-Reply-To: <CACP0BpouvmXnjzysGoqKzQxOughvtyRrQdU5+EmF1-jrOrjF8g@mail.gmail.com>
From: Naveen Kottapalli <naveen.sarma@gmail.com>
Date: Fri, 18 Jan 2019 13:15:59 +0530
Message-ID: <CANFmOtmp+r_aC5M-idjosV3zEAFooN49KYYDqmb5P0YVVNuHUw@mail.gmail.com>
To: Wojciech Szczypta <wojciech.szczypta@motorolasolutions.com>
Cc: "dime@ietf.org" <dime@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b2329057fb6b477"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/ehm8k-9Y6DGFN8AUIovp3I0tXs8>
Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis - failover (handling not delivered/non-acknowledged STR) and session information
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 07:46:20 -0000
Comments inline. Yours, Naveen. On Thu, 17 Jan 2019 at 23:24, Wojciech Szczypta < wojciech.szczypta@motorolasolutions.com> 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 > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >
- [Dime] Mail regarding draft-ietf-dime-rfc3588bis … Wojciech Szczypta
- Re: [Dime] Mail regarding draft-ietf-dime-rfc3588… Naveen Kottapalli