Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-07.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 14 July 2020 08:18 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 CCDEA3A1255 for <tsvwg@ietfa.amsl.com>; Tue, 14 Jul 2020 01:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2_OujF8a6kqA for <tsvwg@ietfa.amsl.com>; Tue, 14 Jul 2020 01:17:59 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 73EFD3A1254 for <tsvwg@ietf.org>; Tue, 14 Jul 2020 01:17:59 -0700 (PDT)
Received: from [192.168.1.74] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B53C61B00223 for <tsvwg@ietf.org>; Tue, 14 Jul 2020 09:17:55 +0100 (BST)
Content-Type: multipart/alternative; boundary=Apple-Mail-5792D7D4-A3AC-4D4B-AE34-759004D128D1
Content-Transfer-Encoding: 7bit
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Tue, 14 Jul 2020 09:17:54 +0100
Message-Id: <B3D787FC-E330-4E38-84E2-38CB2B2B77BF@erg.abdn.ac.uk>
References: <159468155386.29604.5340281663438721826@ietfa.amsl.com>
In-Reply-To: <159468155386.29604.5340281663438721826@ietfa.amsl.com>
To: tsvwg <tsvwg@ietf.org>
X-Mailer: iPad Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xvTWILsRawMfIq09Yk6CZ2kcs3k>
Subject: Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-07.txt
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, 14 Jul 2020 08:18:02 -0000

Thanks For the new revision. I have looked and the new text addresses my comments. You noted some unaddressed comments, please see response and suggestions below:

(14)

This didn't quite make sense to me:
"The Gap Ack Blocks SHOULD be
   isolated.  This means that the TSN just before each Gap Ack Block and
   the TSN just after each Gap Ack Block have not been received. By
   definition, all TSNs acknowledged by Gap Ack Blocks are greater than
   the value of the Cumulative TSN Ack."
- Please consider if you can make the SHOULD clearer and the following sentence.
MT: What do you think is not clear. The second sentence make it as clear as possible to me...
GF: I think maybe this would benefit from some rewording. I think the word ‘isolated’ has multiple ways it can be read. I am still not quite sure what was intended? Unique or not? Is this anywhere near?...

Each Gap Ack Block SHOULD identify a unique non-overlapping range that has not been received.

(17)

"  An endpoint SHOULD NOT send a DATA chunk with no user data part."
- Why not? What is the negative impact of not following this recommendation in 6.2?
MT: The problem is in the socket layer. When using a connection oriented socket
(like a 1-to-1 style socket), a receive call returning 0 means that the
peer is not sending anything anymore and not that a user message of length
0 has been received. For UDP (not connection oriented), this is not a problem.
GF: Could we say something like this then?:

" An endpoint SHOULD NOT send a DATA chunk with no user data part. (This avoids the API returning a zero-length message.)“

(19)

I wonder what the requirement really is here...
This comes after a normative requirement to use a CRC32c, but I am not clear
what action is needed in this recommendation:
"   Any hardware implementation SHOULD be done in a way that is
   verifiable by the software."
- Is this intended to somehow utilise appendix C?
MT:I guess it means that if the hardware does not tell you that the CRC is correct, you still need to be able to do a verification in software. Intel cards have this feature" for small SCTP packets: they don't report that the CRC is correct, and the software will do the computation and make the final decision. And Intel got it wrong over and over again...

GF: I see, I expect the text can be clearer, and avoid being misread as hardware verification?... How about: 

Any hardware implementation SHOULD permit alternative verification of the CRC in software.

(26)

Appendix A contains normative text. I appreciate that ECN could be optional, but I am less than happy to see normative text in an appendix. Could this be moved to the body of the specification?
Or be removed? I don't recall that ECN was really tested in interops.
The reason it was put in an Appendix was that people were not sure if it is right
approach.
If you look at https://tools.ietf.org/html/draft-stewart-tsvwg-sctpecn-05#section-4.1
you see that chunks are defined differently. However, that document was never accepted as a WG document.

MT: Right now: leaving it as it is.
GF: OK, please do discuss this within the WG, and decide one approach to accept, or remove this text to another ID. It could also be an  appropriate time to revisit a spec for SCTP with ECN as a working group topic? However, that might not be best for a .bis document, ... please think.

Gorry

> On 14 Jul 2020, at 00:06, internet-drafts@ietf.org wrote:
> 
> 
> A new version (-07) has been submitted for draft-ietf-tsvwg-rfc4960-bis:
> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc4960-bis-07.txt
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc4960-bis-07
> 
> Please note that it may take a couple of minutes from the time of submission
> until the diff is available at tools.ietf.org.
> 
> IETF Secretariat.
>