IETF Logo Mail Archive

RE: quick failover in SCTP

"David Lehmann" <dlehmann@ulticom.com> Thu, 14 October 2010 14:15 UTC

Return-Path: <dlehmann@ulticom.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD883A6A0A for <tsvwg@core3.amsl.com>; Thu, 14 Oct 2010 07:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+OVufZs+s6z for <tsvwg@core3.amsl.com>; Thu, 14 Oct 2010 07:15:38 -0700 (PDT)
Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id E7A7E3A6948 for <tsvwg@ietf.org>; Thu, 14 Oct 2010 07:15:37 -0700 (PDT)
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id DDB3B34E01F16A12; Thu, 14 Oct 2010 10:16:56 -0400 (EDT)
Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o9EEGWch000376; Thu, 14 Oct 2010 10:16:49 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: quick failover in SCTP
Date: Thu, 14 Oct 2010 10:14:39 -0400
Message-ID: <A51D8ACD861B7E41BFC7FE5C64BE9648135ADBEA@MTLEXVS01.ulticom.com>
In-Reply-To: <AANLkTikAFt7q=nOphfFcs2ur8M131sudmqi8myweHvnj@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: quick failover in SCTP
Thread-Index: Actp+k9Wo3y61+WjQJS3pviIPRRPLABrwAgg
References: <AANLkTi=07JfcQOKhfLouaU8N6=r57Koh9fKw+j3=O56R@mail.gmail.com><8CF58AED-5D88-46A3-B873-26AAB8DAF9BD@lurchi.franken.de><AANLkTi=2uGTkPjtcohABJ3vpy=5ryAMzXSwGiq3tXgi_@mail.gmail.com><17E9584A-5AC1-4CC7-AC93-7207412DD05B@lurchi.franken.de><AANLkTi=4NDwVgkgsndZYy_t6OcA4b3fgOBC4w+o+HEhA@mail.gmail.com><EC763CF2-05B6-4A3F-A508-72E482A5E5BE@lurchi.franken.de> <AANLkTikAFt7q=nOphfFcs2ur8M131sudmqi8myweHvnj@mail.gmail.com>
From: David Lehmann <dlehmann@ulticom.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
Received-SPF: pass
Cc: tsvwg@ietf.org, Preethi Natarajan <prenatar@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 14:15:39 -0000

> >>> I would like to see some extensions to you suggestion:
> >>> * Introduce a threshold (call it PFMR for now).
> >>>  Then use
> >>>  if (error counter > PMR)
> >>>     the path is inactive.
> >>>  if (error counter <= PMR) && (error counter > PFMR)
> >>>     the path is potentially failed.
> >>>  Using PFMR = 0 is what you suggest, PFMR=PMR gives
> >>>  the old behavior.
> >>
> >> I thought similar thing and I agree with providing a way to disable PF.
> >> I tend to agree with this idea, but one thing I'm not very sure is how
> >> PFMR != 0 && PFMR < PMR can be useful.
> > I could image someone wanting to call a path potentially failed
> > after 2 consecutive timer based retransmission instead of 1.
> > Just being a bit more conservative. This might help deploying
> > such a feature in SIGTRAN networks where CMT is not deployed.
> > For CMT traffic, PFMR==0 is the right choice, I guess.
> > But I think PF is also very helpful in non-CMT scenarios.
> 
> OK. I think it would be good to have tunable parameter for users. I
> agree with this.

Just to be clear the default would be PFMR == 0, which means use another path if the error count is non-zero.  Correct?

-David

v2.23.0 | Report a Bug | By Email