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
- [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-1… The IESG
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] Last Call: <draft-ietf-tcpm-rto-consid… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Benjamin Kaduk
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Stewart Bryant
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Martin Duke
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… t petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Carsten Bormann
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Joseph Touch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Wesley Eddy