Re: [tsvwg] draft-ietf-tsvwg-rfc4960-bis-08 and SFR

Michael Tuexen <tuexen@fh-muenster.de> Tue, 02 February 2021 13:38 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1613A1AD5 for <tsvwg@ietfa.amsl.com>; Tue, 2 Feb 2021 05:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.48
X-Spam-Level:
X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 r1s8W0gzqxD9 for <tsvwg@ietfa.amsl.com>; Tue, 2 Feb 2021 05:38:23 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD503A1AD4 for <tsvwg@ietf.org>; Tue, 2 Feb 2021 05:38:22 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:4d54:d34d:bac:c17b] (unknown [IPv6:2a02:8109:1140:c3d:4d54:d34d:bac:c17b]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 366F8721BE017; Tue, 2 Feb 2021 14:38:16 +0100 (CET)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <EBBDC6FF-C776-4E71-8264-1A660D6C9279@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_804217C0-EE05-4D1F-B884-720472289207"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 02 Feb 2021 14:38:15 +0100
In-Reply-To: <20201204225930.GG449907@localhost.localdomain>
Cc: tsvwg@ietf.org
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
References: <20201204225930.GG449907@localhost.localdomain>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ZMyAXJiEFvYgGg87Y9pPrPKRMIM>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc4960-bis-08 and SFR
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 02 Feb 2021 13:38:26 -0000

> On 4. Dec 2020, at 23:59, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> 
> Hi,
> 
> Was it considered to add the Split Fast Retransmit from [1,2]
> to 4690bis instead? It might be a too big change for a bis edition,
> more complex, but it helps to better isolate path characteristics.
> SCTP already has a cwnd per destination, and drops on different,
> likely unrelated, paths shouldn't interfere on another's cwnd. I
> understand that if not in CMT context, the gains out of it may not be
> appealing enough, as in theory it would be most effective only during
> path fail overs.
Hi Marcelo,

such a change was not suggested. And I think SFR is more in the context of
multipath and as you know, it seems that multipath support for SCTP will
not progress in TSVWG.

I guess, if we would introduce RACK for SCTP, we would do something path
specific. But I'm not sure if there is interest in doing this.
Need to talk to people...

Best regards
Michael
> 
> 1.http://dx.doi.org/10.1109/TNET.2006.882843
> 2.https://datatracker.ietf.org/doc/html/draft-tuexen-tsvwg-sctp-multipath-20#section-3.1
> 
> Best regards,
> Marcelo
>