Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice

Benjamin Kaduk <kaduk@mit.edu> Sun, 31 May 2020 18:54 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414F93A0BAE; Sun, 31 May 2020 11:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 nLO90YRNHvrY; Sun, 31 May 2020 11:54:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6D76B3A0BA1; Sun, 31 May 2020 11:54:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04VIs2Gc000540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 14:54:04 -0400
Date: Sun, 31 May 2020 11:54:01 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mark Allman <mallman@icsi.berkeley.edu>
Cc: tom petch <daedulus@btconnect.com>, last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Message-ID: <20200531185401.GU58497@kduck.mit.edu>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <DB7PR07MB53406A74483D8123C75ADD70A28E0@DB7PR07MB5340.eurprd07.prod.outlook.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ck5tMHUVgo0x3aKUtM9Lyw3lhag>
Subject: Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2020 18:54:13 -0000

On Thu, May 28, 2020 at 01:09:41PM -0400, Mark Allman wrote:
> 
> I am not entirely sure I understand the remaining points in the
> review as it's pretty rambling to me.  Certainly we use heartbeats
> (in things like SCTP) and control packets (think TCP zero window
> probes or keep-alives).  The document is very simply saying that if
> these are used in some fashion we can also use them to measure FT
> information.  That seems pretty reasonable to me and I can't figure

There was a quote from the document: "Some protocols use keepalives,
heartbeats or other messages to exchange control information."
A naive reading of this text is that it is discussing ways to exchange
control information, and giving specific examples of keepalives and
heartbeats as messages used to exchange control information (while admitting
the existence of other such messages).  This is as surprising to me as it
is to Tom -- keepalives and heartbeats do not, in my experience, contain
control information!

Your follow-up discussion suggests that the intent is to say that "some
protocols use regular/periodically/frequently exchanged messages, such as
for keepalives, heartbeats, or control-information exchange" and to
leverage that traffic for FT purposes.  I suggest that this be clarified in
the text of the document.

Thanks,

Ben