Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

On Apr 18, 2013, at 7:00 PM, Martin Thomson wrote:

> On 18 April 2013 09:51, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Yep, "reset the stream" is probably the right terminology.
> 
> Note that I was using a very specific terminology, not making shit up
> (I know, it's hard to tell sometimes).  c.f.
> http://tools.ietf.org/html/rfc6525#section-4.2
> 
> Unfortunately, the "Incoming SSN Reset Request Parameter" doesn't
> include a way to signal that a particular reset is somehow different
> from a normal close.  Therefore, unless you look at the SACK chunks -
> which is probably not possible above the SCTP layer - you can't tell
> the difference between:
> - I got your data and I'm done with this channel now
> - The OPEN message got lost for long enough that I ran out of
> buffering time or space, so this channel is borked; nothing was
> delivered
Absolutely correct!
> 
> This is where I think that Bernard was going with this.  It's not that simple.

I think you are looking for some kind of "reliable opening a datachannel".
That was provided by the three way handshake. But the working group decided
that this kind of setup is not required...
> 
> I really don't want to get back to the point where we require
> application-level (read: browser-level) acknowledgement of OPEN
> messages to address this corner case.  But we have to acknowledge that
> it's a problem and deal with it somehow.  (HTTP/2.0 has an error
> message that it uses for this sort of case, maybe that could be a
> solution, assuming that the stream ID on the reverse path is
> available.)
I think the OPEN can only be sent if both streams (incoming / outgoing) are
are available. I suggested an Error message already several times. Also
for other things like reception of unsupported message types, unexpected messages,
message formatting issues, ... There are several error condition. I think
the alternative suggested was to reset the streams. However, for the peer there
is no way to figure out why the data channel was closed if something was lost.

Best regards
Michael
> 
> --Martin
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 