Subject: Quick Failover Algorithm in SCTP

From: "David Lehmann" <[email-masked]>
Date: Wed, 19 Jan 2011 14:39:05 -0500

Hello,

What is the status of this I-D?  draft-nishida-tsvwg-sctp-failover-02

I would like to see this feature move forward.  As you are aware, it is
crucial in the telecom world that a failure is resolved quickly.
Ulticom has had quick failover in its SCTP implementation for 10 years
now.  IMHO, each OS' native SCTP implementation should have quick
failover.   ...just my $.02 

What is the next step in the process?

--

David Lehmann

Ulticom, Inc.

856-787-2952

---

From: Thomas Steffen <[email-masked]>
Date: Wed, 19 Jan 2011 20:24:09 +0000

On Wed, Jan 19, 2011 at 7:39 PM, David Lehmann <[email-masked]> wrote:
> IMHO,
> each OS’ native SCTP implementation should have quick failover.   …just my
> $.02

I didn't say much on this list recently, but to come out of hiding: I
fully agree.  Failover is pretty useless if it does not happen
quickly.  You can define quickly as roughly within normal transmission
time (milliseconds) or within about a second.  But the standard on OS
level used to be around 30s, and that is bound to cause problems in
most applications.

Regards,
Thomas

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Jan 2011 14:48:33 -0600

At 01:39 PM 1/19/2011, David Lehmann wrote:
>I would like to see this feature move 
>forward.  As you are aware, it is crucial in the 
>telecom world that a failure is resolved 
>quickly.  Ulticom has had quick failover in its 
>SCTP implementation for 10 years now.  IMHO, 
>each OS’ native SCTP implementation should have 
>quick failover.   …just my $.02
>

The status of this ID is that of an individual 
submission, with a target WG of TSVWG. The chairs 
currently believe there has been insufficient 
review within the WG to date to warrant 
progressing this document to the next level. Your 
note obviously helps the chairs determine if 
there is interest in this effort. We thank you 
for the comment. More comments (that show there 
was a review per comment, preferably) will nudge 
us towards reviewing progression of this effort.

Does this seem reasonable?

James & Gorry
TSVWG chairs

---

From: "David Lehmann" <[email-masked]>
Date: Wed, 19 Jan 2011 15:56:42 -0500

> Does this seem reasonable?

Yes.  

Those in favor of this document, please speak up!  
Thank you.

-David

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 19 Jan 2011 22:04:02 +0100

> Those in favor of this document, please speak up!  
Dear all,

I do support this document (after initially being conservative).

It should be noted that using PFMR = PMR, the behavior of RFC 4960
is used.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Wed, 19 Jan 2011 18:00:05 -0500

+1

I have often thought after my work with Armando that expanding
the way we do failover in SCTP is a good thing..

This is a good start... and with a bit of WG help SHOULD become
what we do in SCTP stacks ;-)

R

> It should be noted that using PFMR = PMR, the behavior of RFC 4960

-----
Randall Stewart
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 19 Jan 2011 17:44:09 -0700

David,

I'm not in favour of the document, but I'll speak up
anyway.  I do not support this document because
CMT-based approaches are far superior and have been
fielded by multiple commerical implementations for
quite a few years.  I would sum up this draft as too
little too late.  Progressing it would place pressure
on implementations already using the superior approach
to also implement this half-baked inferior one.

OTOH, I would support (with comments, review and field
experience) standardization of the full CMT-based
approach.  Note also that there are more individuals
actively contributing to the WG that have significant
experience with the CMT-based approaches.

--brian

David Lehmann wrote:                   (Wed, 19 Jan 2011 15:56:42)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Chris Benson <[email-masked]>
Date: Wed, 19 Jan 2011 17:38:07 -0800 (PST)

>>  draft-nishida-tsvwg-sctp-failover-02

+1.

This looks useful even in the presence of other extensions.

Chris Benson.

On Wed, 19 Jan 2011, David Lehmann wrote:

>>  Date: Wed, 19 Jan 2011 15:56:42 -0500
>>  From: David Lehmann <[email-masked]>
>>  To:  <[email-masked]>
>>  Subject: RE: Quick Failover Algorithm in SCTP
>>  
Chris Benson, Software Engineer,
Adax Inc., Berkeley, California, USA.
    [email-masked]
    +1 510 548-7047 ext. 189
    www.adax.com

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 20 Jan 2011 20:51:43 +0100

Dear all,

quick failover will actually be part of the full CMT-based approach described 
by the document draft-tuexen-tsvwg-sctp-multipath-01.txt. See section 4.3 of 
this draft. Without quick failover, CMT-SCTP would try to send on not working 
paths for a long time. This would significantly degrade performance.

Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 20 Jan 2011 20:43:06 +0100

Dear all,

quick SCTP failover is crucial for all time-critical multi-homed applications. 
Particularly, I deploy RSerPool-based SCTP applications in a multi-homed 
environment. Improved SCTP failover speed reduces the number of expensive 
session-level failovers in case of network problems.

Therefore, I support this document.

Best regards

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 Jan 2011 09:57:56 +0200

Hi,

> Those in favor of this document, please speak up!  

as AD, let me point out that "speaking up" is not sufficient.

If folks want to have the WG adopt it and move it along, *they* will need to sign up for doing the editing and reviewing work on a continuous basis. ("Vote by volunteering your own cycles.")

Lars

---

From: Randy Stewart <[email-masked]>
Date: Fri, 21 Jan 2011 05:19:19 -0500

Lars:

You can count on me to review the drafts and send text... in fact I will
even one better that.. If adopted as a wg item I will put it into the FreeBSD
SCTP implementation ;-)

R

-----
Randall Stewart
[email-masked]

---

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 21 Jan 2011 11:36:27 +0100

On Freitag 21 Januar 2011, Lars Eggert wrote:
> If folks want to have the WG adopt it and move it along, *they* will need
> to sign up for doing the editing and reviewing work on a continuous basis.
> ("Vote by volunteering your own cycles.")

Dear Lars,

I am also going to review future versions of this document.

Best regards

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 21 Jan 2011 05:35:35 -0700

Thomas,

Thomas Dreibholz wrote:              (Thu, 20 Jan 2011 20:51:43)
> paths for a long time. This would significantly degrade performance.

Two comments:

- - draft-nishida-tsvwg-sctp-failover-02 does not support loadsharing and
  cannot be used for CMT without modification (which was my point).

- - under superior CMT approaches, it is the loadsharing algortihm itself
  that is adjusted based on a number of factors (retransmission peg
  counts only being one).

So, I don't think that draft-nishida-tsvwg-sctp-failover-02 is necessary
to proceed with draft-tuexen-tsvwg-sctp-multipath-01: a draft that I
would support going forward without so-called non-CMT 'quick-failover'
and using instead the superior approaches.

To be fair, AFAIK it was never the intentions of draft-nishida-tsvwg-
sctp-failover-02 to support CMT, nor to attempt to rival CMT failover
approaches: I believe that it was originally intended just to document
remedies for a little quicker failover for non-CMT implementations.

This was discussed in the 'Quick Failover in SCTP' ladder on TSVWG
from March 17-18, 2010.

- --brian

- -- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tüxen <[email-masked]>
Date: Fri, 21 Jan 2011 15:29:47 +0100

> If folks want to have the WG adopt it and move it along, *they* will need to sign up for doing the editing and reviewing work on a continuous basis. ("Vote by volunteering your own cycles.")
Hi Lars,

I already reviewed the document, comments from me were addressed, and I'm willing
to do this in the future. As Randy pointed out, we'll also implement it in FreeBSD.

So I'm willing to continue to work on the document.

Best regards
Michael

---

From: "David Lehmann" <[email-masked]>
Date: Fri, 21 Jan 2011 17:11:12 -0500

> remedies for a little quicker failover for non-CMT implementations.

IMHO, the failover would be significantly quicker.

-David

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 24 Jan 2011 01:54:42 -0800

Hello Brian,

I believe we both agree failover is an important issue.
I guess the problem is how we solve it. You don't prefer this approach
since you know better one, which is fine to me. However, I would like
to understand what is superior approach so that I can think about it
throughly. Also, I would like to know if it's going to be
standardized.

I would like to avoid leaving this issue without doing anything. I
hope you'll agree this part.

Thanks,
--
Yoshifumi Nishida
[email-masked]

2011/1/21 Brian F. G. Bidulock <[email-masked]>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFNOX2XMYOP2up1d2URAn1uAJ95gFHDRj9/Yvnd7A1icDAJWe5aBgCgt+KO
> D+Ofg1tg2rGFpJgIKidVqbc=
> =8IEI
> -----END PGP SIGNATURE-----
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Jan 2011 05:42:57 -0700

Yoshifumi,

I believe we already had this discussion.  See the thread starting with:

 http://www.ietf.org/mail-archive/web/tsvwg/current/msg09912.html

If there is something you didn't understand from the previous discussion,
please feel free to ask away.

--brian

Yoshifumi Nishida wrote:                      (Mon, 24 Jan 2011 01:54:42)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Mon, 24 Jan 2011 14:05:49 -0500 (EST)

Hi,

I'm completely an observer and not an SCTP protocol implementer.  As a distributed file systems developer, I have been interested in SCTP and in particular, CMT, since 2007.  I'm finding it difficult to track the discussion completely.  Is it in fact the case that the openss7 CMT is not interoperable with that in FreeBSD?  That now seems implied.  What process of interop testing or mutual design review, if any, has been attempted on them thus far?  Does the openss7 team presently have a research obligation (or opportunity)?  Am I missing more context?

Thanks, and sorry for any distraction.

Matt

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 24 Jan 2011 14:54:25 -0700

Matt,

Matt W. Benjamin wrote:                     (Mon, 24 Jan 2011 14:05:49)
> Hi,
> 
> I'm completely an observer and not an SCTP protocol implementer.  As a
> distributed file systems developer, I have been interested in SCTP and
> in particular, CMT, since 2007.  I'm finding it difficult to track the
> discussion completely.

Welcome to the wunnerful world of SCTP!  If CMT is of interest to you
Thomas' conference should be of special interest:

	http://www.tdr.wiwi.uni-due.de/en/workshops/pams-2001

> Is it in fact the case that the openss7 CMT is not interoperable with
> that in FreeBSD?  That now seems implied.

Our implementation and many other implementations successfully interop
tested with FreeBSD from the 2nd SCTP plugtest in 2001 in Sophia
Antipolis through the 6th in Vancouver and beyond.  Are you saying that
FreeBSD implemented something recently that was not interoperable with
other implementations?  I wouldn't believe it.

> What process of interop testing or mutual design review, if any, has
> been attempted on them thus far?

A wide range of SCTP implementations (many more than just FreeBSD and
OpenSS7) have been tested at SCTP plugtests and interoperability events
over the past 10 years.  Many have also been the thesis of a number of
post-graduate degrees and the subject of many research papers.

> Does the openss7 team presently have a research obligation (or
> opportunity)?

You can contact me off-list if you have an opportunity to offer.

> Am I missing more context?

Probably.  It is considered bad form to review or promote specific
implementations on an IETF list.  I cannot help you here with the process
of software selection: I can only discuss techniques as they apply to
the SCTP protocol.

I am thinking that maybe you didn't intend to send this note to the
WG list.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Mon, 24 Jan 2011 17:24:29 -0500 (EST)

Hi,

Apologies, it was not my intention to compare implementations in this sense.  I was not trying to discuss commercial opportunities either, just trying to better understand the discussion.  I am certain that I still don't, but I'm making it worse.

Thanks (and sorry),

Matt

-- 

Matt Benjamin

The Linux Box

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 25 Jan 2011 11:12:49 +0100

Dear all,

> 	http://www.tdr.wiwi.uni-due.de/en/workshops/pams-2001

The URL of the PAMS 2011 is http://www.tdr.wiwi.uni-
due.de/en/workshops/pams-2011/ .

> post-graduate degrees and the subject of many research papers.

I have looked up the previous SCTP interops. There have been 9 SCTP interops 
to far:
1. Munich, June 2000
2. Research Triangle Park, October 2000
3. Sophia Antilopis, April 2001
4. San Jose, February 2002
5. Essen, September 2002
6. Newark, June 2003
7. Münster, July 2004
8. Vancouver, July 2006
9. Kyoto, August 2007

That is, the last interop has been organized 3.5 years ago. 

Is there any interest in another interop meeting, in order to test up to date 
features? Particularly, newer things like CMT-SCTP, NR-SACK, SACK Immediately, 
Stream Reset, PKTDROP, UDP Encapsulation, NAT Traversal, etc. could be tested.

As already offered at the last interop, a further interop could again be 
organized at the University of Essen.

Best regards

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 13:20:06 +0200

Our STCP stack implementation, used in high end Telecom signaling nodes, implements the potentially failed feature and has done it since the 
beginning of deployment 3-4 years back. We think the feature is equally important for CMT-SCTP as for standard (non-CMT) 4960 SCTP. We have not deployed
an CMT STP setting (yet). Until recently we have operated with a PFMR threshold of about PMR/2, but recently we have changed this threshold to 0, 
meaning failover after one retransmission timeout.

BR, Karen

*****************************************************************************************
Karen Egede Nielsen
Software Architect, Ph.D.

Tieto Denmark A/S
IP Solutions, Telecom & Media
Skanderborgvej 232, 8260 Viby J, DK-Denmark
Direct Phone / Mobile +45 25134336
E-mail: [email-masked]
*****************************************************************************************

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Lehmann
Sent: 19. januar 2011 21:57
To: [email-masked]
Subject: RE: Quick Failover Algorithm in SCTP

Yes.  

-David