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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 26 July 2020 12:31 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.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 078CF3A0E21 for <tsvwg@ietfa.amsl.com>; Sun, 26 Jul 2020 05:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level:
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_NONE=0.001, 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 nAvzADtKtHyC for <tsvwg@ietfa.amsl.com>; Sun, 26 Jul 2020 05:31:53 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE2C3A0E1F for <tsvwg@ietf.org>; Sun, 26 Jul 2020 05:31:52 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:789f:e52a:4f1d:f41d] (unknown [IPv6:2a02:8109:1140:c3d:789f:e52a:4f1d:f41d]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id CAF477220B806; Sun, 26 Jul 2020 14:31:47 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <B3D787FC-E330-4E38-84E2-38CB2B2B77BF@erg.abdn.ac.uk>
Date: Sun, 26 Jul 2020 14:31:45 +0200
Cc: tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5927D5EB-A26E-42BA-A5F4-F2E3ACF78629@lurchi.franken.de>
References: <159468155386.29604.5340281663438721826@ietfa.amsl.com> <B3D787FC-E330-4E38-84E2-38CB2B2B77BF@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/j5JYIQcHVSGptOvkZALNYCjWf0I>
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: Sun, 26 Jul 2020 12:31:56 -0000

> On 14. Jul 2020, at 10:17, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> 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 
The word is stolen from RFC 2018 (TCP SACK), which says:
Each block represents received bytes of data that are contiguous and isolated;
> 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.
I guess you mean:

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

That would allow [2-3],[3-4]. The intention is to disallow that. 4 has been received, therefore
[2-3] is not allowed, 2 has been received, therefore [3-4] is not allowed.

Would using

The Gap Ack Blocks SHOULD be isolated.  Isolated means ...

help you?
> 
> (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.)“
Now using:

<t>An endpoint SHOULD NOT send a DATA chunk with no user data part.
This avoids the need to be able to return a zero-length user
message in the API, especially in the socket API as specified in
<xref target='RFC6458'/> for details.</t>

> 
> (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.
Taken.
> 
> (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.
OK. Will bring it up at the presentation.

Best regards
Michael
> 
> 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.
>>