Subject: [Tsvwg] Comments on draft-ietf-tsvwg-sctpsocket-00.txt

From: Mike Bartlett <[email-masked]>
Date: Fri, 15 Jun 2001 16:17:53 +0100

Dear SCTP Sockets Mapping authors,

I have taken a look at the new SCTP Sockets Mapping draft
(draft-ietf-tsvwg-sctpsocket-00.txt) and have a number of
comments/queries/suggestions.

In this email I have listed the comments that I hope to be fairly
non-controversial.  I will send further emails for the comments which I
anticipate to require more discussion - these relate to socket closure and
use of association IDs.

Best wishes

Mike Bartlett
Voice Networking Group
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8363 1039
Email: [email-masked]
Web: http://www.dataconnection.com

1. Sections 3.1.2 and 4.1.2 say that bind() specifies the local primary
address for the association.  I think this should read "the only address".
2. Section 3.1.4 should explicitly refer to the name of the graceful
shutdown flag (i.e. MSG_EOF)
3. CANT_START_ASOC should be CANT_START_ASSOC in section 3.3
4. Section 3.3 says "the sender will also recieve [should say receive] a
SCTP_SEND_FAILED event".  This and any similar phrases throughout the
document should add "... if requested with the SCTP_RECVSENDFAILEVNT socket
option".
5. In the last paragraph of section 3.3, should not refer to the SHUTDOWN
chunk.  I suggest wording along the following lines.
"In order to shutdown the association gracefully, the user must call
sendmsg() with no data and with the MSG_EOR flag set.  The function returns
immediately, and the success of the graceful shutdown is returned to
recvmsg() by an SCTP_ASSOC_CHANGE notification of type SHUTDOWN_COMPLETE
(see section 5.3.1.1)."
6. Section 4.1.5: cross-reference should be to 7.1.3 not 7.1.4 for
SCTP_INITMSG
7. Section 4.1.6: has an invalid cross-reference to the linger section.  It
should read 7.1.4 not 7.1.6.

8. Cross-reference in section 5.2: "See section 5.2.1 for more information".
Should this be section 3.1.2?

9. Two points on the MSG_ADDR_OVER flag:
a) The text for the MSG_ADDR_OVER flag in section 5.2.2 should presumably
say TCP rather than UDP, because for UDP sockets the destination address is
always critical.  Also the reference to sendto() seems incorrect because
that call does not have ancillary data.  I suggest that the text should read
as follows.
"This flag, for TCP-style sockets, requests the SCTP stack to override the
primary destination address with the address found with the sendmsg call." 
b) In section 4.1.8  I suggest that the first sentence of point 1) should be
modified to refer to the MSG_ADDR_OVER flag as follows.
"When sending, the msg_name field in the msghdr is not used to specify the
intended receiver.  However, if the MSG_ADDR_OVER flag is specified in the
flags (see section 5.2.2) then the sender uses this field to indicate a
different peer address if it does not want to send the message to the
primary address of the receiver." 
10. Section 5.2.2: for MSG_EOF please insert the text "on the specified
association" after "Setting this flag invokes the SCTP graceful shutdown
procedures".  This is analogous to the MSG_ABORT flag where this text is
specified.
11. section 5.2.2: Please state that sinfo_assoc_id is ignored for TCP-style
sockets.

12. Section 5.3.1.5: sse_type should be set to SCTP_SHUTDOWN_EVENT

13. Section 5.3.1.1 says "The identifier for the new association resides in
the sctp_notification structure in the cmsg_data ancillary data."  This is a
notification, not ancillary data.
14. Section 5.3.1.1 says of the SCTP_ASSOC_CHANGE notification: "Clients
(i.e. applications on which only active opens are made) can leave this
ancillary data item off".  This is a notification, not ancillary data.  [In
fact as I will argue in another email there is a big problem with this
method for turning off acceptance of incoming associations.]
15. Sections 6.1, 6.3 and 7 refer to "peeled off" sockets or sometimes just
"high bandwidth" sockets.  These terms are not used anywhere else.
Elsewhere sockets created using sctp_peeloff() are called "branched off"
sockets - please use this term here as well.
16. Sections 7 and 7.1.3 refer to "the datagram model" and "the
connnection-oriented model".  Please replace by references to UDP and TCP
sstyle sockets respectively.
17. Sections 7.1.7 and 7.1.8 refer to "integer boolean flag".  This should
simply say "integer" (since they are not boolean values).
18. Section 7.3: SCTP_REVCVDATAIOEVENT should read SCTP_RECVDATAIOEVENT
19. Section 7.3 is called "Ancillary Data Interest Options" and the first
sentence says "Applications can receive notifications of certain SCTP events
and per-message information as ancillary data with recvmsg()."  This section
actually talks about both ancillary data (the SCTP_SNDRCV structure) and
notifications (which are not ancillary data).  Please make this clearer.
The final sentence in this section "The format of the data structures for
each ancillary data item is given in section 5.2." is superfluous given that
each type of ancillary data or notification has been given an individual
cross-reference already.
20. Section 8.1: The flags field on sctp_bindx() is formed from the bitwise
OR of zero or more of the flags ADD and REMOVE.  Of course it only makes
sense if exactly one of these flags is specified (the combination "don't ADD
and don't REMOVE" makes no more sense than the combination "ADD and
REMOVE").  I suggest that these should not be bitwise flags.  Please can you
make them just two alternative values for the flag.
21. SCTP_BIND_ADD_ADDR and SCTP_BIND_REM_ADDR should read
SCTP_BINDX_ADD_ADDR and SCTP_BINDX_REM_ADDR in section 8.1.
22. Section 8.5.  I don't understand what your new call provides that
couldn't be achieved using setsockopt() and getsockopt().  None of the calls
is simultaneously reading and writing.  You can set peer address parameters
using setsockopt(SCTP_PEER_ADDR_PARAMS) or you can read them using
getsockopt(SCTP_PEER_ADDR_PARAMS).  You can retrieve peer address
information using getsockopt(SCTP_PEER_ADDR_INFO).  Why do we need a new
call which can both set and get the same information set using different
option identifiers?  Also the references to SCTP_SET_PRIMARY_ADDRS and
SCTP_SET_PEER_PRIMARY_ADDRS as values for opt have no corresponding section
later on.
23. The appendices both show the SCTP_RECVDATAIOEVNT socket option being
set/got twice.
24. How about the option of specifying a message lifetime on outgoing data?
(Section 5.2.2)  This would be analogous to the section 10.1 interface in
RFC 2960.
25. There are (obviously) numerous typos in the document.  The most common
by far is "assocation", "associaition", "assocication", "asssociation",
"associatin" etc.  Also "equivalant", "subsequent call will", "will
associates", "Some SCTP user", "delievered", "assoicated", "gesockopt",
"messaage", "boundries", "directtion".
26. Section 1: "Both TCP [TCP] and UDP [UDP] have benefited from this
standard representation and access method across many diverse platforms."
There are no references for "[TCP]" and "[UDP]" in section 11.

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Mon, 18 Jun 2001 07:34:08 -0500

Mike:

As Jonathan said, thanks for the detailed read. We
realize we are still honing this draft and it will
get there... one quick comments... I may
have more later :-0

> primary destination address with the address found with the sendmsg call."

For a UDP socket the destination is always critical (to find the 
association) but the normal behavior of the stack should be
that you send to the primary address. No matter what address
is used to find the association. The flag is needed to override
this behavior. In fact even thought Jonathan commented that
it was redundant in TCP, I think maybe if he thinks on it
he may agree that it is needed here too. 

I don't see that the stack should ever use addresses for anything
but locating the association in the UDP side unless this flag
is set. For the TCP flag, I would think this flag would indicate,
"ok, I now have to look at this address, since normally I ignore it
 and as long as it is valid I will override the primary with it".

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)