Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 19 November 2014 20:54 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38801A8739 for <tsvwg@ietfa.amsl.com>; Wed, 19 Nov 2014 12:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.145
X-Spam-Level:
X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001] autolearn=ham
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 3YW9Yz2rK9ip for <tsvwg@ietfa.amsl.com>; Wed, 19 Nov 2014 12:54:44 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E151A8747 for <tsvwg@ietf.org>; Wed, 19 Nov 2014 12:53:39 -0800 (PST)
Received: from [192.168.1.200] (p508F059E.dip0.t-ipconnect.de [80.143.5.158]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 737A71C1052A8; Wed, 19 Nov 2014 21:53:36 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="iso-8859-1"
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Priority: 3 (Normal)
In-Reply-To: <5d68d136cd87bde12faaf414b05167d3.squirrel@spey.erg.abdn.ac.uk>
Date: Wed, 19 Nov 2014 21:53:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <798ABCB9-1C4E-4781-A51C-4D3228C0F1EC@lurchi.franken.de>
References: <5d68d136cd87bde12faaf414b05167d3.squirrel@spey.erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/sgHGKQJc7bESzkThO0BoejAY_So
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 19 Nov 2014 20:54:49 -0000
On 29 Oct 2014, at 15:01, gorry@erg.abdn.ac.uk wrote: > TSVWG, > > This is the start of a WGLC on "Quick Failover Algorithm in SCTP". > https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-08 > > This WGLC will last until Wednesday, 19th November, 2014, this includes > the period of the coming IETF meeting. > > A good note to the list is "I have read this version of the draft, > and I approve (or support) its progression to RFC". The chairs > request notes to the list showing support to get a sense of the WG. Dear TSVSG, I have read this version of the ID and approve its progression to RFC. FreeBSD implements most of the stuff, however exposing the PF_State is not implemented yet (so no support for the SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket option). Furthermore, FreeBSD doesn't support yet the spt_pathcpthld field in struct sctp_paddrthlds, which means FreeBSD doesn't support the optional features described in Section 4.3. I have a general remark: The document uses the terms * Quick failover (it is even in the title of the document) * Permanent failover * SCTP-PF The relation of the above three is not clear for me since they are not used consistently. Some editorial comments. Please pick them carefully, since I'm not a native speaker and therefore my suggestions might be sub-optimal. But I think the language used in the document needs to be improved. * Abstract: s/is that it supports multi-homed communication/is the support of multi-homing/ s/[RFC4960] specified failover operation/failover operation as specified in [RFC4960]/ s/of SCTP multi-homed operation./of the SCTP failover operation./ s/The memo complements RFC 4960/This memo complements [RFC4960]/ s/of the Potentially Failed state/of the Potentially Failed path state/ s/and associated new/and the associated new/ s/during network failure/during a network failure./ s/and specifies for SCTP senders to support this more performance optimal failover procedure as an add-on to the [RFC4960] failover operation.// s/The memo in addition complements [RFC4960]/Furthermore this memo complements [RFC4960]/ s/by introduction of/by introducing of an/ s/modes/mode/ s/a failover/the recovery of a failed primary path/ s/These operation modes offer/This operation mode offers/ s/for more performance optimal operation in/performance improvements in/ s/From the perspective of this memo the/The/ s/considered optional./optional./ s/The procedures defined require/The procedures defined in this document require/ * Section 1: s/an SCTP association can bind to multiple IP addresses at each endpoint/an SCTP endpoint can bind multiple IP addresses./ s/network interface redundancy and improved end-to-end fault tolerance./network fault tolerance./ s/failed retransmissions/failed timer-based retransmissions/ s/to SCTP and allows/to SCTP that allows/ s/after a failover impacts/after the recovery of a failed path/ s/With [RFC4960] procedures/With the procedures specified in [RFC4960]/ s/switch back to use the primary path/switch back to the primary path/ s/becomes available./becomes available again./ s/for SCTP to support the Permanent Failover switchover procedures proposed by [CARO02]./the Permanent Failover procedures proposed by [CARO02]./ s/alternative approach/alternative approaches/ s/provided in Appendix./provided in the Appendices./ * Section 3: s/Issues with the SCTP Path Management/Issues with the SCTP Path Management as specified in RFC 4960/ s/issues in the current SCTP/issues in SCTP as specified in [RFC4960]/ s/SCTP can utilize multiple IP addresses for a single SCTP association./An SCTP endpoint can support multiple IP addresses./ s/initial negotiation/the initial negotiation/ s/define this as the primary/use this as the primary/ s/SCTP sends/an SCTP endpoint sends/ s/heartbeat packets/packets containing a HEARTBEAT chunk/ s/of the path./of these destination addresses./ s/to secondary destination address, when/ to an non-primary destination address, if/ s/to be active/to be active and clears the error counter for that destination address./ s/error count for the/error counter for that/ s/protocol parameter 'Path.Max.Retrans'/tunable protocol parameter Path.Max.Retrans (PMR)/ s/SCTP endpoint/the SCTP endpoint/ s/(error counter/(the error counter/ s/stop using non-primary one./stops using the non-primary one./ s/significant amount/a significant amount/ s/starts to use the secondary path./starts to use the non-primary path for initial data transmission./ s/in the standard/in [RFC4960]/ s/before failover takes place/before the failover takes place/ s/to the secondary address/to an active non-primary address/ s/to the primary/to the primary address/ s/to the secondary/to the non-primary/ s/and can thus be reached at the receiver./and thus can be received by the peer./ s/will not be acceptable/is not acceptable/ s/path is active again/path becomes active again/ * Section 4: s/updates SCTP path management scheme with the Potentially Failed state and associated Quick Failover operation./extends the SCTP path management scheme by adding the Potentially Failed state and the associated Quick Failover operation./ * Section 4.1: s/minimize performance impact/minimize the performance impact/ s/destination/destination address/ s/destination/destination address/ s/is ideal so that/is better because/ s/transitions a destination/can transition a destination address/ s/a destination as/a destination address/ Define AMR. It is used here the first time. s/address performance impact/address the performance impact/ s/This new method/SCTP-PF defined in this document/ s/between Active and Failed states/between the Active and Failed state/ * Section 4.2: s/SCTP-PF Algorithm Detail/SCTP-PF Algorithm in Detail/ s/SCTP PF operation/The SCTP-PF operation/ s/Heartbeats/HEARTBEAT chunks/ s/If an heartbeat is unanswered/If a HEARTBEAT chunk is not acknowledged/ s/another heartbeat immediately/another packet containing a HEARTBEAT chunk immediately/ s/of heartbeats may/of HEARTBEAT chunks MAY/ s/as SACK or T3-rtx timer/as a T3-rtx timer/ s/that heartbeats be send/that HEARTBEAT chunks are send/ s/for the destination address/for that destination address/ s/receives an heartbeat ACK/receives a HEARTBEAT ACK/ s/transmit heartbeats to the/transmit HEARTBEAT chunks to the/ s/ACKs/Acknowledgements/ s/ACKs/Acknowledgements/ s/chunks which has been/chunks that have been/ s/ACKs/SACKs/ or s/ACKs/Acknowledgements/ s/SCTP stack SHOULD/An SCTP stack should/ Wouldn't you also want to signal state changes from PF to Failed and vice-versa? s/such SCTP stack MUST/such an SCTP stack must/ s/association state transitions/associated state transitions/ * Section 4.3: s/degradation, Permanent Failover/degradation, the Permanent Failover/ s/even if the old primary/even when the old primary/ Sorry for the long list of editorial comments, but I wanted to be as concrete as possible. Best regards Michael > > Of course, you can ask for alternate text (where you supply the > actual replacement text, or convey the meaning sufficiently to the > authors) for anywhere in the document that you find unclear or troublesome. > > James/Gorry/David > TSVWG chairs > >
- [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-0… gorry
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Michael Tuexen
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Becke, Martin
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Michael Tuexen
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Yoshifumi Nishida
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Yoshifumi Nishida
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Becke, Martin
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Michael Tuexen
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Bob Braden
- Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failov… Yoshifumi Nishida