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 18:55 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 26CE4130E8D for <clue@ietfa.amsl.com>; Mon, 19 Nov 2018 10:55:20 -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 gC8t8Hk0xj8D for <clue@ietfa.amsl.com>; Mon, 19 Nov 2018 10:55:17 -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 C3CB0130E43 for <clue@ietf.org>; Mon, 19 Nov 2018 10:55:11 -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 wAJIt9FE000711 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Nov 2018 12:55:10 -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>, The IESG <iesg@ietf.org>
Cc: 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>
From: Adam Roach <adam@nostrum.com>
Message-ID: <fb638fef-452a-4958-31a7-aa403b570ed8@nostrum.com>
Date: Mon, 19 Nov 2018 12:55:04 -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: <154265195328.5264.10510811874699482118.idtracker@ietfa.amsl.com>
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/uO5gx_qf_jpXaRoy04fMD44fF0Y>
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 18:55:26 -0000

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.

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.

/a