[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