Re: Fwd: Re: SCTP mapping to data channels

On Sat, Feb 4, 2012 at 11:39 PM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 2/4/2012 3:43 PM, Harald Alvestrand wrote:
>
>> just my $0.02 off the cuff....
>>
>> since the streams are naturally unidirectional, have no open, but do
>> have a reset, it seems to me like we should reflect that unless we have
>> a reason not to:
>>
>> - SDP item (TBD) is used to say "we want a data channel", and the
>> initial max # of channels
>>
>
> I'm not even sure we need that.  The association can be created on-demand;
> we already have the DTLS connection.  Initial channels is only marginally
> useful, and could be a simple attribute.


Correct, if we're using BUNDLE, but I don't think BUNDLE is mandatory to
use.

>
>
>  - createDataChannel() grabs the first unused channel, adds more channels
>> if it needs to
>>
>
> Sure.
>
>
>  - channels are unidirectional
>> - first packet (sequence #0) causes an onopen() event before the
>> ondata() event
>> - a reset causes an onclose() event
>>
>
> I'll need to check if reset is signaled to the far side immediately; I
> suspect it might not be.  If it is, that would work.


This sounds like a good way of handling construction/destruction of
channels.

>
>
>  With this we should not need any signalling (leaving apps to use channel
>> 0 specially if they want to), and will in practice have an infinite
>> number of channels.
>>
>> when in doubt, keep it simple....
>>
>
> Definitely.  And this is a straightforward mapping, since we now know that
> adding channels and reset are supported.  That simplifies our work (as does
> leaving them unidirectional - no glare, no params that need to be
> exchanged, etc).
>
> There is an assumption that for unreliable, partly-reliable and
> out-of-order channels that the receiver knows this fact; if not that would
> need to be exchanged (perhaps by the app on channel 0).


This is kind of a tricky situation since as you point out, the
reliable/in-order attributes are per-DATA, not per-stream. So we either
need to surface this information per-packet, or disallow certain SCTP
protocol usages (i.e. for endpoints that are not implemented using this
API).



>
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
>