Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
Mark Allman <mallman@icir.org> Thu, 18 June 2020 13:32 UTC
Return-Path: <mallman@icsi.berkeley.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 196C83A1129 for <tcpm@ietfa.amsl.com>; Thu, 18 Jun 2020 06:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 a0V009cDg_tB for <tcpm@ietfa.amsl.com>; Thu, 18 Jun 2020 06:32:43 -0700 (PDT)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 7BB813A1030 for <tcpm@ietf.org>; Thu, 18 Jun 2020 06:32:20 -0700 (PDT)
Received: by mail-oi1-f179.google.com with SMTP id k4so5081660oik.2 for <tcpm@ietf.org>; Thu, 18 Jun 2020 06:32:20 -0700 (PDT)
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=KJY7iMMlO4vmvVjOeOugeRmi49K0C3+CD6AiJ1YaH8A=; b=hGni1i732LRkvingbE7BInvdUnIU6tQRMuDri9SbsaVGHxRuMG+44RNsZu83KX4+sB 1SE2Af/xBSxEpPKSCiy9PbaOvS/q4ELp3AgMV0wfqi25q2SSL/UihT3HrjezBHi6UmE+ KSks+uGNjR7qhiweZjqnHlCSAdxo+o90T5xv5UvbE5b7/HBdkARp5W9WDfUosE0XyWN/ XkpSWdciw12bXyK+E0v+0wZmIdRWABm6K21ixSnT2dKDab3EGRmIyHnBeZqXBtFiosv0 95moSbrLD/YRoVS8CxK5KwvDOfLfPvDiIBMQoFSDiu4FqfjTIdSnggdp/NNxBtRF0BRg 2INQ==
X-Gm-Message-State: AOAM532lcXUi6m6FwZPFkw/KwRAGf0SwbK+1vC4nz/VdTh2h84scKv0e BGhgRGlxA0K1xA0PHK4subGQKw==
X-Google-Smtp-Source: ABdhPJyluxM77vPwzbRaKgQnYS9aeaYncowsZJcetgseCJgsGRFJ0h8FfPtzfGLGZEAFJic5FE4tEA==
X-Received: by 2002:aca:cf4c:: with SMTP id f73mr2756309oig.165.1592487139672; Thu, 18 Jun 2020 06:32:19 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:7c97:4043:1622:ee65]) by smtp.gmail.com with ESMTPSA id c23sm699752otd.7.2020.06.18.06.32.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 06:32:18 -0700 (PDT)
From: Mark Allman <mallman@icir.org>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Martin Duke <martin.h.duke@gmail.com>, Review Team <gen-art@ietf.org>, tcpm <tcpm@ietf.org>, Last Call <last-call@ietf.org>, draft-ietf-tcpm-rto-consider.all@ietf.org, tom petch <daedulus@btconnect.com>
Date: Thu, 18 Jun 2020 09:32:15 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <C275B130-44DE-46DC-B50C-9D288EE3A1A4@icir.org>
In-Reply-To: <EB54EC6A-418E-430F-91B1-C6832A606257@gmail.com>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com> <FE0FA7D5-176D-4111-95DA-BD5424A24FE2@icir.org> <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org> <CAM4esxTAMgUc4gfL-_Z2bjChjaHJGWL0F5VJn8Nd-=j2Zj5V_A@mail.gmail.com> <CAM4esxROPy-MX8_fu5inMvsKYVKR16jjTkAntt9qy=vfGM+mUg@mail.gmail.com> <EB54EC6A-418E-430F-91B1-C6832A606257@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_DE62FB0B-1C9C-45FB-BCA3-776933061004_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/XQxReV7slmFBRI41fNsjqNDFbZk>
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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: Thu, 18 Jun 2020 13:32:52 -0000
Last comment first ... > We are getting there, but I would ask that you take the transport > hat off and look again from an infrastructure and packet transport > perspective. I don't view this as looking at it from a transport vs. infrastructure perspective. And, I am not disagreeing with your perspective. My take is that the nub of what you're saying is that there are cases where we know something about the network. And, that something let's us design a more savvy loss detection and response scheme. E.g., because the link / path is known to be short and so using an initial RTO of 1sec is too long. E.g., because the cause of loss is known or can be safely assumed to not be congestion. And, I think that view is both correct and reasonable. However, ... (0) I do not view that view as inconsistent with this document at all. (1) Because there are cases where we know more doesn't make a set of default requirements for the general case when we don't understand the path any less valid. (2) The document explicitly says alternates are fine modulo the usual consensus. I.e., in cases where we have more information we can do things differently. And, the cost of that is no different than the cost today (i.e., specifying it and gaining consensus). So, my view is that this all boils down to making it clear that this is not somehow THE (best) way to do time-based loss detection for all cases. Rather, following the guidelines with result in a safe-for-general-use loss detector. > In the general case, delay across a > network path depends not only on distance, but also a number of > variable components such as the route and the level of buffering in > intermediate devices. > > Its is more the contending/conflicting traffic rather than the > buffering, or perhaps the time spent in queues, but “buffering” is > a link a transport colloquial term. Per this and Gorry's note, I will tweak this to use queuing, as that is what I meant. > Perhaps we could include a clearer disclaimer regarding the > non-best-effort-internet-end-to-end traffic? > You have some text on this down in section 2 but it is a bit buried. OK, let me see if I can foreshadow this a bit more and/or pull some from section 2 to earlier. > An exception to this rule is if an IETF standardized mechanism > determines that a particular loss is due to a non-congestion > event (e.g., packet corruption). > > That is a bit heavy. It should be “a protocol” there than an IETF > standardarized mechanism. The IETF does not have a monopoly on > pre-blessing protocols before they are deployed. > [...] > > In some cases you cannot tell the cause, but it is more important > to ignore the loss. OAM being a particularly good example. First, I don't think I can readily change this without going against the consensus the document has already gathered. (I.e., this is not about the intro, framing, context, etc. bits, but the actual meat of the technical stuff.) Second, you are right that the IETF does not have a monopoly, but that doesn't make the statement in the document the wrong thing to say. Third, I doubt I should change it. The problem here from the standpoint of a set of default guidelines is that we'd like a mechanism to determine the cause of loss to **actually work** before it's OK to avoid a congestion control response. If a standardized mechanism is used then we have some confidence that the mechanism has been vetted as reasonable. If the mechanism is not standardized then we have no idea if it actually works or if it is some ill-conceived scheme that is badly broken. In this latter case, I don't think we want to bless this approach as OK within the default. It may be OK, but it should get some consensus that it is OK. allman
- [tcpm] Genart last call review of draft-ietf-tcpm… Stewart Bryant via Datatracker
- Re: [tcpm] Genart last call review of draft-ietf-… Mark Allman
- Re: [tcpm] Genart last call review of draft-ietf-… Gorry Fairhurst
- Re: [tcpm] [Last-Call] Genart last call review of… Benjamin Kaduk
- Re: [tcpm] [Last-Call] Genart last call review of… Gorry Fairhurst
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] [Last-Call] Genart last call review of… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Mark Allman
- Re: [tcpm] Genart last call review of draft-ietf-… Martin Duke
- Re: [tcpm] Genart last call review of draft-ietf-… Martin Duke
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Gorry Fairhurst
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Mark Allman
- Re: [tcpm] Genart last call review of draft-ietf-… Stewart Bryant
- Re: [tcpm] Genart last call review of draft-ietf-… Mark Allman
- Re: [tcpm] Genart last call review of draft-ietf-… Mark Allman
- Re: [tcpm] Genart last call review of draft-ietf-… Gorry Fairhurst
- Re: [tcpm] Genart last call review of draft-ietf-… Martin Duke
- Re: [tcpm] Genart last call review of draft-ietf-… Yoshifumi Nishida