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

From: Caitlin Bestler <[email-masked]>
Date: Wed, 18 Mar 2009 18:19:11 PDT

>On Wed Mar 18 13:02 , Michael Tüxen <[email-masked]> wrote:On Mar 16, 2009, at 10:42 PM, Caitlin Bestler wrote:
>
>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...

RFC 5043 (DDP/SCTP):

7.1.  Adaptation Layer Indication Restriction

   The local interface MUST allow the ULP to specify an SCTP endpoint to
   use a specific Adaptation Indication.  It MAY require the ULP to do
   so.

   Once an endpoint decides on its acceptable Adaptation Indication(s),
   it SHOULD terminate all requests to establish an association with any
   different Adaptation Indication.

   An SCTP implementation MAY choose to accept association requests for
   a given SCTP endpoint only until one association for the endpoint has
   been established.  At that point, it MAY choose to restrict all
   further associations for the same endpoint to use the same Adaptation
   Indication.

Basically, once an SCTP endpoint (one-to-many socket) is doing the DDP
Adaptation, it has many valid reasons why it does not want to support
other adaptations. Especially, if the SCTP Endpoint is actually delegated
to an iWARP RNIC.

Most iWARP/MPA/TCP RNICs let the host control establishing MPA/TCP
connections. Presumably an iWARP/SCTP RNIC would also let the host
control establishing associations. Such an RNIC would not want the host
to accept some non-iWARP associations using the same endpoint, because
it would require far more extensive collaboration between the RNIC and the
host stack than has proven feasible between TOEs and host TCP stacks.

Now the "SCTP implementation" here could be considered to be inclusive
of the packet filter (such as net filter) sitting above the stack. But in order
for any layer to reject an association with the wrong adaptation code it
needs to know that it in fact did not send an adaptation, and not that the
Adaptation event just has not shown up yet.

That could be done by bundling the information, or by having an option
to say "give me an Adaptation Event for the null Adapation when is applied.

However, that doesn't cover problem of "0,1 or 2". If the Adaptation is not
included with the Association Established event, there has to be some
sort of "End of Adaptations" bit on the *last* Adaptation Event. And if you
want that "End of Adaptations" indication, there has to be an explicit
"No Adaptation Requested" event.

What triggered this line of thought is that a patch was proposed for
the Linux stack to optimize the typical non-adapted association by
omitting the Adaptation event when there in fact was none. In the
general sense, I think that is the right approach. But we need some
mechanism to let the ULP enforce section 7.1 of RFC 5043.

---

From: Vlad Yasevich <[email-masked]>
Date: Wed, 18 Mar 2009 21:45:57 -0400

>    different Adaptation Indication.

This text is somewhat conflicting with the text in rfc 5061.  I say somewhat
is that both texts use SHOULD keyword leaving some wiggle both ways that
can be rather ugly... :)

While trying to interpret the text above, I have a question.

Suppose endpoint A implements DDP adaptation.  Suppose endpoint B implements
FOO adaptation (yet to be defined).  Should endpoint A terminate association
attempts from endpoint B?  If yes, then in effect, RFC 5043 proposes that
an endpoint is bound to a port and an Adaptation Layer, and attempts to connect
to this endpoint with any Adaptation other then the one bound would result
in a termination.  This is somewhat counter to the whole notion of:

						This parameter SHOULD
   NOT be examined by the receiving SCTP implementation and should be
   passed opaquely to the upper-layer protocol.

as specified in RFC 5061.

> to say "give me an Adaptation Event for the null Adapation when is applied.

Not necessarily.  One could defined the adaptation socket option as "write once".
Once written, it can't be changed until the endpoint is recreated.
I am not sure we want to support changeable adaption indication point.  It would
allow nasty things to happen, like 2 associations on the same socket using 2
different adaptations.

> "No Adaptation Requested" event.

Not at all.  If a full list of peer adaptations is provided, you don't need
the *last* tag.  You would get a full list at the time of establishment and
be done.

> mechanism to let the ULP enforce section 7.1 of RFC 5043.

Not quite.  The optimization was to not exchange the Adaptation Indication
parameter on the wire when it was not specified.  Once the application
actually specified the Adaptation Code Point, we'll exchange the parameter
and provide a ULP notification.

-vlad