Subject: [rddp] SCTP mapping

From: "Williams, Jim" <[email-masked]>
Date: Fri, 28 Feb 2003 11:44:40 -0500

Regarding

   http://www.ietf.org/internet-drafts/draft-stewart-rddp-sctp-02.txt

Looks like a good, well thought out proposal.

I have a couple points.

-----

In section 3.2, I would prefer to see a bit more explicit
statement something like the following.

     DDP-enabled SCTP endpoints MAY refuse to connect
     with any remote endpoint that is multi-homed.  If a multi-homed
     DDP-enabled SCTP endpoint attemts to connect, and the connection
     is rejected with a resource error, then the connection SHOULD
     be reattempted with fewer specified IP addresses, and ultimately
     in non-multi homed mode.

My sense is that this is the intent anyway, so I am only hoping
for a bit more explicit language.

-----

In section 4, it is stated, "DDP should request the maximum
[number or streams per association] it will wish to use from SCTP."

I would encourage a cleaner layering here.  DDP should not need
to be aware that it is layered on SCTP, and should not be 
concerned with how SCTP allocates DDP streams among SCTP
associations.

I am guessing that most implementations will chose to support
one stream per association because it is simpler and I don't
see a performance down side.  However since number of streams
per association is negotiable, it is fine to allow more.

I am in favor, though, of keeping the complexity of deciding
the desired number of streams per association, and negotiating
with the remote end point the actual number supported layered
below the DDP layer.  DDP does not and should not care if two
of its streams are in the same or in different SCTP associations. 

But I don't claim to have thought this through completely,
and so am quite willing to change my mind in the face of
good arguments.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 28 Feb 2003 11:11:36 -0600

On 2/28/03, Williams, Jim wrote:

> DDP-enabled SCTP endpoints MAY refuse to connect with any
> remote endpoint that is multi-homed.  If a multi-homed
> DDP-enabled SCTP endpoint attemts to connect, and the
> connection is rejected with a resource error, then the
> connection SHOULD be reattempted with fewer specified IP
> addresses, and ultimately in non-multi homed mode.
>
>My sense is that this is the intent anyway, so I am only
>hoping for a bit more explicit language.

Allowing the remote end to be multi-homed has no impact upon
RDDP. It does have some impact on the SCTP layer. I believe
that you could argue that any SCTP endpoint MAY refuse to
connect with a multi-homed peer by returning a resource
error. However I would argue that it SHOULD NOT do so.

The difference between "MAY refuse" and "SHOULD NOT refuse"
is only one of shading though. The more germane point is
that unless there are DDP layer reasons for refusing, I do
not believe it belongs in the draft.

Note that in contrast, *local* multi-homing has *major*
impacts on rddp. The draft makes it clear that nobody is
obligated to make their RDDP/SCTP endpoint multihomed, and
in fact they SHOULD NOT do so by default if it impacts
performance. Short of designing RDDP into the motherboard
itself I do not think a multihomed RDDP/SCTP endpoint could
ever match the performance of an RNIC-specific RDDP/SCTP
endpoint.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 28 Feb 2003 11:29:53 -0600

On 2/28/03, Williams, Jim wrote:

>In section 4, it is stated, "DDP should request the
>maximum [number or streams per association] it will wish
>to use from SCTP."
>
>I would encourage a cleaner layering here.  DDP should not
>need to be aware that it is layered on SCTP, and should
>not be concerned with how SCTP allocates DDP streams among
>SCTP associations.
>

But DDP has to interface with the actual LLP. It is indeed
good design to isolate the LLP dependencies, but ultimately
whatever sub-component that does that isolation has to make
requests of the actual LLP on terms that it understands.

For SCTP the proposed mapping takes the assumption that the
SCTP layer overhead for unordered streams is almost nil.
Therefore the DDP layer should avoid making any advance
commitment that would force it to create a second
association at a future data when there was no need for it
to do so.

A second association can is also not possible for
peer-to-peer applications that pre-specifiy the port number
of both ends. In the more typical active/passive case only
the passive side port number is fixed  in advance, so
additional associations are less of a problem, but still
undesirable forthe reasons cited below.

>I am guessing that most implementations will chose to
>support one stream per association because it is simpler
>and I don't see a performance down side.  However since
>number of streams per association is negotiable, it is
>fine to allow more.

On the contrary, there are major advantages to sharing
the same association across multiple DDP streams
consolidates acking, congestion control and setup.

An integrated  RDDP/SCTP implementation SHOULD NOT presume
there is only one stream per association unless it has
very strong reasons to believe that there will only be a
single stream between the two endpoints.

There is actually little reason to do a fully integrated
RDDP/SCTP implementation. You can achieve virtually all
ofthe performance benefits by leaving them cleanly layered
but having a specialized SCTP layer that only supports
unordered delivery.

Caitlin Bestler

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 28 Feb 2003 12:04:12 -0600

>association at a future data when there was no need for it

But that makes me realize that the next revision should have
the following language added:

    DDP exclusively uses unordered Data Chunks. The SCTP 
    layer may be able to optimize the resources allocated to 
    support an SCTP stream if advised that a  stream will 
    never be used for ordered Data Chunks. If a local
    interface is available to provide such information it
    MUST be used.

Caitlin Bestler