Re: [rtcweb] Data channel: Handling of packets on unknown channels

[Harald Alvestrand <[e-mail]>]

On 06/29/2018 05:57 AM, Justin Uberti wrote:
> Taylor is correct. In that thread, we agreed that the PeerConnection
> doc should say "tough luck".

I read through that thread again (sorry for forgetting about it in my
initial message), and couldn't figure out what the exact semantics of
saying "tough luck" were.

I think the simplest thing on the protocol level is to drop the packets.

On the API level, we can add a warning saying "Note: If you don't make
sure the receiver has configured the datachannel before you send
packets, you risk losing some initial packets."

But we need to make sure the protocol machinery does exactly that (and
not, for instance, shut down the SCTP session), so that the warning is
correct.


>
> On Thu, Jun 28, 2018 at 10:38 AM Taylor Brandstetter
> <deadbeef=[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Note that I started a thread about this last
>     month: https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius
>
>     On Thu, Jun 28, 2018 at 8:19 AM, Michael Tuexen
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>
>         > On 28. Jun 2018, at 17:01, Harald Alvestrand
>         <[e-mail] <mailto:[e-mail]>> wrote:
>         >
>         > Den 28. juni 2018 16:35, skrev Michael Tuexen:
>         >>> On 28. Jun 2018, at 16:22, Harald Alvestrand
>         <[e-mail] <mailto:[e-mail]>> wrote:
>         >>>
>         >>> Den 28. juni 2018 14:51, skrev Michael Tuexen:
>         >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand
>         <[e-mail] <mailto:[e-mail]>> wrote:
>         >>>>>
>         >>>>> In considering the datachannel API, we encountered one
>         interesting race
>         >>>>> condition:
>         >>>>>
>         >>>>> A: <configure for datachannel>
>         >>>>>
>         >>>>> A: CreateOffer(), SetLocalDescription(), send SDP
>         >>>>>
>         >>>>> B: SetRemoteDescription, CreateAnswer,
>         SetLocalDescription, send SDP
>         >>>>>
>         >>>>> B: Configure an externally defined data channel, with #3249
>         >>>>>
>         >>>>> B: Send a message on #3249
>         >>>>>
>         >>>>> A: SetRemoteDescription
>         >>>>>
>         >>>>> A: Wait a while (THE PAUSE)
>         >>>>>
>         >>>>> A: Configure #3249
>         >>>>>
>         >>>>> Now, if a message comes in to A on #3249 during THE
>         PAUSE, what is the
>         >>>>> implementation to do?
>         >>>> Isn't that some kind or error condition?
>         >>>>
>         >>>> If that it true, one could apply:
>         >>>>
>         >>>>  If a message with an unsupported PPID is received or
>         some error
>         >>>>  condition related to the received message is detected by
>         the receiver
>         >>>>  (for example, illegal ordering), the receiver SHOULD
>         close the
>         >>>>  corresponding data channel.  This implies in particular that
>         >>>>  extensions using additional PPIDs can't be used without
>         prior
>         >>>>  negotiation.
>         >>>
>         >>>
>         >>> The receiver can't close the datachannel if the
>         datachannel doesn't
>         >>> exist yet, so this doesn't work for that case.
>         >> I was assuming that the SCTP receives a user message on a
>         stream. When
>         >> this message is delivered to its upper layer, doesn't this
>         layer know
>         >> that there is no data channel? I would assume that this
>         layer triggers
>         >> the stream reset procedure. I'm not saying that the user
>         (for example
>         >> via a JS API) is involved... I'm more talking about
>         implementing this
>         >> iside the browser..
>         >
>         >
>         > Exactly, it could close the stream, but it can't close the
>         data channel
>         > since it doesn't exist.
>         Well, I can run the procedure and the peer will get an
>         indication that
>         something isn't working well.
>         > 
>         > I think closing the stream would be a mistake, since that
>         would make the
>         > outcome about whether you end up with the datachannel or not
>         racy;
>         > discarding data will give you a working datachannel once A
>         gets around
>         > to configuring it.
>         But if the user configures a reliable data channel, the user
>         does not
>         get the service that was required...
>
>         Best regards
>         Michael
>         >
>
>         _______________________________________________
>         rtcweb mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.