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

Benjamin Kaduk <kaduk@mit.edu> Mon, 19 November 2018 19:01 UTC

Return-Path: <kaduk@mit.edu>
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 AE54C130DED; Mon, 19 Nov 2018 11:01:59 -0800 (PST)
X-Quarantine-ID: <5DVNigcQCfqM>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5DVNigcQCfqM; Mon, 19 Nov 2018 11:01:57 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6781130DE3; Mon, 19 Nov 2018 11:01:56 -0800 (PST)
X-AuditID: 12074422-bb9ff70000005074-ad-5bf308a083dc
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 22.BA.20596.1A803FB5; Mon, 19 Nov 2018 14:01:54 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAJJ1khI009966; Mon, 19 Nov 2018 14:01:47 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAJJ1en0004503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Nov 2018 14:01:43 -0500
Date: Mon, 19 Nov 2018 13:01:40 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Adam Roach <adam@nostrum.com>
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
Message-ID: <20181119190139.GU11132@kduck.kaduk.org>
References: <154265195328.5264.10510811874699482118.idtracker@ietfa.amsl.com> <fb638fef-452a-4958-31a7-aa403b570ed8@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <fb638fef-452a-4958-31a7-aa403b570ed8@nostrum.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTURju7M7tbOzW8ap40iy8Wj+MmYbBfpT5o8ykwAoMG5RXd3XDfci9 U5wUiFToXJKDQieV2LQQCVb4MZgsVxkNjUKKFkqERumfaVKSH6N7HX78e97zfPEeXkhQrTFJ 0GC2spyZMdIypZSS56aru+GSNmtlNVXjW++Wa/443TKNPzhJaDzew5rIfA+haV9rI/JkBV7X tLzA7f4nKXB5Z6VFxBXlcR1rNNSy3JHcUqU+sOAgqn/tqWvqXwYN4LvKDhQQoxzcMeYHdqCE FOqX4G5nMxEdPAD7V4Ky6DAtwQv2p3LRIkUHsaclJBOxDKXjhpZJQsTxKBXffhXacBNoBOAf A4NCLoRxqAz7JjJEDSnU3Xw4sZFDoUaAw6vF0fdY/K5jVipiAmXgL5E5iWglUDJ+EoEiVKCT eM59QlQkoDQ80hqQ3wXItcPs2mF2bZu7ANEHUnSmerWJMRh5tlzNlzNmM8upj2WaDNZMVlfz HGx89Sl6GLRFCgMAQUCryJevF7VUDFPL20wBsBdK6ARy/NtvLbW7zKKz6Rlef42rMbJ8AGBI 0PFkUa/AkTrGVs9ylk0qGUrpRHItfkZLoUrGylaxbDXLbbL7IKQxeVa+pKViObaSraswGK3b tAQqxHCVEO4QNSRfzZh4Q2WUDwI1HBxvbicoqdliZpMSyQuiCIkifY15K0c8I1zlvz4PEoW1 4shZUaUSjmwraV4okQglPz+FxRIrs00lNYADtZZBzWlnICX/TqfP6Vt//0ipdqifOYbO952h bnzd7/GNLfe+OFqYMprdE2m6hN7OlFwcyVc4exendtmL7x2ayh1IA3NXZxrDqqLLZaVZIGd0 OIiKP98PTYb+vnk81CnVj6ZW5IAH58JV3pLgh48tJJlVol2wTd9a78jTddFSXs9kZxAcz/wH QoiwFSEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/RFi-10MoYjrruZzqMQWha4Rfm-E>
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:02:00 -0000

On Mon, Nov 19, 2018 at 12:55:04PM -0600, Adam Roach wrote:
> Trying to help out a bit on one of the discuss points...
> 
> On 11/19/18 12:25 PM, Benjamin Kaduk wrote:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for the generally clear and well-written document!
> > I would like to discuss whether there needs to be more prominent coverage
> > of timers/timeouts, especially as relating to the state machines.  (I'd be happy
> > to learn that this is well-covered elsewhere in the document set; I just haven't
> > run into it yet.)
> 
> 
> The initial document included several timers that triggered 
> retransmissions of messages -- but since the CLUE protocol uses TCP as a 
> substrate, these kind of application-level retransmissions can cause a 
> spike of traffic when the networks starts getting congested, which is 
> the opposite of what we want to happen. So they were removed, and the 
> protocol now relies exclusively on the reliability mechanisms provided 
> by TCP both for retransmission and for detection of connection failures.

(SCTP now, but sure.)

> In terms of supervising the overall lifetime of the state machines, it's 
> important to keep in mind that these operations always take place within 
> the context of a larger session (e.g., a SIP session), which naturally 
> limits how long the state machines can live: at the end of the 
> corresponding session, all CLUE state goes away.

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

-Benjamin