Subject: RE: [rddp] SCTP mapping - Multiple Streams

From: "Williams, Jim" <[email-masked]>
Date: Mon, 3 Mar 2003 14:40:40 -0500

> >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.

The down side for the implementation is that two contexts
(stream and association) must be accessed for each
packet sent and received rather than one combined context.
This is a factor of two "cost" increase in one of the
more expensive aspects of protocol acceleration.  As
an implementer, I would not lightly incur this.
I don't see the advantages as particularly compelling.

> 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.

My understanding is that one end of an SCTP association
may specify one stream per association and the other
end has no choice but to comply as the number is negotiated
by the minimum of the two.  So there is no problem in
making such an presumption.  The implementation is 
simpler if separate associations are used for each
stream between endpoints.

Whether an implementation chooses to do one stream
per association or multiple streams per associations
is a design choice that does not need to be mandated
either way by the mapping standard, and is not mandated
by the proposal.

However I would prefer to see the number of streams
per association layered opaquely below DDP so that
the DDP layer does not know or care about which of its
streams share or do not share an association.
Doing otherwise unnecessarily complicates the layering
model with no added value.  Otherwise you end with
a situation where moving from RDDP/TCP to RDDP/SCTP
requires unnecessary application changes.  This is not
a good thing.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 3 Mar 2003 14:24:24 -0600

>I don't see the advantages as particularly compelling.
For an established association[1], the association is easily
found with the verification tag. From there the
source/destination addresses should be verified to
filter out spoofed packets.

That is true whether you have a "consolidated" context
or not.

>From there you need to perform per-stream processing.
This is a simple lookup within the context of the already
found association. This is the *only* step that having a
one-association / one-stream pairing would save.

Meanwhile it would avoid savings in association setup
(a four-way handshake), Acks (the overhead of which could
be shared with multiple  streams) and congestion control
(each stream would have to do its own slow start).

[1] An established association is where the performance
issues are most important. Matching an incoming SCTP packet
during association setup and teardown is more complex, as
is currently being discussed in the sctp-implementors list.

>> 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.
>
Yes that would be allowed. But that presumes that the
association creator knows that there will be no other
streams. How would it know this?

The key issue is who is the owner of the association?
The ULP or the RDDP stack? If there are multiple clients
that want to access the same remote service, SHOULD they
use the same association?

As I read the SCTP design, the applicability statement
and the sockets API, I believe there is an intent that
an association should be shared by multiple streams.
One of the major comparison points versus TCP cited is
that applications such as HTTP force applications to create
redundant parallel connections, which is unfair and
unproductive use of network resources.
>either way by the mapping standard, and is not mandated
I agree that mandating is probably excessive, but I believe
it ought to remain at the SHOULD level. One of the intents
of SCTP is to consolidate the overhead created by parallel
connections. RDDP's mapping should be consistent with this.

>requires unnecessary application changes.  This is not

That is a valid point. But one that can be solved by simply
viewing the stream as an extension of the port number. The
"connection qualifier" is the port number + stream number,
where TCP only supports stream 0.

This approach can be extremely valuable when the client
machine uses multiple DDP streams to the same server. For
example a web server accessing a file server via RDDP/SCTP.
Traffic shaping can be performed for the total workload,
whille each individual HTTP fetch is too short to be
effectively traffic shaped. No per-fetch setup is required.
And each external HTTP connection can use its own DDP stream
to interact with the file server (avoiding the need for
a central queuing of file server requests).

In any event, I think you are correct that this issue cannot
be properly discussed in the absence of some discussion of
the local interface. I believe this requires a discussion
of how a ULP would create a DDP Stream *without* knowledge
of the underlying LLP.

I would propose that the aforementioned "connection
qualifier" is one very simple method of doing so. The "LLP
Stream" is identified by the remote IP Address(es), the LLP
protocol (SCTP or TCP), the port and the stream number.

The stack would create the association if this was the first
DDP stream requiring it. Later, it could be deleted when all
of its streams had been terminated.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 3 Mar 2003 15:13:23 -0600

To be a bit more specific, the local interface that would
give control over SCTP Stream selection would be the
equivalent of a 'bind'.

If the ULP chooses to bind, the low 16-bits of the "port
number" would specific the SCTP or TCP port number. The
high (or next) 16-bits would specify the DDP Stream.
An application that was unaware of multiple streams would
bind Stream 0 by default, which even TCP supports.

If the application did not issue a bind, which is typical,
the DDP layer would choose the port and stream for it.

The adaptation protocol already includes a reset-notice
to inform the other side that a new DDP Stream has been
initialized.

This is one method. It would also be possible to use SLP
or some IB-CM equivalent to select streams. The benefits
of stream consolidation is not incompatible with maintaining
source level TCP compatability for the ULP.

Caitlin Bestler

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Mar 2003 07:17:45 -0600

Caitlin:

A minor point added to your excellent
comments...

> is currently being discussed in the sctp-implementors list.

Another savings would be the amount of state.. A SCTP
association (or TCP connection for that matter) is a
fairly heavy weight thing.. it takes memory to hold
all of that state blob that makes up the association/connection.
On the other hand, each stream usually takes around 8 - 16
bytes (depending on the implementation.. and I bet you
could get it real low if you had the unordered optimization
you mention previously)... As such this is much smaller
than having N * sizeof(tcb) connections... Quite a
signifigant savings...

And I think the talk on the implementors guide as
come to a conclusion... as Randy Bush as been noted
to say "don't feed the trolls"... and I think
we have done that for long enough :>

> where TCP only supports stream 0.

Which then would combine them into a nice 32 bit number
that could be hashed ... something that seems to
be would be no more overhead than having
multiple associations...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)