Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Martin Thomson <[e-mail]>]

On 18 April 2013 09:51, Harald Alvestrand <[e-mail]> 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

This is where I think that Bernard was going with this.  It's not that simple.

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

--Martin