Subject: [Tsvwg] Comments on 'Sockets API Extensions for SCTP' draft

From: Mike Bartlett <[email-masked]>
Date: Mon, 6 Aug 2001 11:15:18 +0100

Dear authors,

> I've read the new "Sockets API Extensions for SCTP" draft
> <draft-ietf-tsvwg-sctpsocket-01.txt>.  Thanks for incorporating my
> comments on the previous version.  I have a few further comments on the
> new version, of which item (1) is the only one on which I anticipate any
> debate.
> 
> 1. In my original posting on 18th June which started the discussion of
> closure of TCP-style SCTP sockets, I suggested that SCTP association
> shutdown should be decoupled from socket closure in *both* graceful
> shutdown and non-graceful shutdown (abort) cases.  Among the discussion
> that ensued there was some suggestion that the ability for an application
> to abort and then retrieve undelivered data was not needed.  I am not an
> M2PA expert by any means, but my reading of the latest M2PA draft (version
> 3) suggests that SCTP still requires this function.  Please can we agree
> whether this function is needed (to allow an application to *abort* a
> TCP-style association separately from closing the socket), and of course
> document this clearly here.  
> 
> Because of the confusing placing of the paragraph on SO_LINGER at the end
> of the section (4.1.7) on shutdown(), rather than at the end of the
> previous section (on close()), I am not even certain of whether the
> Sockets API Extensions draft intends to support this function, but my
> guess is not, given that section 7.1.4 has not been changed.
> 
> 2. Assuming that SO_LINGER still applies to close(), possibly as well as
> shutdown(), I suggest the following rewrite of section 4.1.6 - this
> rewrite encompasses several points unrelated to item (1) above.
> 
> "Applications use close() to close down listening sockets, and sockets on
> which the association has ended.  
> 
> They may also use a call to close() to shutdown both a socket and an
> active association on the socket at the same time.  In this case they will
> not receive back any undelivered user data as send failure notifications,
> nor any user data that the remote endpoint may need to send during a
> graceful shutdown.  The application should call shutdown() before calling
> close() in order to receive these items - see section 4.1.7.
> 
> The syntax is:
> 
> int close (int sd);
> sd - the socket descriptor of the association to be closed. 
> After an application calls close() on a socket descriptor, no further
> socket operations will succeed on that descriptor. 
> To perform the ABORT operation described in [SCTP] section 10.1, an
> application can use the socket option SO_LINGER. It is described in
> section 7.1.4."
> 3. Section 4.1.7 should point out that the shutdown() call allows the
> application to receive data sent by the remote endpoint while the socket
> is still open (as well as data retrieval).  It should also make it clear
> whether the "immediate and full" protocol shutdown which SHUT_WR initiates
> is always a graceful shutdown - see item (1).
> 4. Point (2) in section 4.1.8 should refer to shutdown() as well as
> close().
> 5. The reference to sendto() for the MSG_ADDR_OVER flag seems incorrect
> because that call does not have ancillary data.
> 6. Sections 3.1.2, 4.1.2, 4.1.9, 4.1.10, etc should make it clear that the
> "addr" parameter is a TRANSPORT address - i.e. an IP address and a port-
> while the sentences about IPV4 versus IPV6 obviously apply only to the IP
> address part.  This adds clarification to the reference to SCTP choosing
> the local port in section 4.1.9.
> 7. Typos:
> conntionless in section 1, point (2)
> exisitng in section 1, point (3)
> "data, and, header" in section 5.2
> notificaion in section 5.3.1.1
> send*() in section 5.3.1.4
> it's should be its in section 7.3
> funtion in section 8
> 
> Best wishes
> 
> Mike Bartlett

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

---

From: Jonathan Wood <[email-masked]>
Date: Fri, 17 Aug 2001 12:39:27 -0700 (PDT)

> > guess is not, given that section 7.1.4 has not been changed.

Your guess is correct - abort without closing functionality is not
supported. The (very rough) consensus on the mailing list seemed
to me at least to be that this functionality was neither needed
not desired.

> > application can use the socket option SO_LINGER. It is described in

OK, will clarify. Thanks for the suggested text.

> > because that call does not have ancillary data.

OK.

> > the local port in section 4.1.9.

I thought that the type (struct sockaddr *) would make this clear,
but adding "transport address" in here and there wouldn't hurt...

Also remember that IPv4 vs. IPv6 actually does apply to more than
just the IP address part, since the actual structure will either be
a sockaddr_in or a sockaddr_in6.

> > it's should be its in section 7.3

Thanks and regards,

Jonathan