[tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-08
Claudio Porfiri <claudio.porfiri@ericsson.com> Tue, 01 December 2020 08:07 UTC
Return-Path: <claudio.porfiri@ericsson.com>
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 CC81B3A0A35 for <tsvwg@ietfa.amsl.com>; Tue, 1 Dec 2020 00:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sswdIEQ5uA4p for <tsvwg@ietfa.amsl.com>; Tue, 1 Dec 2020 00:07:57 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857E33A0A29 for <tsvwg@ietf.org>; Tue, 1 Dec 2020 00:07:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yo+6m9zO91j3e/EhIZ4lDhjQEB0TO7LwQi+2/bl8zQpQpb2FUVj14QjCkU+LCjtk1KtEm/u75cii0cuCkHLhcWrANIrPMawsuSAiMxf1UFijEdW6mfCzT5WGukfxVAFc0inNS8KTBEVR+6TLjyCklhQQ3sYrRc3ekJc2NSf8VKjusbJw30mLUit9QTL0UpWNfN865RwKaA3MeyOp1SqyC0DyEfIJ5Dq70f25eyGrcSuXAicmRfCijbcoWUO3/jKkolMUQQoCFDQ1s3iCQf50EBSKa98RlDm7f1HRJhakX8EvIkrclkXeE0q4A1Pakyojg+Vqq5mN0R56ZkN69zzZ7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DFDxW4YY9nHlmM3/oWzQxTV/AG34lKR8Deq/Aa705Bc=; b=VfAOH5AL9kXLYpqbUmJTcOocvMV5frck9i8/TvOyc9ccryZR3UCuC8PcpWtPHD20bmk4b//u+zsRRTMcJ5T9ELmMotoxCuveF6fgR+xJW+BLFZ2cORgY78wI6Ymc8V9izeJbUFkNh7xlrbmlsVrWabHJzH4QQFl/kHEwyEEMqZ5mn8/evgbGQ9h9s+0B4U/I7zfvIIWwFQo11Z4RteWLNRPkovDSePFCSdDAm33y3lVJqGr6xqccqFN1ijqhg/OqqrbNS3bH3EmpmEi8PRxY0NGpXfTBW3yqP9771U1jS19YcGcau99MBspOdhsXus1+kbt13Vlpc068BBdrWWa51Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DFDxW4YY9nHlmM3/oWzQxTV/AG34lKR8Deq/Aa705Bc=; b=pEe+VfWB2Y2MuLRjJrNKYta4eHCGWeDYDmCGe62FL89POCwU5XIJ5m8kYObvB4OAw4sj8hO+po5mVAHmdMXliBwj3xAz0V3gwoPVc/pAFCzyp5oJGEGccT2azO1VIXDdJ+4td25Je0RgbBRenyXDbeksfBPAVkQrszfn4gBmT9I=
Received: from AM0PR07MB4066.eurprd07.prod.outlook.com (2603:10a6:208:4d::18) by AM0PR07MB5524.eurprd07.prod.outlook.com (2603:10a6:208:104::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Tue, 1 Dec 2020 08:07:54 +0000
Received: from AM0PR07MB4066.eurprd07.prod.outlook.com ([fe80::30d7:7bd4:13f:b433]) by AM0PR07MB4066.eurprd07.prod.outlook.com ([fe80::30d7:7bd4:13f:b433%6]) with mapi id 15.20.3632.015; Tue, 1 Dec 2020 08:07:54 +0000
From: Claudio Porfiri <claudio.porfiri@ericsson.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Comments on draft-ietf-tsvwg-rfc4960-bis-08
Thread-Index: AdbHJXKXma7mUCLvQ4y75+JU3KfBlw==
Date: Tue, 01 Dec 2020 08:07:53 +0000
Message-ID: <AM0PR07MB406612FAC3238A432DCC041887F40@AM0PR07MB4066.eurprd07.prod.outlook.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.151.166.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 316de97b-9058-430f-75ca-08d895d0351a
x-ms-traffictypediagnostic: AM0PR07MB5524:
x-microsoft-antispam-prvs: <AM0PR07MB5524DFEEF93F54642922885F87F40@AM0PR07MB5524.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jp9VkQKOBN1ybE9xBiCwr1Pj5BOrjSUBL9tL83vMWZcDZXRdryk77o9Dbb+JC0b9zRNoYZJPzL27yE1wQaUnhpg6eYwUTJDpymPvw/9h9zpH4vSMzqhJAVmNiumArtOO76kqGHhoJz3UwJAACnzmA9YWM4W67qW6xMs9ZSd/brA5+rS+QDMAPdJ7dQrZnUhSbly2+K8D53AoZpaTCvkpe8C22SPx0WA44Dw/FjPd6cNFiQZ2sclUfrqRrq2Z7GeQQ/mVE0ebYhBKNAWrMWZZiMaJY2c45QYYeqSpCe7LockIh6/NRT/Y3toKIUKkHKxLxoSEFftpsP6sRuxstBVekw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4066.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(346002)(396003)(376002)(33656002)(44832011)(316002)(52536014)(66616009)(66476007)(76116006)(66446008)(64756008)(66556008)(9686003)(99936003)(2906002)(478600001)(86362001)(66946007)(8936002)(6916009)(55016002)(6506007)(7696005)(186003)(8676002)(83380400001)(26005)(71200400001)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: OfzeeB2xsE/XlaIgvwtVx0cCg55VUhijYDt+nwnU7q9MYHm1tYN9b/N5KF77chplLMBi30HHnohiRA9jQroRR+rAmxsNezX/Pq/j7mbpk7UxSYXPW9t6B/ejDotzEFN22BUY+OQGuWBkg8anDHcVHggHuvg6/h0Fu77NAKqY2BK0GBkKZd6Rvc2jZ5RhdYMdzyoyvvr2OS5PJ+VA2lN+PLL8bS6Xffcn2KLk3hoGdiJ3mwXVe9AjPQApPbpCMDSRKXsPbhROOQ+sa7aP+ATTKCP9ROrX2Mv7OKHdKOceLUb4dw6jgQ0eZuEXarwjhl0euKK1BaUMhhDMB9GwdE1UXa0QjhivR09TvA0VwsZyw7+Oo9Jaqo5olzGuWdQSrpFLJKSNAicLm70iW3LMCd5/Qm2wiKUNTR+hTYJHdPnpMlhmHUNYIGmVZ5+Ix4pwUbhVb39i0TPvf2nabykMxhUyQsYLtgJJlXMAMrKvhgEDcsqLGQD11dY63FKFfXL9W2xtQ1AjhhkkEn+bii8PNUJWj/+ThCMqCHf/Wt31kagtJVAIrdDyR+Yo6GOfXbU9Cer9hgm5jQLOYyD3AUyk7/5O9GY4mxOEDXKqVEaPon3vcyCNqzWoPT/paAgn9r7kWIaSe9fcPZIxM5tguUyhpwA68cyqb+ReBqlgrXjoKGG6fy9qhAcGwLTWoK1tYv3/JM9LpyGl2ZTQZ1fhl/AQVeELk4Pb+G12yQKgIQwAc7vXNSNhFjlOYFWJinEG1Vhe9RlQOvhfTStYofRwisiehA14B9MNBPKCln2FuEWUTdry4DfYVrihKemd4zgsjBcU6MaojMGAtrgrQ4z1q3hqR5uV4k8XgxhPf8EsEc25/EPmjA9SUn3tkqLvGkCsgmPU0WzLM/y70BU8sx795uTKw47wHwAU9+NbIzPBoTzwEXf6SuQeDwjsFiPEpIYvngB1ByPuYxaRO78CZ9C5ujmXyZDrpElWel2O7+aP/p9BbSlBsp4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0125_01D6C7C1.70D437E0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB4066.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 316de97b-9058-430f-75ca-08d895d0351a
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 08:07:54.3921 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: v9ZKMupg66LJvBI5jLHfFsbc0d5qUvQz9sLZ+kL5VoyG8ScEKAxbqyo4MPy+nRLNdRfpgx3Q5EYXOFotP6zYg78DxQUFWqR39/C/hSwVCNg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5524
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2vQQhG6MzO2M1PkeIgdna8Dm3AE>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-08
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, 01 Dec 2020 08:08:00 -0000
Hi, here are my comments on the draft: Generic: About chunks and timers, I'd wish to observe that having a t3-rtx timer on per chunk is computationally expensive, and that I don't see how it's possible that chunks being bundled in the same SCTP packet can be lost independently. An effective implementation would have a T3-rtx timer on per SCTP packet and tie all the transported chunks. About implementation of rx-buffer: it should be written somewhere that there MUST be independent rx-buffers on per Association. This come from having observed that implementations exist that share the same rx-buffer among all the Associations (and endpoints) and advertise the arwnd with the full shared buffer size. The clear side effect is that a zero-window situation for an Association causes zero-window case on all the other Associations. In section 6.1 "Transmission of DATA Chunks", part A, it's written: If the sender continues to receive SACKs from the peer while doing zero window probing, the unacknowledged window probes SHOULD NOT increment the error counter for the association or any destination transport address. This is because the receiver could keep its window closed for an indefinite time. Actually, when a fault happens at the SCTP User, the indefinite time of zero-window situation may cause a deadlock situation, I have observed that problem in the reality. It would be good suggesting for the implementor to have a supervision for zero-window situation that allows aborting the Association when that state lasts too long. In section 6.4 "Multi-Homed SCTP Endpoints" By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use. In situation where the primary path is not stable, this can cause traffic bouncing between paths. There are cases where cost is different per path, thus the SCTP adopter wants to use the primary path as soon as possible (i.e. when the path is IPSec encapsulated and the bandwidth on secondary IPSec tunnel is less than on the primary), but when the paths have the same cost, moving the association due to t3-rtx expiration towards another path would make the Association to use the path with better quality. That's why I'd change SHOULD with MAY and give the implementor a chance for deciding. Section 7.3 "Path MTU Discovery" An endpoint SHOULD apply these techniques, and SHOULD do so on a per- destination-address basis. In my opinion SHOULD is a MUST. Section 8.4 " Handle "Out of the Blue" Packets" The whole section assumes that a single SCTP Host is taking care of a computing machine, whereas it can be better for the implementor to have multiple SCTP Host instances taking care of different SCTP Endpoint within the same machine. In my opinion for being considered OOTB, an SCTP packet must be addressed to one of the SCTP Endpoints belonging to a specific SCTP Host. With the current description, whenever a situation requires to have separated SCTP Hosts in the same machine, a filtering mechanism is needed to avoid the hosts to mutually abort the traffic, and when the filtering mechanism is implemented the behavior is the one I wish to have in the host itself i.e. to only take care of the traffic directed towards the SCTP Endpoints defined for it. In the part 8) The receiver SHOULD respond to the sender of the OOTB packet with an ABORT. I think that SHOULD is to be replaced by MAY. Section 16 " Suggested SCTP Protocol Parameter Values" The following protocol parameters are RECOMMENDED: RTO.Initial: 1 second RTO.Min: 1 second RTO.Max: 60 seconds Max.Burst: 4 RTO.Alpha: 1/8 RTO.Beta: 1/4 Valid.Cookie.Life: 60 seconds Association.Max.Retrans: 10 attempts Path.Max.Retrans: 5 attempts (per destination address) Max.Init.Retransmits: 8 attempts HB.interval: 30 seconds HB.Max.Burst: 1 SACK.Delay: 200 milliseconds The timers used depend on the actual network, there are cases where in order to fulfil the requirements, they need to be set one order of magnitude below the values recommended. (SIGTRAN and RAN). I'd suggest not to state absolute values, but to provide a criteria for selecting those values. In the signaling networks the ratio is RTO.Max = 4 * RTO.Min RTO.Initial = 2 * RTO.Min HB.interval = 20 * RTO.Min SACK.Delay = RTO.Min / 5 Best regards, Claudio Porfiri
- [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-… Claudio Porfiri
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Marcelo Ricardo Leitner
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Michael Tuexen
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Maksim Proshin [GMAIL]
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Michael Tuexen
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Maksim Proshin [GMAIL]
- Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-… Michael Tuexen