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

Michael Tuexen <> Sun, 26 July 2020 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 078CF3A0E21 for <>; Sun, 26 Jul 2020 05:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.631
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nAvzADtKtHyC for <>; Sun, 26 Jul 2020 05:31:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CE2C3A0E1F for <>; 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 (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.\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Sun, 26 Jul 2020 14:31:45 +0200
Cc: tsvwg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [tsvwg] New Version Notification - draft-ietf-tsvwg-rfc4960-bis-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Jul 2020 12:31:56 -0000

> On 14. Jul 2020, at 10:17, Gorry Fairhurst <> 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.
> (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
> 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
> Gorry
>> On 14 Jul 2020, at 00:06, wrote:
>> A new version (-07) has been submitted for draft-ietf-tsvwg-rfc4960-bis:
>> The IETF datatracker page for this Internet-Draft is:
>> Diff from previous version:
>> Please note that it may take a couple of minutes from the time of submission
>> until the diff is available at
>> IETF Secretariat.