IETF Logo Mail Archive

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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Thu, 28 June 2018 14:35 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472C0130E8C for <rtcweb@ietfa.amsl.com>; Thu, 28 Jun 2018 07:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8N743MVuyDq for <rtcweb@ietfa.amsl.com>; Thu, 28 Jun 2018 07:35:19 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17603130E21 for <rtcweb@ietf.org>; Thu, 28 Jun 2018 07:35:19 -0700 (PDT)
Received: from [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d] (p200300CD6F1A97003C96AA9C3349E44D.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 65216721E2822; Thu, 28 Jun 2018 16:35:16 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no>
Date: Thu, 28 Jun 2018 16:35:15 +0200
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de>
References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/ITn82qIjy07eyw38oUAgodUuka4>
Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 14:35:22 -0000

> On 28. Jun 2018, at 16:22, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Den 28. juni 2018 14:51, skrev Michael Tuexen:
>>> On 28. Jun 2018, at 13:30, Harald Alvestrand <harald@alvestrand.no> 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... 

Best regards
Michael
> 
>> 
>>> I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes
>>> before concluding that it doesn't say.
>>> 
>>> What I'd PREFER it to say is "these messages will be dropped on the
>>> floor. Tough luck."
>>> 
>>> I would prefer it to say so explicitly.
>>> 
>>> Can we do this?
>> Not sure about the procedural thing... That ID is stuck in the RFC editor queue
>> for a long time...
>> 
>> Best regards
>> Michael
>>> 
>>> -- 
>>> Surveillance is pervasive. Go Dark.
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>

v2.23.0 | Report a Bug | By Email