Subject: [Tsvwg] SCTP Sockets support for Multiple Adaptation Indicators

From: Caitlin Bestler <[email-masked]>
Date: Mon, 16 Mar 2009 14:42:51 PDT

The SCTP Sockets draft seems to assume that an SCTP Socket will use at most one SCTP Adaptation.

While it would certainly not be a common deployment, I cannot find anything in the DDP/SCTP or ADD-IP
RFCs that would prevent them from being deployed concurrently for the same Association.

This brings up two major points:

+ When this happens, should it be reported as two events, or as an event with a list or set?

+ How do you differentiate between *adding* an Adaptation to a socket, and *setting* it?
   Do we want to add an extra interface to set a list? Re-interpreting current calls as "adding"
   rather than "setting" strikes me as risky even if we have very high confidence that nobody
   is currently flip-flopping a socket between ADD-IP and RDMA.

This also shows that the sockets specification needs some clarity on the relationship between
the Association Change event and the Adaptation event. 

While ADD-IP specifies that the Adaptation indication should be opaque to the SCTP layer,
I believe that it should be anything but opaque to the next immediate layer that approves
of RDMA connections (netfilter and/or the iWARP Communications Manager for Open Fabrics).
The DDP/SCTP RFC specifically allows a host to effectively bind a socket/SCTP endpoint to
the DDP Adaptation so that it can be delegated to an RDMA device that can specialize in handling
only that Adaptation.

But to do that effectively, that layer needs to expect *all* of the Adaptation Indications at the same
time as as Association Change indication. Waiting for 0 or 1 Adaptation indications is terribly
awkward code which does nothing for your latency. Waiting for 0, 1 or 2 is even harder.

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 17 Mar 2009 21:07:41 -0400

> + When this happens, should it be reported as two events, or as an event with a list or set?

Purely from a protocol perspective, since both indications would be delivered in the same
INIT - INIT_ACK exchange, it would make sense to deliver both in a single indication event
as a list.

> + How do you differentiate between *adding* an Adaptation to a socket, and *setting* it?

I think we only allow to set it (again as a list of sorts).  It makes no sense to support
adding since adaptations are instantiated before associations are established.  So, the
adaptation layer would set all of them first thing.  It might as well use 1 call to set
everything up.

>    is currently flip-flopping a socket between ADD-IP and RDMA.

Yes, and I think the current socket option may even be adapted without backward compatibility
issues.

A slightly bigger obstacle is the notification API.

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 18 Mar 2009 21:02:04 +0100

> the Association Change event and the Adaptation event.
These are two different things. You would first get an assoc change  
followed
by an adaptation layer indication.
> awkward code which does nothing for your latency. Waiting for 0, 1  
We could change the API to allow setting more than one adaptation  
layer value...
And the notification could provide all indications. But this does not  
address
any assumptions you are making about the assoc change notification...

I do not understand what you mean by bind an end-point to a adaptation  
layer indication.
The socket API allows only to bind addresses and a port...