Subject: [Tsvwg] SCTP Sockets Mapping

From: Jon Berger <[email-masked]>
Date: Wed, 21 Mar 2001 18:32:43 -0000

Randall,

Here are some comments on the latest SCTP Sockets draft.

1) Section 1
You say that a mechanism is defined to convert a UDP-style socket into a
TCP-style socket but its not clear to me what this is unless you are talking
about sctp_peeloff().  I would argue that this is not a conversion as you
end up with a different socket.  Assuming the intention is that a peeled off
socket is a TCP-style socket, it is probably worth stating this in section
8.2

2) Section 3.1.3
flags are said to be described in section 5.  However all of the flags
defined in section 5 are part of the msghdr structure at some level.  Is the
flags parameter actually used on the sendmsg/recvmsg calls or are the
xxx_flags in the msghdr structure always used instead?  Which flags take
precedence?

3) Section 3.1.3 
Section 3.1.3 and a number of other places refer to IP address where they
should be talking about Transport Address as the port is also required
information.

4) Sections 3.1.4 +  4.1.6 + 7.1.6
Socket closure.  I have a concern that with graceful socket closure, the
application can theoretically still receive data after issuing close (and
even after close completing).  This is something that should be explicitly
mentioned.

5) Section 4.1.8 
Restriction number 2 - why is closure using sendmsg() illegal on TCP style
sockets?

6) Section 5.1 
Should MSG_IS_EVENT be MSG_IS_NOTIFICATION as used later in the doc?

7) Section 5.2.2
sinfo_dscp - if this is only used on the outbound side, you should say that
it only applies to sendmsg().

8) Section 5.2.2
sinfo_assoc_id - is this required on sendmsg() and recvmsg()?  

9) Section 5.2.2
How about the option of having an expiry time on outgoing data?

10) Section 5.3
It would be nice to have a forward reference here to section 7.3 indicating
how to receive the notifications.

11) Section 5.3.1 
I think SCTP_PATH_CHANGE is clearer than SCTP_INTF_CHANGE.

12) Section 5.3.1.2 - 5.3.1.4
Should sn_length be sic_length etc. or is sn_length defined elsewhere?

13) Sections 5.3.1.X and 7.3
Section 7.3 refers to section 5.3.1 - 5.3.4 but the actual section numbers
are 5.3.1.1-5.3.1.4

14) Section 7.3
I think it would be more transparent if the naming of the ancillary data
options was closer to the actual information returned.  
e.g. SCTP_RECV_REMOTE_ERROR would return the SCTP_REMOTE_ERROR structure.

15) Section 5.3.1.1 sac_state
Given that SCTP does not support the half close semantic of TCP, is there a
need for a new event which indicates to the application that the peer has
initiated shutdown of the association.  e.g.
"QUENCH_SENDING	The peer has initiated graceful shutdown of the association.
No more data can be sent on this association but data can still be received
until a SHUTDOWN_COMPLETE or COMMUNICATION_LOST notification has been
received."

16) Sections 5.4.1 and 5.4.3
When discussing ancillary data returned in recvmsg(), 5.4.1says "Multiple
instances of other events may appear in a single call."  However 5.4.3
relies on not getting more than one of any type of notification event.  

17) Section 5.4.3
As this section applies only to the recvmsg() call, I don't see where the
reference to SCTP_INIT comes from.

18) Section 6.1
SCTP_DATAIOEVNT should be SCTP_RECVDATAIOEVNT.

19) Sections 7.1.1 and 7.1.2
Reference to "peer address parameter" should be srto_assoc_id and
sasoc_assoc_id respectively.

20) Section 7.1.4 
Reference to 3.1.1 should be to 5.2.1

21) Section 7.1.4
Setting these options on a listening socket should affect all future inbound
sockets created from that listening socket.

22) Section 7.1.5
is missing

23) Sections 7.1.9 and 7.1.10
Presumably these should be integers not integer boolean flags.

24) Section 7.3
Text in this section refers to "connectionless mode", "connection oriented"
and "datagram oriented".  It would be more consistent with the rest of the
draft to talk about TCP and UDP style sockets.

25) Section 8.1
References to SCTP_BIND_ADD_ADDR and SCTP_BIND_REM_ADDR should be
SCTP_BINDX_ADD_ADDR and SCTP_BINDX_REM_ADDR respectively.

I'm not keen on defining the flags so that ADD is 0 and REM is non zero.
These aren't really flags in my opinion and it could start to get messy if
more flags are added.  I'd prefer to lose the ADD flag and have a REMOVE
option. 

Jon

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

---

From: Jonathan Wood <[email-masked]>
Date: Fri, 30 Mar 2001 16:27:07 -0800 (PST)

>> 
>> Hmmm, then you will need to explain to people (again and again) that
>> SCTP_PATH_CHANGE has nothing to do with a route convergence in the
>> network.
>> 
>> I'd say let's stay away from the use of "path". 
>> 
>> -Qiaobing
>
>Bleah.  I definately conceed that one.  Very good point.  Any other
>supporters for SCTP_PEER_ADDRESS_CHANGE?
>

Works for me.

Jonathan

---

From: Jonathan Wood <[email-masked]>
Date: Fri, 30 Mar 2001 16:29:14 -0800 (PST)

>
>Jonathan Wood <[email-masked]> writes:
>> Some replies inline:
>> [[email-masked] wrote:]
>>> Given that SCTP does not support the half close semantic of TCP, is
>>> there a need for a new event which indicates to the application
>>> that the peer has initiated shutdown of the association.  e.g.
>>> "QUENCH_SENDING The peer has initiated graceful shutdown of the
>>> association.  No more data can be sent on this association but data
>>> can still be received until a SHUTDOWN_COMPLETE or
>>> COMMUNICATION_LOST notification has been received."
>>
>> This might be a good idea... With TCP-style sockets, you shouldn't
>> get kicked off the socket until the shutdown is complete, so as to
>> retrieve any notificaitons that may occur during the shutdown
>> process. In the mean time, you may still be sending data, and the
>> stack can only drop it or return it in a send failed event. A
>> QUENCH_SENDING event would be useful here. 
>
>There is already an errno value which sendmsg() can generate which
>covers this situation:
>
>	ESHUTDOWN	/* Cannot send after transport endpoint shutdown */
>
>Would QUENCH_SENDING not have identical semantics?

I like ESHUTDOWN ever better -- it has the same ultimate effect (letting the 
sender know that it can't send any more), and at the same time enforces this 
correct behavior.

Jonathan