Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
Mark Allman <mallman@icsi.berkeley.edu> Thu, 28 May 2020 17:09 UTC
Return-Path: <mallman@icsi.berkeley.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2726E3A0063 for <last-call@ietfa.amsl.com>; Thu, 28 May 2020 10:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.20150623.gappssmtp.com
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 eI1HSDLmfuBy for <last-call@ietfa.amsl.com>; Thu, 28 May 2020 10:09:45 -0700 (PDT)
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 EB0973A0061 for <last-call@ietf.org>; Thu, 28 May 2020 10:09:44 -0700 (PDT)
Received: by mail-oo1-xc2a.google.com with SMTP id f39so2555803ooi.7 for <last-call@ietf.org>; Thu, 28 May 2020 10:09:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=lA+o4012FIuRL9MlTHZJo1q8ICFy9+nEt6UqUBbZKxQ=; b=UX9oVGh+8kvODKcOW0uoCxPDiVlDIwYlLtxlZDjKWJivRNPkZMiwhVTtbXbnZPsPSJ zCsTzE1Fl9SICloKB83h/o32GDjlSOkM80rYyu5q4ajYi9+kgFb3U7VY+1AUhY8YHs2E 6WSqXl31jCryhXxpE0cI8NjJoUl6yS4zdSL0c/Sm8U9hgugEMKzDDwn9QnVhpmqfQpJE 0+uyg/TLB6LSZMMe1ewSZQqMGGStbdzIINcYwre9sDygmVVePAULISy1Fh84YwagAVki YFgZtOVxK9SfUptMMMooi2o+PwToMftorL/EG0cdEKbpdu9DfPNzhgIJx/TUF11N+iLd SfpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=lA+o4012FIuRL9MlTHZJo1q8ICFy9+nEt6UqUBbZKxQ=; b=rhzSfRkNOnfohHtdIJhvq2238PvS9sXKrualdcYf1NwywnP16m4ywwPLuyWMSj9lNy awwixtHMLiLOBPWwHFQnuOzolaxwMHK9ZBO4cnvLw4lj2ZkRergGoTl7CJebgR+6km3v zUULdVIkCLX6Dsi3UHnxPbkGPUdM91tR8V2pRFK/WBCRKDEfrXJ8ea9d3FmYuNDgsc3g gDEZaZegbQTCsEyur4RfQlYJN5kJbe0Rt8TWLam82wRlNYfdwbaL0KQhVxe/mb6YdL1y 11AjhOlNJ0JEJwklwtrgNGCSCdLEp/BmKkmZ9F54hSrwLfOy2+XlG24kvjbmsTcYEcHq OZ9Q==
X-Gm-Message-State: AOAM530Mnt7XfocPLG1pPWf552wumd+scIp4ol+MTNazaKb2NedEFnjB f/Rd5QOlPKupvjmTi1zQ+sRmCg==
X-Google-Smtp-Source: ABdhPJyrLQ6yQ7TuBn8u7VcXi+6tzQvHYnyQ8JScfz2FasLd0Z+XXzLv+6cvLbQ2B/A/B0HwOQJL4A==
X-Received: by 2002:a4a:381:: with SMTP id 123mr1364729ooi.85.1590685784043; Thu, 28 May 2020 10:09:44 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:3c1d:c19b:e6c9:7c4e]) by smtp.gmail.com with ESMTPSA id w2sm493574oon.36.2020.05.28.10.09.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2020 10:09:43 -0700 (PDT)
From: Mark Allman <mallman@icsi.berkeley.edu>
To: tom petch <daedulus@btconnect.com>
Cc: last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Date: Thu, 28 May 2020 13:09:41 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu>
In-Reply-To: <5ECFE791.3050400@btconnect.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <DB7PR07MB53406A74483D8123C75ADD70A28E0@DB7PR07MB5340.eurprd07.prod.outlook.com> <5ECFE791.3050400@btconnect.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_42FFD37B-5BE3-4C2A-A5FE-EEB540C6FC81_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/lSkiniNpfxTY1K0QArkxUHmNMlo>
X-Mailman-Approved-At: Thu, 28 May 2020 11:01:18 -0700
Subject: Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 17:09:46 -0000
I just want to quickly correct one thing here ... > [the draft] then recommends a minimum RTO of one second (a) It DOES NOT say this at all. The document does not specify ANY minimum RTO. The document does says this: In the absence of any knowledge about the latency of a path, the initial RTO MUST be conservatively set to no less than 1 second. But, as soon as there is some notion (e.g., a RTT measurement) then there is knowledge and this no longer applies. I.e., this is for the startup case where we are beginning transmission into an unknown network path. (b) If this is too hefty for some application, that's fine. Do what we do now and get consensus to use something different. Again, the document says: The correct way to view this document is as the default case. [...] The requirements in this document may not be appropriate in all cases and, therefore, inconsistent deviations may be necessary (hence the "SHOULD" in the last bullet). However, inconsistencies MUST be (a) explained and (b) gather consensus. In other words, the worst case is the current case. 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 out what your complaint about that is. Perhaps you could try again so my pea brain can understand the complaint? Thanks! allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Benjamin Kaduk
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Stewart Bryant
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Martin Duke
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… tom petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… t petch
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Carsten Bormann
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [Last-Call] [tcpm] Last Call: <draft-ietf-tcp… Joseph Touch