Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)

王礼鹤 <> Sat, 11 April 2020 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 679823A11E9 for <>; Sat, 11 Apr 2020 06:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q153Y0I1stUZ for <>; Sat, 11 Apr 2020 06:08:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 445093A11E7 for <>; Sat, 11 Apr 2020 06:08:21 -0700 (PDT)
X-QQ-GoodBg: 2
X-QQ-SSF: 00400000000000F0
X-QQ-FEAT: VqXHZHhIyRxvbssd9wuL+2brDze4L2wPXg6LDULCxiz3Z/qiUeelECA7nai2y o4wVCj5KO/jmD3NyX0Zj9c4MADwALXY1MFWwR+HSYb+TBPk1rqHovFIuEdkVWNvfJVlRteE PM/fCVvuiy8/wdGdC2YpQ5Sp8kD1ib3ZDW/HvXSjYeZBAVSF8uu5r1S+RGX81w9ZAfWEo0K 41ou8BULU36HKHxt/R981QwQZFUdRvWfdWivrXtaEC0FVx0sL6OrpeV9cTJW6UYHt8fturi urpGu6wB/tFH3PRD+QpPHjP729aXGffaQ2k6WGOn5F0JEhuvvhzlngxBqZncdWOCsjnjdG/ h2a9dd6KwTsE08JlMoi2SIJqx326n+W9zi586FkmiDzae3KM7w=
X-QQ-mid: logic517t1586610392t3809315
From: 王礼鹤 <>
To: Michael Tuexen <>
Cc: randall <>, Kacheong Poon <>, Peter Lei <>, "vladislav.yasevich" <>, "martin.h.duke" <>, "magnus.westerlund" <>, "" <>, Gorry Fairhurst <>, wes <>, tsvwg <>, RFC Errata System <>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5E91C0D8_0F85A010_53FC1604"
Content-Transfer-Encoding: 8bit
Date: Sat, 11 Apr 2020 21:06:32 +0800
X-Priority: 3
Message-ID: <>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
References: <> <>
In-Reply-To: <>
X-QQ-ReplyHash: 148922001
Received: from (unknown []) by (ESMTP) with SMTP id ; Sat, 11 Apr 2020 21:06:34 +0800 (CST)
Archived-At: <>
X-Mailman-Approved-At: Sun, 12 Apr 2020 14:27:27 -0700
Subject: Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
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: Sat, 11 Apr 2020 13:13:12 -0000

Thank you for reply.

Will you update these two words
&gt; It can be used in the snd_flags field of the sctp_sndinfo structure.
&gt; It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure.
to the RFC 6458 or Errata?


for receiver, I agree&nbsp; that MSG_EOR is enough to detect a whole message in a 
stream, but for sender(SCTP_EOR is only for sender) it is more complex. If user 
space decide which is EOR and kernel space decide which is INIT, every stream 
must record the stream status. When kernel get a EOR, it must be set to INIT after
send packet. Think about this, at worst, kernel have to record 65535 streams, it 
is lots of memory. And at a speical time, change SCTP_EXPLICIT_EOR status, for 
some implement, it got a flood of SCTP_EOR message, 65535 pieces.

So, for sender, I think it should all decide by userspace, INIT or EOR, then 
kernel will have clean code, just like send fragments. While if got INIT error, 
receiver can simply drop a non-INIT chunk when buffer is empty, or drop buffer 
when get a INIT chunk, very easy.






此电子邮件包含来自东信北邮的信息,而且是机密的或者专用的信息,仅供标明地址的个人或团体使用。如果您收到的电子邮件存在错误,请通知本公司,删除全部原始信息(包括任何原始信息的备份),并且禁止散布或分发全部或部分原始信息。本公司不担保本电子邮件中信息的准确性、适当性或完整性,并且对此产生的任何错误或疏忽不承担任何责任。接收方应在接收电子邮件或任何附件时检查有无病毒。本公司对由于转载本电子邮件而引发病毒产生的任何损坏不承担任何责任。  爱护环境 善用纸张 打印文件 必先三思。

From: &nbsp;"Michael Tuexen"<;;
Date: &nbsp;Fri, Apr 10, 2020 05:40 AM
To: &nbsp;"RFC Errata System"<;; 
Cc: &nbsp;"randall"<;; "Kacheong Poon"<;; "Peter Lei"<;; "vladislav.yasevich"<;; "martin.h.duke"<;; "magnus.westerlund"<;; ""<;; "Gorry Fairhurst"<;; "wes"<;; "wanglihe"<;; "tsvwg"<;; 
Subject: &nbsp;Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)


&gt; On 9. Apr 2020, at 06:46, RFC Errata System <; wrote:
&gt; The following errata report has been submitted for RFC6458,
&gt; "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)".
&gt; --------------------------------------
&gt; You may review the report below and at:
&gt; --------------------------------------
&gt; Type: Technical
&gt; Reported by: wanglihe <;
&gt; Section: GLOBAL
&gt; Original Text
&gt; -------------
&gt; 8.1.26&nbsp;&nbsp;&nbsp; must indicate that they are
&gt;&nbsp;&nbsp; finished sending a particular record by including the SCTP_EOR flag.
&gt; but I can not find where to use SCTP_EOR flag.
&gt; because
&gt; 5.1&nbsp; The msg_flags are not used when sending a message with sendmsg().
&gt; 3.1.4&nbsp; flags:&nbsp; No new flags are defined for SCTP at this level.&nbsp; See
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 5 for SCTP-specific flags used in the msghdr structure.
&gt; 4.1.8 same with 3.1.4
&gt; 9.10, 9.12&nbsp;&nbsp;&nbsp; flags:&nbsp; The same flags as used by the sendmsg() call flags (e.g.,
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MSG_DONTROUTE).
&gt; 9.7&nbsp;&nbsp; flags:&nbsp; The same as sinfo_flags (see Section 5.3.2).
&gt; 5.3.2 sinfo_flags not mention about it&nbsp; 
&gt; Corrected Text
&gt; --------------
&gt; maybe msg_flags should be used.
I agree, that text describing where to use the SCTP_EOR flag is missing.

It can be used in the snd_flags field of the sctp_sndinfo structure.
It can also be used in the sinfo_flags field of the sctp_sndrcvinfo structure,
which is deprecated.
&gt; Notes
&gt; -----
&gt; Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.
I don't think this is needed, since if you know when a message ends, the next userdata on the same
stream with the same ordering property is the beginning.
&gt; And between&nbsp; a init chunk and&nbsp; a STCP_EOR,&nbsp; if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
What happens if you are have not completed to provide a complete message and you turn off SCTP_EXPLICIT_EOR
is not specified. An implementation could fail the disabling of SCTP_EXPLICIT_EOR, but I don't think the
BSD stack does this. I guess (not tested) it will terminate the current message with the next send call.

Best regards
&gt; Instructions:
&gt; -------------
&gt; This erratum is currently posted as "Reported". If necessary, please
&gt; use "Reply All" to discuss whether it should be verified or
&gt; rejected. When a decision is reached, the verifying party&nbsp; 
&gt; can log in to change the status and edit the report, if necessary. 
&gt; --------------------------------------
&gt; RFC6458 (draft-ietf-tsvwg-sctpsocket-32)
&gt; --------------------------------------
&gt; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
&gt; Publication Date&nbsp;&nbsp;&nbsp; : December 2011
&gt; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich
&gt; Category&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : INFORMATIONAL
&gt; Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Transport Area Working Group
&gt; Area&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Transport
&gt; Stream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IETF
&gt; Verifying Party&nbsp;&nbsp;&nbsp;&nbsp; : IESG