Subject: RE: [rddp] DDP/SCTP Stream Reset

From: "Williams, Jim" <[email-masked]>
Date: Mon, 9 Dec 2002 12:51:11 -0500

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Monday, December 09, 2002 11:58 AM
> To: [email-masked]
> Subject: [rddp] DDP/SCTP Stream Reset
> 
> 
> One issue in the mapping of DDP to SCTP is how to
> "terminate" an individual DDP Stream in a way that does not
> affect the other streams carried on the same SCTP
> association.

Allowing one stream per association and closing the 
association when the stream is terminated seems
simple, and closely parallels the TCP functionality.

Perhaps you could discuss the value of multiple 
streams per association.  Is there additional
value to allowing RDDP streams to be dynamically
created and destroyed on an ongoing SCTP association?
Also how does this map to the RDDP client?
Do RDDP streams on a single association look any
different to the ULP than streams
on separate associations?  Are the mappings of 
streams to associations controlled by the ULP,
or done transparrently by the DDP layer in a 
way invisible to the ULP?

These questions may be born of ignorance of
SCTP, but seem worth some explanation at least.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 9 Dec 2002 12:15:19 -0600

On 12/9/02, Williams, Jim wrote:

>on separate associations?

Good questions.

The most important values of sharing an association are:

- Connection setup overhead is paid for per Association,
  not per Stream.
- Acking is shared across all streams. This reduces traffic.
- Keepalive is shared across all streams. Ditto.
- Congestion control and traffic shaping can be done at
  the association level. Typically is a better aggregate for 
  control. Frequently each stream is too small to shape.

There is at least one application scenario where multiple
streams would be of extreme value: a front end server that
deals with a very large number of TCP/IP clients
concurrently, and then makes use of RDMA to access database
and/or file servers. Web and Email servers, for example.

Each end client can be dealt with on a different DDP stream.
The stream could be released and reclaimed for each client,
or each processing thread could simply own a stream. In any
event, an error on one stream would not impair the entire
association.

In such an environment it would be plausible to *never*
reach a zero client level. Hence the association between a
given front-end server and a given back-end server might
never go idle. Having to periodically migrate to a new
association would work, but hardly seems friendly.

The key requirement for DDP is to ensure that all in-flight
traffic associated with a stream that has gone bonkers will
be discarded. Placing the reset message *after* the
tear-down ensures this, even without an enforced "time out"
period.

> Are the mappings of streams to associations controlled by
> the ULP, or done transparrently by the DDP layer in a way
> invisible to the ULP?
>
That's a local interface question. But both approaches are
valid. An association can be between two applications, that
just have many concurrent communication threads (as in the
web/email server example), or it could be created implicitly
by the DDP stack so that each DDP stream looks the same
whether it is an SCTP Stream or a TCP connection.

I tend to favor the latter, but any such schemes should
restrict sharing of an association to streams that have the
same class of service. Additionally, unless kernel mode
support is very cheap, a single association may be confined
to a single user process.

This is an area where the protocol must be compatible with
multiple common programming practices. Daemons which support
multiple clients can be implemented as state machines with
objects for each client, multi-threaded daemons with threads
per client and multi-process daemons that launch processes
for each client.

And I have always believed that standards should be flexible
enough to allow my competition to do something wasteful such
as launching a distinct process for each client.

More seriously, I do not want a standard to presume any
execution model, because then my competitor will force me to
match their legacy code.

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