Subject: Re: [Tsvwg] SCTP Sockets Mapping

From: Jonathan Wood <[email-masked]>
Date: Fri, 23 Mar 2001 19:10:00 -0800 (PST)

Thanks for your close reading of the draft. Many comments were regarding 
notifications. We are still in the process of nailing down exactly how 
notifications work, hence the mess.

Some replies inline:

> 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

Yes we are talking about sctp_peeloff(); the language will be clarified.

> 
> 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?

This is unclear in the draft. I believe the new flags defined in the draft 
should go in the msghdr structure.

...

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

TCP-style sockets have clean, well defined semantics for closing with close(). 
If we allowed closing with sendmsg() we would need to complicate the draft with 
new rules. For example, what state would the socket be in after the close()? 
Would it still be usable, or are you expected to do a close right after? (Note 
that I think we need to clarify these sorts of things for the UDP-style sockets 
too.)

...

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

Perhaps. However, I'm inclined to move away from the use of "path" in general 
since we are really talking about peer addresses, which may or may not 
correspond to network paths. Any other suggestions for the naming game?

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

Typo; should be sic_length etc.

> 
> 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."
> 

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.

...

> 
> 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. 
> 

Presumably if we added more flags, they would be XOR-able with REM_ADDR, so I 
don't think that would be messy. Now for ADD_ADDR, it does seem a bit redundant 
to try to abstract it by #defining it, and in the same breath mandate that it is 
always 0... So I would be OK with dropping it.

j

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Mon, 26 Mar 2001 21:25:22 -0600

Jonathan Wood <[email-masked]> writes:
> Perhaps. However, I'm inclined to move away from the use of "path"
> in general since we are really talking about peer addresses, which
> may or may not correspond to network paths. Any other suggestions
> for the naming game? 

RFC 2960 uses "peer address" pretty consistently, so
SCTP_PEER_ADDRESS_CHANGE is OK.

I'm not particularly allergic to the term "path" since a peer address
does correspond to a network path in a network which has been
engineered specifically to exploit SCTP.  SCTP_PATH_CHANGE is a little
more compact than SCTP_PEER_ADDRESS_CHANGE.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Mon, 26 Mar 2001 21:36:43 -0600

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.
>> 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?
-- 
La Monte H.P. Yarroll      Home:                [email-masked]
   If you remember nothing else:  [email-masked]         NIC Handle: LY
   GPL - "Just give source a chance."

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 27 Mar 2001 16:38:13 -0600

> more compact than SCTP_PEER_ADDRESS_CHANGE.

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Wed, 28 Mar 2001 06:02:23 -0600

> I'd say let's stay away from the use of "path". 

Bleah.  I definately conceed that one.  Very good point.  Any other
supporters for SCTP_PEER_ADDRESS_CHANGE?