Michael Tüxen | 5 Feb 12:40 2009
Picon

DTLS interop server available on interop.fh-muenster.de

Dear all,

Robin and myself have setup an DTLS interop server at
interop.fh-muenster.de (195.37.125.98).

It runs an echo and discard server for DTLS/UDP and
DTLS/SCTP.

The DTLS implementation use is the one from OpenSSL with
Robins bug fixes available at
http://sctp.fh-muenster.de

If you have comments, questions, found bugs or anything else
related to the above interop testing, please send an e-mail to
seggelmann <at> fh-muenster.de or tuexen <at> fh-muenster.de.

Best regards
Michael

Caitlin Bestler | 5 Feb 15:32 2009

draft-ietf-sctpsocket-18: sinfo_context and successful sendmsg

This is a repost - the original went astray.
--------------------------------------------

In the current draft the sinfo_context is only specified to be
returned "back to the upper layer if an error occurs" [page 25].

RDMA interfaces typically have an option where transmit requests
will generate an explicit completion even if the operation completes
successfully.

When iWARP is implemented over SCTP sockets it would be useful to
have an option where the sinfo_context would be returned for a
specific SCTP message even when no error occurs. I would propose
that an additional sendmsg() flag be defined for this option.
The same completion mechanism as used for errors could be used,
just with a "no error" error code.

Internet-Drafts | 9 Feb 16:15 2009
Picon

I-D Action:draft-ietf-tsvwg-emergency-rsvp-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-10.txt
	Pages           : 37
	Date            : 2009-02-09

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments formed by either a single administrative domain or a set
of administrative domains that closely coordinate their network
policy and network design.  The mechanisms defined in this document
can be used for a session whose path spans over such a controlled
(Continue reading)

Internet-Drafts | 16 Feb 15:15 2009
Picon

I-D Action:draft-ietf-tsvwg-sctpsocket-19.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
	Author(s)       : R. Stewart, et al.
	Filename        : draft-ietf-tsvwg-sctpsocket-19.txt
	Pages           : 87
	Date            : 2009-02-16

This document describes a mapping of the Stream Control Transmission
Protocol SCTP into a sockets API.  The benefits of this mapping
include compatibility for TCP applications, access to new SCTP
features and a consolidated error and event notification scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-tsvwg-sctpsocket-19.txt): message/external-body, 70 bytes
Internet-Drafts | 18 Feb 20:15 2009
Picon

I-D Action:draft-ietf-tsvwg-emergency-rsvp-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Resource ReSerVation Protocol (RSVP) Extensions for Emergency Services
	Author(s)       : F. Le Faucheur, et al.
	Filename        : draft-ietf-tsvwg-emergency-rsvp-11.txt
	Pages           : 37
	Date            : 2009-02-18

An Emergency Telecommunications Service (ETS) requires the ability to
provide an elevated probability of session establishment to an
authorized user in times of network congestion (typically, during a
crisis).  When supported over the Internet Protocol suite, this may
be facilitated through a network layer admission control solution,
which supports prioritized access to resources (e.g., bandwidth).
These resources may be explicitly set aside for emergency services,
or they may be shared with other sessions.

This document specifies extensions to the Resource reSerVation
Protocol (RSVP) that can be used to support such an admission
priority capability at the network layer.  Note that these extensions
represent one possible solution component in satisfying ETS
requirements.  Other solution components, or other solutions, are
outside the scope of this document.

The mechanisms defined in this document are applicable to controlled
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-11.txt
(Continue reading)

Vlad Yasevich | 23 Feb 22:05 2009
Picon

EXPLICIT_EOR api

Hi All

I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
After re-rereading the spec, I realized that the text is rather sparse.

The first question that came to mind was whether this should be limited
to 1-1 sockets (as it appears to be), or should it also be available
for 1-many sockets?  If the later, the API needs to change to include
the association id.

The other thing is that we need to explain the limitation of this
option wrt. to multi-streaming.  I've had to explain to a few users
already this limitation and it considerable changed their plans.

Additionally,  since there is no signaling mechanism that lets a peer
know that this API is in use, there needs to some guidance here as well.
As it stands right now,  when the sender uses this option, the receiver
needs to reset its partial deliver point so that data gets delivered instead
of waiting to be fully reassembled, which may be a very long time.

-vlad

Randy Stewart | 24 Feb 10:37 2009
Picon

Re: EXPLICIT_EOR api


On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:

> Hi All
>
> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
> After re-rereading the spec, I realized that the text is rather  
> sparse.
>
> The first question that came to mind was whether this should be  
> limited
> to 1-1 sockets (as it appears to be), or should it also be available
> for 1-many sockets?  If the later, the API needs to change to include
> the association id.

Hmm if you get that impression it is INCORRECT. the explicit EOR mode
should work no matter if you are one-2-one or one-2-many.

If you are on a 1-2-m socket then once you do a EOR mode on
that assoc whenever you write to that one association, until
you explicitly say "EOR" you are sending to that same stream. In
fact the BSD implementation will give you an error if you try
to change the stream number. So for example I could do

socketopt(12msd, set EOR mode, assoc1);
send("msgpart1", assoc1, stream-1);
send("mspart2", assoc1, stream-1)
send("entire msg", assoc2, stream-8);
send("mspart3", assoc1, stream-1);

(Continue reading)

Vlad Yasevich | 24 Feb 14:24 2009
Picon

Re: EXPLICIT_EOR api

Randy Stewart wrote:
> 
> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
> 
>> Hi All
>>
>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>> After re-rereading the spec, I realized that the text is rather sparse.
>>
>> The first question that came to mind was whether this should be limited
>> to 1-1 sockets (as it appears to be), or should it also be available
>> for 1-many sockets?  If the later, the API needs to change to include
>> the association id.
> 
> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
> should work no matter if you are one-2-one or one-2-many.

I get this "impression" because the is no way to turn on explicit EOR on
an association.  The interface doesn't allow one to pass the association
id to the kernel.  Thus, it's really a per-socket value, meaning that every
association on a 1-many socket would use explicit EOR mode.  If we want
to offer full support for 1-many api, we need change the option api to
be able to take association id, just like most other API already specified.

> 
> If you are on a 1-2-m socket then once you do a EOR mode on
> that assoc whenever you write to that one association, until
> you explicitly say "EOR" you are sending to that same stream. In
> fact the BSD implementation will give you an error if you try
> to change the stream number. So for example I could do
(Continue reading)

Vlad Yasevich | 24 Feb 19:29 2009
Picon

Re: EXPLICIT_EOR api

Michael Tüxen wrote:
> Hi Vlad,
> 
> comments in-line.
> 
> Best regards
> Michael
> 
> On Feb 24, 2009, at 2:24 PM, Vlad Yasevich wrote:
> 
>> Randy Stewart wrote:
>>>
>>> On Feb 23, 2009, at 4:05 PM, Vlad Yasevich wrote:
>>>
>>>> Hi All
>>>>
>>>> I've recently been asked about SCTP_EXPLICIT_EOF support on linux.
>>>> After re-rereading the spec, I realized that the text is rather sparse.
>>>>
>>>> The first question that came to mind was whether this should be limited
>>>> to 1-1 sockets (as it appears to be), or should it also be available
>>>> for 1-many sockets?  If the later, the API needs to change to include
>>>> the association id.
>>>
>>> Hmm if you get that impression it is INCORRECT. the explicit EOR mode
>>> should work no matter if you are one-2-one or one-2-many.
>>
>> I get this "impression" because the is no way to turn on explicit EOR on
>> an association.  The interface doesn't allow one to pass the association
>> id to the kernel.  Thus, it's really a per-socket value, meaning that
(Continue reading)

Kacheong Poon | 25 Feb 04:33 2009
Picon

Re: EXPLICIT_EOR api

Vlad Yasevich wrote:
> Michael Tüxen wrote:
...
>> We could use
>>
>>    struct sctp_assoc_value {
>>      sctp_assoc_t assoc_id;
>>      uint32_t assoc_value;
>>    };
>>
>> instead of an int and use assoc_value to enable/disable if we want
>> to be able to control this on a per association base, which makes sense
>> for me.
>> Kacheong, what do you think?
> 
> Hi Michael
> 
> That would work.  If assoc_id is set to 0, option applies to socket
> and future associations.

This is fine.

>> Correct. We can't do this for socket options. And we can't enable
>> notifications on a per association base. Should we change that too?
> 
> Hmm..  That's an interesting question.  Is it a possible scenario where
> an application decides to change event subscription of an association after
> it's established?  I can't see a reason right now, but that doesn't mean it
> doesn't exist.

(Continue reading)


Gmane