SCTP socket options

Hi,

Please see my implementation,
Socket is created using

socket(PF_INET, SOCK_RAW, IPPROTO_SCTP)

.....

The socket option for Send buffer is set by using

setsockopt(.., SOL_SOCKET, SO_SNDBUF, (void *)&buffsend, ...)

where, buffsend = ((receiver window * No of virtual links) * 2)

Now suppose if I put receiver window size as more than 14560 and the
number of virtual links are 8, then the setsockopt() call is failing
with error ENOBUFS (SO_SNDBUFS exceeds system limit)

Can anybody guide as to whether, I can assign more buffer space for
Sendbuffer ?  If so How can I do it. If not, is there a better approach
for socket creation and setsockopt so that I can use maximum buffer
space for send buffer and receive buffer.

Thanks and best regards,
devayya

Re: WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW

On 2006-11-29, at 4:41, James M. Polk wrote:
> The WGLC for draft-ietf-tsvwg-addip-sctp-17.txt
> starts today, November 28th, 2006, and ends on or after December  
> 13th, 2006
> - depending on the level of comments to the TSVWG list at that time.

In response to LC comments, the authors have recently updated the draft:
http://tools.ietf.org/html/draft-ietf-tsvwg-addip-sctp-18

The WG should confirm that -18 is ready for publication. Please send  
final comments until March 6.

Lars

New I-D posted: draft-scharf-tsvwg-quick-start-flow-control-00.txt

Hi,

I have written a new I-D on some issues that have been noticed during
implementation efforts of the experimental Quick-Start extension (RFC
4782).

I'd be very interested in feedback. I am cross-posting both to
tsvwg and tcpm, since it might be of interest to both communities.

Michael

----- Forwarded message from Internet-Drafts <at> ietf.org -----

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Avoiding Interactions of Quick-Start TCP and Flow Control
	Author(s)	: M. Scharf, et al.
	Filename	: draft-scharf-tsvwg-quick-start-flow-control-00.txt
	Pages		: 12
	Date		: 2007-2-27
	
   This document describes methods to avoid interactions between the
   flow control of the Transmission Control Protocol (TCP) and the
   Quick-Start TCP extension.  Quick-Start is an optional TCP congestion
   control mechanism that allows hosts to determine an allowed sending
   rate from feedback of routers along the path.  With Quick-Start, data
   transfers can start with a potentially large congestion window.  In
   order to fully utilize the data rate determined by Quick-Start, the
   sending host must not be limited by the TCP flow control, i. e., the

SCTP socket options

Hi,

Please see my implementation,
Socket is created using

socket(PF_INET, SOCK_RAW, IPPROTO_SCTP)

.....

The socket option for Send buffer is set by using

setsockopt(.., SOL_SOCKET, SO_SNDBUF, (void *)&buffsend, ...)

where, buffsend = ((receiver window * No of virtual links) * 2)

Now suppose if I put receiver window size as more than 14560 and the 
number of virtual links are 8, then the setsockopt() call is failing 
with error ENOBUFS (SO_SNDBUFS exceeds system limit)

Can anybody guide as to whether, I can assign more buffer space for 
Sendbuffer ?  If so How can I do it. If not, is there a better approach 
for socket creation and setsockopt so that I can use maximum buffer 
space for send buffer and receive buffer.

Thanks and best regards,
devayya

SCTP socket options

Hi,

Please see my implementation,
Socket is created using

socket(PF_INET, SOCK_RAW, IPPROTO_SCTP)

.....

The socket option for Send buffer is set by using

setsockopt(.., SOL_SOCKET, SO_SNDBUF, (void *)&buffsend, ...)

where, buffsend = ((receiver window * No of virtual links) * 2)

Now suppose if I put receiver window size as more than 14560 and the 
number of virtual links are 8, then the setsockopt() call is failing 
with error ENOBUFS (SO_SNDBUFS exceeds system limit)

Can anybody guide as to whether, I can assign more buffer space for 
Sendbuffer ?  If so How can I do it. If not, is there a better approach 
for socket creation and setsockopt so that I can use maximum buffer 
space for send buffer and receive buffer.

Thanks and best regards,
devayya

Protocol Action: 'Authenticated Chunks for Stream Control Transmission Protocol (SCTP)' to Proposed Standard

The IESG has approved the following document:

- 'Authenticated Chunks for Stream Control Transmission Protocol (SCTP) '
   <draft-ietf-tsvwg-sctp-auth-08.txt> as a Proposed Standard

This document is the product of the Transport Area Working Group Working 
Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-08.txt

Technical Summary

This document describes a new chunk type, several parameters and
procedures for SCTP. This new chunk type can be used to authenticate SCTP
chunks by using shared keys between the sender and receiver. The new
parameters are used to establish the shared keys. Using TLS as defined in
RFC3436 (TLS over SCTP) does not help with this requirement because it
only secures SCTP user data. Therefore an SCTP extension is created by
this document which provides a mechanism for deriving shared keys for each
association. These association shared keys are derived from endpoint pair
shared keys, which are configured and might be empty, and data which is
exchanged during the SCTP association setup. The extension presented in
this document allows an SCTP sender to sign chunks using shared keys
between the sender and receiver. The receiver can then verify that the
chunks are sent from the sender and not from a malicious attacker as long
as the attacker does not know an association shared key.

Re: SCTP peer restart: MIS and MOS values

Hi Andrey,

section 2.5 of RFC 4460 states:

  Number of Outbound Streams (OS): 16 bits (unsigned integer)

       Defines the number of outbound streams the sender of this INIT  
ACK
       chunk wishes to create in this association.  The value of 0 MUST
       NOT be used, and the value MUST NOT be greater than the MIS value
       sent in the INIT chunk.

and section 2.34 of RFC 4460 says

    Section 5.3.1).  Other parameters for the endpoint SHOULD be copied
    from the existing parameters of the association (e.g., number of
    outbound streams) into the INIT ACK and cookie.

Section 2.19 of RFC 4460 says:

    After receiving the stream configuration information from the other
    side, each endpoint MUST perform the following check:  If the peer's
    MIS is less than the endpoint's OS, meaning that the peer is
    incapable of supporting all the outbound streams the endpoint wants
    to configure, the endpoint MUST use MIS outbound streams and MAY
    report any shortage to the upper layer.  The upper layer can then
    choose to abort the association if the resource shortage
    is unacceptable.

For me this means that in your case the Local EP should send an

Draft (00) Agenda for TSVWG in Prague

This is the -00 version Draft Agenda for the TSVWG meeting in Prague 
(IETF 68) from the requests I've received to date.  We're running low 
on time already (as usual), so I'll have to start making choices if I 
get too many new requests for time.

++++++++++++++++++++++++++
TSVWG Agenda for IETF 68 (Prague)
Wednesday March 21st, 2007
0900-1130  Congress III

Chair's                                                      0900-0915
       Agenda Bashing                                         (15 min)
       NOTE WELL
       Document Status and Accomplishments
       Milestones Review

Fred - An EF DSCP for Capacity-Admitted Traffic
   draft-baker-tsvwg-admitted-voice-dscp-01

Bruce - A Proposal to Incorporate ECN and PCN in MPLS
   draft-ietf-ecn-mpls-01

Francois - RSVP Proxy Approaches
   draft-ietf-tsvwg-rsvp-proxy-approaches-00.txt

Francois - RSVP Proxy Protocol
   draft-ietf-tsvwg-rsvp-proxy-proto-00.txt

Sally and Mark's - Specifying New Congestion Control Algorithms
   draft-ietf-cc-alt-00.txt

Re: comments wanted: draft-eggert-tsvwg-udp-guidelines

Lars -

I just read it, and I think it is quite nice.

My only feedback is that in Section 3.1, when the document says that 
applications
should consider implementing TFRC "or otherwise ensure that the 
application
complies with the congestion control principles", it might be worth 
mentioning
TCP-like congestion control as well.  E.g., "TFRC, TCP-like congestion 
control,
or otherwise ensure...".

(It is on my TODO list to add a modified CCID2 to DCCP that does 
TCP-style
congestion control with AIMD parameters for slowly-responding congestion
control.  A start is at
"http://www.icir.org/floyd/papers/draft-floyd-dccp-ccid2slow-00b.txt", 
but
unfortunately, I am slow at getting to things these days.)

- Sally
http://www.icir.org/floyd/

A few nits noticed in passing:

Section 3.1:
"instead of ignoring it" -> instead of ignored"

New I-D posted: draft-gunn-tsvwg-ef-admit-evaluation-00