Re: [tsvwg] SCTP question

<philip.eardley@bt.com> Mon, 05 November 2018 17:33 UTC

Return-Path: <philip.eardley@bt.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 4D056130E57 for <tsvwg@ietfa.amsl.com>; Mon, 5 Nov 2018 09:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.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 EzJHlOpalbuJ for <tsvwg@ietfa.amsl.com>; Mon, 5 Nov 2018 09:32:59 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7829130E46 for <tsvwg@ietf.org>; Mon, 5 Nov 2018 09:32:58 -0800 (PST)
Received: from tpw09926dag13h.domain1.systemhost.net (10.9.212.37) by RDW083A011ED67.bt.com (10.187.98.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 17:34:09 +0000
Received: from tpw09926dag15g.domain1.systemhost.net (10.9.212.31) by tpw09926dag13h.domain1.systemhost.net (10.9.212.37) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 5 Nov 2018 17:32:53 +0000
Received: from RDW083A012ED68.bt.com (10.187.98.38) by tpw09926dag15g.domain1.systemhost.net (10.9.212.31) with Microsoft SMTP Server (TLS) id 15.0.1293.2 via Frontend Transport; Mon, 5 Nov 2018 17:32:53 +0000
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (23.103.134.177) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 5 Nov 2018 17:31:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UMqLAVvozODaNqrsLs1g4w/iUoqaN2qgjmksBtgqVHw=; b=7HntcHH09cgR9WbdNtN3BzTKqY7rn4uG+kLvimRouVjcOELD6/DZKUHtQc/jhpLrKVDgzi1DqVsMNCt16pspTjgTAFmVPWfyAg7spjKtiHdVkXaZMrYJavwHFxOFR4V8W0hBOmyA/Qgz2M/Enu0+p5jFO/TQ8KtWZmCQZ1MQDsw=
Received: from LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM (10.166.250.17) by LOXP123MB1270.GBRP123.PROD.OUTLOOK.COM (10.166.254.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.25; Mon, 5 Nov 2018 17:32:52 +0000
Received: from LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM ([fe80::fc79:166b:7904:a543]) by LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM ([fe80::fc79:166b:7904:a543%4]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 17:32:52 +0000
From: philip.eardley@bt.com
To: michael.tuexen@lurchi.franken.de
CC: mproshin@mera.ru, nhorman@tuxdriver.com, perry.wilks@bt.com, tsvwg@ietf.org, draft-ietf-tsvwg-2960bis@ietf.org
Thread-Topic: [tsvwg] SCTP question
Thread-Index: AdRlXIaYnYmti2juQ3WjfuYSa9RVhgAGjlEAAB9IegAA/l8BgAAWOWGAArl7x1A=
Date: Mon, 05 Nov 2018 17:32:51 +0000
Message-ID: <LOXP123MB08052E6E1704B9E354BF5561EBCA0@LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM>
References: <LOXP123MB08050FABE8A17B6BF1F7E64EEBFE0@LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM> <20181016173620.GB20870@hmswarspite.think-freely.org> <5e9e468a035341cea28066c14fddcc26@mera.ru> <LOXP123MB080505C9DDEC754008CEC070EBF40@LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM> <F0B8D93E-699D-4C69-BC2C-6A338FABBA93@lurchi.franken.de>
In-Reply-To: <F0B8D93E-699D-4C69-BC2C-6A338FABBA93@lurchi.franken.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=philip.eardley@bt.com;
x-originating-ip: [193.113.37.9]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LOXP123MB1270; 6:4hx9yY0pCmNTfo0IrS10mVce5kFeUIEDFSb4Nmx8nO0ssdlfiyXxZu/mgxRCmoCMxhusNAOPrbAcPja7oA+IHX+IhInna1oNDB0R7nceQRf8jEPb2TXiq0cZ88Zs1P0KVdnUdBBtORbj9+nNqCOR8HLFVxDJ++BBFaPKBsiOvelk+RCB+wsEYHwK1rWbjCmGrhgkdb/6x3oWURu9aMv3P7MdmgXDgJRbsza8hMtZCNY8ZkzrgleKLzWVY4VrIAkLQpcE9DzkmReBBeILFy76fc+Wdd5ZNegoTse7J8ehlp79qax6o/rj1OZpklOxm4a3rIoVPUMTX/UtgbQWmYBqbtfxfwu8I1YUKGMZuorP4j9tADDIhIcTpZrSCp8ShIm4k9QU4Bi5O/xQQdlwGPZcLs5hCzNQZro7RGA19L9igi2J9EohPBplysPWUNijMNnfd1LNhpUoJxB49lcNwruYbQ==; 5:/fLctUHTcCBkOsvoqSzirLtcydhmbF0a0u8CdB6XPBe1v7bklGbLc9nZjyTsMYERbIjinZ+EbCPfCzU+lciZN86N7zRCgKKwV+TA7LYnA+A19Em/Wf85DTTHdH5GOPUZw80w/3uAjaXOow2f79B4eOG4nTZnjv/aaPS4fgiI5TU=; 7:97OCljkJ5SSnz+G1OlwMt67Wr2vpmZssSJ1kKqtWPfHw6hPp2hPXReh95k0DGLtc10dinuTMUmiT7CtZ0xui2ygxD8i0VVDZHcEyHzgq6l5JdjWSzf9MY9zlCobbBBjLimSa4WNIphQMO3DHltwGPA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: 24a6938a-4896-4291-52ad-08d64344b6b6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB1270;
x-ms-traffictypediagnostic: LOXP123MB1270:
x-antispam-2: 1
x-microsoft-antispam-prvs: <LOXP123MB1270F3741B37533A6665951FEBCA0@LOXP123MB1270.GBRP123.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(146908506813832)(166708455590820)(175275609761927);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:LOXP123MB1270; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB1270;
x-forefront-prvs: 08476BC6EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(39860400002)(396003)(189003)(199004)(51444003)(13464003)(7736002)(6246003)(76176011)(6436002)(446003)(305945005)(2900100001)(99286004)(86362001)(66066001)(6306002)(9686003)(6506007)(71200400001)(186003)(71190400001)(4326008)(55016002)(486006)(316002)(53546011)(106356001)(6116002)(11346002)(53936002)(102836004)(93886005)(7696005)(68736007)(25786009)(54906003)(81166006)(81156014)(5660300001)(3846002)(8936002)(105586002)(6916009)(26005)(229853002)(478600001)(8676002)(33656002)(4477795004)(256004)(14454004)(2906002)(966005)(476003)(74316002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:LOXP123MB1270; H:LOXP123MB0805.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: y9inzYRRTIeuAZ+PAg/T0YJxtdTSIDk1MnAkQ8Y4ZGLV4c/Xod9fwddt4o3K7tUT7kUuhIl84VMsTkXfuXvkj7AK12XSiDYS4uTZwnPt5Lq/uH7fZTC2o23/zDa0ZyV67bJoQR+7oqnbU3AU/OtmOIqb/X60knVBibX/d6H/SE+AqWJqh9qA8o+SLh05aAFMxVCPkyTNGeW8n1MSjj2cXy1a7+rmET3cfWj9cvckkaqcfVDHojxmoRVH7YVwEXTpe0/Uh0lH02TT8tCiS+n5rg2Z5tOkWTErx++0Zh8O0QVhY6UDe+14AbrVpHfjdN+WyKFVBiBTH2vr4WjuHHQLHgFYhA6WyPGhu6CvOSHbRNA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 24a6938a-4896-4291-52ad-08d64344b6b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 17:32:52.0421 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB1270
X-OriginatorOrg: bt.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/oaUriwB3DHa2X0EUouMKoZjSRfY>
Subject: Re: [tsvwg] SCTP question
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: Mon, 05 Nov 2018 17:33:07 -0000

Michael, all,

What do you think is the best way of progressing with this? I noticed that draft-ietf-tsvwg-rfc4960-errata has just been approved by IESG - I guess the plan is now to work on the actual rfc4960bis, so it could be incorporated there? (don't think I-D has been started?)  Is it best if we actually submit an Errata?

Perry W is also very interested to know whether he interprets the implications of this correctly:-

<< Our understanding is (assuming that the 'shall' in the note should be uppercase) that the rules as for the DATA CHUNK are followed.
This means that there is a separate timer for each destination IP address.  The changeover to try a different IP address only takes place after X retransmissions to the same IP address. When X is reached a transmission to an alternative IP address is made.
Is our understanding correct?
>>

I'm not sure whether this worthwhile discussing during the WG meeting on wed - the agenda looks quite tight (and neither Michael, Perry nor I are in Bangkok, I think)

Thanks
phil
-----Original Message-----
From: Michael Tuexen [mailto:michael.tuexen@lurchi.franken.de] 
Sent: 22 October 2018 21:32
To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
Cc: Proshin, Maksim <mproshin@mera.ru>; nhorman@tuxdriver.com; Wilks,PB,Perry,TLB35 R <perry.wilks@bt.com>; tsvwg@ietf.org; draft-ietf-tsvwg-2960bis@ietf.org
Subject: Re: [tsvwg] SCTP question

> On 22. Oct 2018, at 12:01, philip.eardley@bt.com wrote:
> 
> Do other people agree?- especially Randall, as editor of RFC4960, and other people who've been involved a lot with SCTP?
I agree with the other people... I interpret it as a SHALL.

When doing conformance testing (which I do once in a while), I expect the INITs and COOKIE-ECHOs to be retransmitted based on the timer rules (Start with RTO.Initial, double until reaching RTO.Max). If the peer is multihomed and this is configured, one has to consider if the multiple address are used for retransmitting the INITs and COOKIE-ECHOs.

I know that the use of shall sometimes causes confusion and we will likely resolve this when working on RFC 4960bis.

You can forward my address to your colleague in case he has further questions. I wrote two implementations of the ETSI conformance test suite for SCTP:
* https://github.com/nplab/ETSI-SCTP-Conformance-Testsuite
  This is based on an extended version of packetdrill and can be used to test socket based
  implementations like the FreeBSD or Linux kernel implementation. Working on Solaris support.
* https://github.com/nplab/sctp-tests
  This can be used for blackbox testing and is based on the SCTP Test Tool stt.

Best regards
Michael
> Thanks
> phil
> 
> 
> -----Original Message-----
> From: Proshin, Maksim [mailto:mproshin@mera.ru]
> Sent: 17 October 2018 09:32
> To: Neil Horman <nhorman@tuxdriver.com>; Eardley,PL,Philip,TUD1 R 
> <philip.eardley@bt.com>
> Cc: Wilks,PB,Perry,TLB35 R <perry.wilks@bt.com>; tsvwg@ietf.org
> Subject: RE: [tsvwg] SCTP question
> 
> Hi Neil,
> 
> In general it's not correct to say that "shall" is the same as SHALL. Thus RFC 8174 explains that "only UPPERCASE usage of the key words have the defined special meanings".
> Saying this anyway I think that RFC 4960 actually means SHALL/MUST in that note.  
> 
> BR, Maxim
> 
> 
> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Neil Horman
> Sent: Tuesday, October 16, 2018 20:36
> To: philip.eardley@bt.com
> Cc: perry.wilks@bt.com; tsvwg@ietf.org
> Subject: Re: [tsvwg] SCTP question
> 
> On Tue, Oct 16, 2018 at 02:42:05PM +0000, philip.eardley@bt.com wrote:
>> A colleague of mine, Perry, has a couple of questions about SCTP RFC4960. He's in the BT design team on Signalling protocols and concerned about conformance testing amongst other issues.
>> 
>> The statement is on page 57 of RFC4960  (section on Association initialisation) "Note: T1-init timer and T1-cookie timer shall follow the same rules given in Section 6.3."
>> The question is: how should the "shall" be interpreted in this sentence? Does it mean that the S6.3 rules MUST be followed? Or does it mean that the S6.3 rules are optional - in which case, are there any thoughts about rules other than those in S6.3?
>> 
> The conventions section indicates that they keyword SHALL is goverened 
> by RFC2119, which asserts SHALL is synonomous with the keywork MUST.  
> That is to say that the phrase above on page 57 of RFC4960 is an 
> absolute requirement.  You have to have the T1-init and T1-cookie 
> timer follow the same rules given in Section 6.3
> 
> Neil
> 
>> Thanks,
>> Best wishes,
>> Philip Eardley
>> Research and Innovation
>> This email contains BT information, which may be privileged or confidential.. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
>> We monitor our email system, and may record your emails.
>> British Telecommunications plc
>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
>> England no: 1800000
>> 
>