Re: [Bug 23832] New: Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases

On 11/20/2013 12:37 AM, Martin Thomson wrote:
> On 18 November 2013 21:35, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Again, I'm searching for the justification for making the model more
>> complex in order to save an OPEN message.
> As I have explained before, several times, in this context, there are
> usage models for SCTP that don't look like data channels.  It may be
> that I just like those usage models because I'm used to them, but
> here's an example that the current API doesn't support, but could
> easily.
When I have data channels, everything looks like a nail, I guess....

>
> Open unreliable, out-of-order delivery stream, send packet, close
> stream.  Assuming that each message provides sufficient
> self-identification this is perfectly doable without an OPEN.
> Requiring OPEN here would force the stream into reliable, in-order
> delivery, which potentially increases the latency of the above.
> Requiring signaling: even slower.  Establishing channels "just in
> case": not really feasible.

So let's reduce this a bit below the "....

You have chunks of data (packets).
You need them to be delivered to the other side, out-of-order, unreliably.
You need to have them delivered to the same application, but you need to
have different IDs on the packets (what you're using channel numbers for
in your suggested implementation).
You're OK with having them in one congestion control regime (otherwise
they would have to be in different PCs).
You can't spend the time to set up a channel per ID.

As far as I can tell, the following design will satisfy your criteria:

- Open up a single data channel at app establishment time. External
configuration allows you to do this with no extra round trips.
- Prefix each data packet with a number between 0 and 65535 (the ID).
- Dispatch as needed.

The advantages over the "self-opening" data channels are:

- No need to close the resulting ephemeral channels
- No need to guess at any property of the channels
- No chance of hitting a channel number that is in use for any other purpose

It's always possible to build a connectionless service on top of a
connection-oriented service, and vice versa. The details of how to do so
may matter; they control how much state we accumulate, and where.

>
> Given the current API, these cases are probably better off just using
> existing channels, but that suffers from concurrency issues.


-- 
Surveillance is pervasive. Go Dark.

Received on Wednesday, 20 November 2013 05:38:34 UTC