Subject: Re: Some comments on sockets extensions api draft06

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 21 May 2003 06:28:36 -0500

Dear all:

I am forwarding this offline list comment I received
from Shridhar to the list... the reason being:

1) I think all of the points are valid and need addresses
2) I need to see if anyone objects to one of the points.

see below..

Sridhar Samudrala wrote:

>Randy,
>
>I have a few minor comments on the sockets api extensions draft06.
>
>1) Sec 3.1 has a paragraph that says
>   If the server or client wishes to branch an existing association off
>   to a separate socket, it is required to call sctp_peeloff() and in
>   the parameter specifies one of the transport addresses of the
>   association. 
>I guess sctp_peeloff() takes id of an association, not a transport address.
>  
>
#1 is a comment that I have now fixed for the -07 version.. a leftover
from before the assoc-id was added.... amazing we did not find
it sooner :>

>2) The following socket options are read/write and can be used with both 
>getsockopt() and setsockopt() 
>	SCTP_SET_PRIMARY_ADDR
>	SCTP_SET_PEER_PRIMARY_ADDR
>	SCTP_SET_PEER_ADDR_PARAMS
>	SCTP_SET_EVENTS
>So i think it is a little confusing to have SET in their names. May be they
>should be changed to
>	SCTP_PRIMARY_ADDR 
>	SCTP_PEER_PRIMARY_ADDR
>	SCTP_PEER_ADDR_PARAMS
>	SCTP_EVENTS
>  
>
#2 requires comments from others... I think it is the RIGHT THING
to do.. however do any of you strongly object?

It is a bit of a change here and there.. but, as Jon Grimm said, one
can always add a

#define xxx_set_xxx   xxx_xxx

to help with this.. Any objections to this change?

>3) In Sec 8.7, the new sctp_sendmsg() api should include 2 other args to
>pass the address of the peer and length of the address as follows. 
>       void sctp_sendmsg(int s, const void *msg, size_t len, 
>			 struct sockaddr *to, socklen_t tolen,
>                         uint32_t ppid,
>                         uint32_t flags,
>                         uint16_t stream_no,
>                         uint32_t timetolive,
>                         uint32_t context)
>  
>
This was an over-sight on my part and I will get tolen (and to) added
to the document for -07

>4) I feel that the use of the terms: notification end event is not consistent.
>There are multiple references to SCTP_ASSOC_CHANGE as an event and a few places
>where SCTP_COMM_UP is referred as a notification.
>As per my understanding,
>	SCTP_ASSOC_CHANGE
>	SCTP_PEER_ADDR_CHANGE
>	SCTP_REMOTE_ERROR
>	SCTP_SEND_FAILED
>	SCTP_SHUTDOWN_EVENT
>	SCTP_ADAPTATION_INDICATION
>	SCTP_PARTIAL_DELIVERY_EVENT
>are all notifications. Each notification can communicate a set of events. So
>SCTP_ASSOC_CHANGE notification can communicate the following events
>	SCTP_COMM_UP
>	SCTP_COMM_LOST
>	SCTP_RESTART
>	SCTP_SHUTDOWN_COMP
>	SCTP_CANT_STR_ASSOC
>
The above I too have noticed.. and I will address this in -07 to
attempt to make the terminology more consistent :>

Please comment on #2 above... If I get no major objections I will
go ahead and make the changes..

R

>If you think that this makes sense, i can make the appropriate changes and
>send a diff to you.
>
>Thanks
>Sridhar
>
>
>  
>

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 22 May 2003 17:05:32 +0200

I agree with the changes.

Best regards
Michael

On Wednesday, May 21, 2003, at 13:28 Europe/Berlin, Randall Stewart 
(cisco) wrote:

>>   association. I guess sctp_peeloff() takes id of an association, not 
>> a transport address.
>>
>> 2) The following socket options are read/write and can be used with 
>> both getsockopt() and setsockopt() 	SCTP_SET_PRIMARY_ADDR
>> 	SCTP_PRIMARY_ADDR 	SCTP_PEER_PRIMARY_ADDR
>> 	SCTP_PEER_ADDR_PARAMS
>> 	SCTP_EVENTS
>>
>>    void sctp_sendmsg(int s, const void *msg, size_t len, 			 struct 
>> sockaddr *to, socklen_t tolen,
>>                         uint32_t ppid,
>>                         uint32_t flags,
>>                         uint16_t stream_no,
>>                         uint32_t timetolive,
>>                         uint32_t context)
>>

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 23 May 2003 14:23:22 -0500

Michael/All:

I just noticed another little bobble.. as I am attempting to fix this in
the xml..

We apparently had
SCTP_SET_PEER_PRIMARY_ADDR defined to set the local primary
address.. and
SCTP_SET_PRIMARY_ADDR to request the peer set its primary.. aka
send an ASCONF.

This seems backwards to me.. and I think it should be

SCTP_PRIMARY_ADDR - sets/gets the primary that the local endpoint is using
SCTP_SET_PEER_PRIMARY_ADDR - send the asconf.. note you can NOT do a GET
                                                                     of 
this.. since you can't tell what the peers prim is :-)

R

Michael Tüxen wrote:

>>>   association. I guess sctp_peeloff() takes id of an association, 
>>> not a transport address.
>>>
>>> pass the address of the peer and length of the address as 
>>> follows.       void sctp_sendmsg(int s, const void *msg, size_t 
>>> len,              struct sockaddr *to, socklen_t tolen,
>>>                         uint32_t ppid,
>>>                         uint32_t flags,
>>>                         uint16_t stream_no,
>>>                         uint32_t timetolive,
>>>                         uint32_t context)
>>>

---

From: Sridhar Samudrala <[email-masked]>
Date: Fri, 23 May 2003 16:06:04 -0700 (PDT)

> this.. since you can't tell what the peers prim is :-)

I agree that this is a better interpretation. Along with this change, i hope 
you are going to update the corresponding data structures.

Also looks like i missed another socket option SET_DEFAULT_SEND_PARAM which
should be SCTP_DEFAULT_SEND_PARAM.

I am not sure about SCTP_SET_ADAPTION_LAYER. Is this a read/write option? 

Thanks
Sridhar

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 23 May 2003 18:47:55 -0500

Randy,

This is a hard one for naming things and either way there seems to be a
degree of confusion... but I think your suggestion is less confusing.

-Qiaobing

---

From: Peter Lei <[email-masked]>
Date: Fri, 23 May 2003 20:28:54 -0500

I agree, this is a bit less confusing... :)