Subject: socket option:SO_NODELAY and SCTP_SET_PRIMARY_ADDR

From: "ʩ" <[email-masked]>
Date: Tue, 24 Sep 2002 16:44:56 +0800 (CST)

Dear all,

    I am implementing the SCTP socket-option in linux, and most of the read/write and read-only options are finished, now i have questions about two options:

7.1.5 SO_NODELAY
    This option is to turn off any Nagle-like algorithm. Had the LKSCTP in sourceforge.net implemented the Nagle-like algorithm?
    It seems that the Nagle algorithm (RFC 896) can only impact the performance of SCTP, whether we use SCTP to transport the signaling or use PR-SCTP to transport the real-time media application. So can we set the Nagle algorithm off by default, or even ignore this option?

7.1.9 SCTP_SET_PRIMARY_ADDR
    This option requests the peer to set the association primary.
    Do we need another more chunk-type, such as SETPRIM chunk, to performance this option? For example, When setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk will be sent immediately to the peer; and when the peer receive a SETPRIM chunk, after doing some verification, it will reset its primary according to the enclosed address in the SETPRIM chunk.
    
I am not sure about this and thanks for help!

Best regards

Jinyang Shi
24/09/02

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 24 Sep 2002 07:30:10 -0500

>    It seems that the Nagle algorithm (RFC 896) can only impact the performance of SCTP, whether we use SCTP to transport the signaling or use PR-SCTP to transport the real-time media application. S…
We have not yet implemented a Nagle algorithm in our release.. and yet 
we do have this option. It currently
just tracks a flag on and off indicating that the endpoint does or does 
not want a "Nagle" like algorithm. Now
you may ask why in the world would you still want it.

a) For existing TCP app's porting to SCTP it gives them a transition 
option.. many of the
TCP apps we have put up do a "TCP_NODELAY" so this then allows us to have a
option they can hang a hook on :>

b) In the future we do plan on implementing some type of "Nagle" algo so 
we want to
have the app be able to turn it on and off...

So I would advise you to do the same even if you have not implemented it 
yet ..

>    Do we need another more chunk-type, such as SETPRIM chunk, to performance this option? For example, When setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk will be sent immediate…
I am not sure what you mean by this. We have a chunk that already takes 
care of this. It is called
a ASCONF chunk and it is in the addip draft. Please have a look at this 
draft.

R

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

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Tue, 24 Sep 2002 07:17:13 -0500

Discussion of LKSCTP (the official Linux implementation of SCTP)
belongs on [email-masked].

[email-masked] writes:
> Dear all,
> 
>     I am implementing the SCTP socket-option in linux, and most of
> the read/write and read-only options are finished, now i have
> questions about two options:
> 
> 7.1.5 SO_NODELAY
>     This option is to turn off any Nagle-like algorithm. Had the
> LKSCTP in sourceforge.net implemented the Nagle-like algorithm? 

AFAIK, Nagle remains unimplemented.

>     It seems that the Nagle algorithm (RFC 896) can only impact the
> performance of SCTP, whether we use SCTP to transport the signaling
> or use PR-SCTP to transport the real-time media application. So can
> we set the Nagle algorithm off by default, or even ignore this
> option?

Nagle is supposed to be on by default.  That is just normal sockets
semantics.

Even though Nagle is still unimplemented, there should be a flag in
the socket structure which indicates whether or not Nagle is active.
You may toggle that flag.

>     Do we need another more chunk-type, such as SETPRIM chunk, to
> performance this option? For example, When
> setsockopt(SCTP_SET_PRIMARY_ADDR) in one endpoint, a SETPRIM chunk
> will be sent immediately to the peer; and when the peer receive a
> SETPRIM chunk, after doing some verification, it will reset its
> primary according to the enclosed address in the SETPRIM chunk.

This is part of the AddIP extension.  Xingang Guo did a preliminary
implementation of AddIP quite some time ago.  It was never fully
integrated.  His implementation is available as a patch on
SourceForge, but it will no doubt take some work to integrate it with
the current code base.

Meanwhile, the following quote from the API draft applies:

    This functionality is optional. Implementations that do not support
    this functionality should return EOPNOTSUPP.

> I am not sure about this and thanks for help!

My pleasure.