IETF Logo Mail Archive

Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description)

Harald Alvestrand <harald@alvestrand.no> Wed, 27 August 2014 11:16 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D601A0647 for <rtcweb@ietfa.amsl.com>; Wed, 27 Aug 2014 04:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 Pg2Nxdqa9PG7 for <rtcweb@ietfa.amsl.com>; Wed, 27 Aug 2014 04:16:53 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8B1A034D for <rtcweb@ietf.org>; Wed, 27 Aug 2014 04:16:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 679887C3FEF; Wed, 27 Aug 2014 13:16:52 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAmeQejb5E6b; Wed, 27 Aug 2014 13:16:51 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:7cd6:dc81:94a3:b548] (unknown [IPv6:2001:470:de0a:27:7cd6:dc81:94a3:b548]) by mork.alvestrand.no (Postfix) with ESMTPSA id 599A47C05BE; Wed, 27 Aug 2014 13:16:51 +0200 (CEST)
Message-ID: <53FDBE22.8080609@alvestrand.no>
Date: Wed, 27 Aug 2014 13:16:50 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <CABkgnnW05HW2kdEH49GfSTe1unCeqKUWguUqd29iMjOc1z5BAg@mail.gmail.com>
In-Reply-To: <CABkgnnW05HW2kdEH49GfSTe1unCeqKUWguUqd29iMjOc1z5BAg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KwgOWmZPJh3qDfVp38PdDyTQhe0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 27 Aug 2014 11:16:57 -0000

On 08/26/2014 11:22 PM, Martin Thomson wrote:
> On 26 August 2014 13:36, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>> What I don't understand how ignoring gives you extensibility. If one sides sends a new PPID, and
>> the other sides ignores it, the sender (at the SCTP level) thinks that the message was received
>> without any problem, since SCTP doesn't take the PPID into account. So user messages are lost.
> I think that the use of a new PPID can be negotiated prior to use, so
> there aren't big problems with any action recommended here.  Resetting
> the stream might work, assuming that we can distinguish between an
> error and a graceful close correctly, that is.

If there is negotiation, there is no problem.

If there is no negotiation, starting to use the new feature will either 
lead to ignored messages or lead to a crashed connection.

Ignored messages are not a problem if they form part of an ignorable 
extension (for instance if someone decided to once in a while send 
checksums over all the data sent so far - doesn't matter to those that 
don't understand it, since it doesn't carry any extra data).

Crashed connections are usually a problem, so that will mean "no 
unnegotiated extensions, ever".

I'm happy with either way of doing it, as long as we're explicit about it.

v2.23.0 | Report a Bug | By Email