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

[Michael Tuexen <[e-mail]>]

> On 11. Apr 2020, at 15:06, 王礼鹤 <[e-mail]> wrote:
> 
> Thank you for reply.
> 
> Will you update these two words
> > 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.
> to the RFC 6458 or Errata?
An RFC can't be changed and I can't change the Errata you submitted. All I can do
is to respond to emails. Possibly an AD can edit an Errata, I don't know.
If it is useful, I can submit an e-mail with text using the OLD TEXT/NEW TEXT way.
> 
> And 
> 
> for receiver, I agree  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 
I agree, MSG_EOR is only relevant on the receiver side, SCTP_EOR on the sender side.
> 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
Yes, for each outgoing stream you need to keep some state around.
> 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 
That is why you can negotiate the number of streams at the beginning of the association.
You can also to late allocation, but once all streams have been used you need
to have some state.And yes, you need to keep a flag if the last message was complete.
> some implement, it got a flood of SCTP_EOR message, 65535 pieces.
What happens if you turn off the SCTP_EXPLICIT_EOR mode is implementation dependent.
I haven't used it in a way that it is dynamically turned on and off, but the specification
does not disallow this. But I don't see a problem if an implementation simply would
not support it and return an error.
> 
> 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.
I don't agree here. SCTP is a reliable transport layer and the receiver should not
discard user messages with ABORTing the association.

So I agree, you have to keep state for each outgoing stream, but you have to do it
anyway. It is just one bit more for knowing if the last message was terminated.

Best regards
Michael
> 
> 
> ------------------
> 王礼鹤
> 公司/东信北邮/5G多媒体产品中心/媒体产品部
> 15210985877
> 北京市海淀区知春路9号坤讯大厦
> 此电子邮件包含来自东信北邮的信息，而且是机密的或者专用的信息，仅供标明地址的个人或团体使用。如果您收到的电子邮件存在错误，请通知本公司，删除全部原始信息（包括任何原始信息的备份），并且禁止散布或分发全部或部分原始信息。本公司不担保本电子邮件中信息的准确性、适当性或完整性，并且对此产生的任何错误或疏忽不承担任何责任。接收方应在接收电子邮件或任何附件时检查有无病毒。本公司对由于转载本电子邮件而引发病毒产生的任何损坏不承担任何责任。 爱护环境 善用纸张 打印文件 必先三思。
>  
>  
>  
> ------------------ Original ------------------
> From:  "Michael Tuexen"<[e-mail]>;
> Date:  Fri, Apr 10, 2020 05:40 AM
> To:  "RFC Errata System"<[e-mail]>;
> Cc:  "randall"<[e-mail]>; "Kacheong Poon"<[e-mail]>; "Peter Lei"<[e-mail]>; "vladislav.yasevich"<[e-mail]>; "martin.h.duke"<[e-mail]>; "magnus.westerlund"<[e-mail]>; "david.black"<[e-mail]>; "Gorry Fairhurst"<[e-mail]>; "wes"<[e-mail]>; "wanglihe"<[e-mail]>; "tsvwg"<[e-mail]>;
> Subject:  Re: [tsvwg] [Technical Errata Reported] RFC6458 (6081)
>  
> > On 9. Apr 2020, at 06:46, RFC Errata System <[e-mail]> wrote:
> > 
> > The following errata report has been submitted for RFC6458,
> > "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6081
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: wanglihe <[e-mail]>
> > 
> > Section: GLOBAL
> > 
> > Original Text
> > -------------
> > 8.1.26    must indicate that they are
> >   finished sending a particular record by including the SCTP_EOR flag.
> > 
> > but I can not find where to use SCTP_EOR flag.
> > 
> > because
> > 
> > 5.1  The msg_flags are not used when sending a message with sendmsg().
> > 
> > 3.1.4  flags:  No new flags are defined for SCTP at this level.  See
> >      Section 5 for SCTP-specific flags used in the msghdr structure.
> > 
> > 4.1.8 same with 3.1.4
> > 
> > 9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
> >      MSG_DONTROUTE).
> > 
> > 9.7   flags:  The same as sinfo_flags (see Section 5.3.2).
> > 
> > 5.3.2 sinfo_flags not mention about it  
> > 
> > Corrected Text
> > --------------
> > 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.
> > 
> > Notes
> > -----
> > 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.
> > 
> > And between  a init chunk and  a STCP_EOR,  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
> Michael
> > 
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --------------------------------------
> > RFC6458 (draft-ietf-tsvwg-sctpsocket-32)
> > --------------------------------------
> > Title               : Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
> > Publication Date    : December 2011
> > Author(s)           : R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich
> > Category            : INFORMATIONAL
> > Source              : Transport Area Working Group
> > Area                : Transport
> > Stream              : IETF
> > Verifying Party     : IESG
> > 
> 
>