IETF Logo Mail Archive

Re: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Mon, 19 November 2018 19:07 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC22130DF3 for <clue@ietfa.amsl.com>; Mon, 19 Nov 2018 11:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 UERFtK8UfkRY for <clue@ietfa.amsl.com>; Mon, 19 Nov 2018 11:07:23 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBF0130DE2 for <clue@ietf.org>; Mon, 19 Nov 2018 11:07:23 -0800 (PST)
Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAJJ7LWv002763 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Nov 2018 13:07:22 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, clue-chairs@ietf.org, "Daniel C. Burnett" <danielcburnett@gmail.com>, clue@ietf.org, pkyzivat@alum.mit.edu, draft-ietf-clue-protocol@ietf.org
References: <154265195328.5264.10510811874699482118.idtracker@ietfa.amsl.com> <fb638fef-452a-4958-31a7-aa403b570ed8@nostrum.com> <20181119190139.GU11132@kduck.kaduk.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <975b22f1-ddd2-b267-51ce-e5629fd50d04@nostrum.com>
Date: Mon, 19 Nov 2018 13:07:16 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181119190139.GU11132@kduck.kaduk.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/SA7LfzcmfhPr1rgkERzrudbz-6s>
Subject: Re: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 19:07:24 -0000

On 11/19/18 1:01 PM, Benjamin Kaduk wrote:
> So it seems the question is scoped to what to do with a peer that is
> behaving properly with the SIP session and claims to negotiate CLUE at the
> SIP layer, but then fails to actually send one of the required CLUE
> messages.


Sure. This isn't much different than an implementation that advertises a 
video stream, causing you to allocate resources for a corresponding 
codec, and then never sends any associated packets. The net effect is 
that you have wasted resources, potentially for the entire duration of 
the session; but, since they go away when the session terminates, there 
is little to no harm inflicted on the system.


>    Section 6 of this document only mentions "a timeout error is
> raised" twice, in some informal discussion of why the initiation phase
> might fail, which is part of what got me thinking about the question.


I suspect that's left-over language from back when we had explicit 
retransmission timers in the document. It might bear removing (or, at 
least, clarification that it's talking about SCTP timeouts).

/a

v2.23.0 | Report a Bug | By Email