Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14

Martin Duke <martin.h.duke@gmail.com> Wed, 17 June 2020 17:21 UTC

Return-Path: <martin.h.duke@gmail.com>
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 CAC943A0AA2; Wed, 17 Jun 2020 10:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ouThygbpX5Ax; Wed, 17 Jun 2020 10:21:06 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 3EE513A0A9C; Wed, 17 Jun 2020 10:21:06 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id i4so659072iov.11; Wed, 17 Jun 2020 10:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ieix0otep0Pryj066lfXA+VNML5YvyE5vSQRvKyNbMk=; b=k17Z6Tq9EzKzKwtJFYb0GR3XwsqG0xx0oawsS8n6bvi6xOZ9N5srgJpovxeqHdBGeV 44FGSbMgstxDAQus5v++JglyIrKKmZyEhn3lErD+QMP76Tc5Wb6bB0eMpWRZYZ1Zmd7L wMeg9EgDtVNe2rDhr1syNP1GI2cEGS++WWehe+w97Z+z3TUNZJM8f/6DFji+t7I4A3sF 6dIjqHD2MFcbyVp4l49tmQOoEsRFaJK64EkEvdfDWI5hZgpOkvaXwDiY3dq2X+X4ZQPx Z5fs2RAH6LVs2jdb5NuSjd9Y7XElkn0pJUz7MIdGptksJpARreY6GqBg3+w8M2EnQgQE c3cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ieix0otep0Pryj066lfXA+VNML5YvyE5vSQRvKyNbMk=; b=EKQYirn8My3sUsAaoOqDAqRv2f0AIkrBqFJ44n+YFZskBATQJgwQWoRfnTM7v+yYUi eS1mBfMyAdAVEdJq65K8cjaUYRP0JrswqhuFDu7aBcYMrVNvrF53ZCEzXBDUlXd4FNL2 evcHXJqckqJT7Mzw0dWGYLSMbdPeSwraH/6DJpc1cNEtCaJWHUsuzmSFT6aMbSFqJgj2 iBLXZbm3moMDMCMX9/cC6Jr2QbIXgSHK2Hy09Rv7ibjoXE8ZnWzhL5TeVCCy0rgfMHq2 uo90YdluT6h3BRoxyEEbSkLCA0yvEZ6DGM/T2Juqy5qgUuJ5WmsxSphsSILBPvSOf5jv 4DCA==
X-Gm-Message-State: AOAM532b0CjN6NJ6cAUl7I3D5/Vjq95uvGiRd1SG6UWEb7FzJCyflG/n vv0SCP4Ypf21p2xuiTETbOj/iIoMTjTM8UrG6tk=
X-Google-Smtp-Source: ABdhPJwu8OABmROZgHSPiBTJ15fYJB3uVUs3Vu6AKMr0HPWRm+VxY4LEW2HF1kuecHSffLdAqO0EH/yK4bXGaV5OjRQ=
X-Received: by 2002:a6b:e311:: with SMTP id u17mr428648ioc.51.1592414464640; Wed, 17 Jun 2020 10:21:04 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAM4esxTAMgUc4gfL-_Z2bjChjaHJGWL0F5VJn8Nd-=j2Zj5V_A@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 17 Jun 2020 10:20:53 -0700
Message-ID: <CAM4esxROPy-MX8_fu5inMvsKYVKR16jjTkAntt9qy=vfGM+mUg@mail.gmail.com>
To: Mark Allman <mallman@icir.org>
Cc: Stewart Bryant <stewart.bryant@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>
Content-Type: multipart/alternative; boundary="000000000000800f4505a84ae213"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/PI1Zs6yYwBJXdPsiUBfrrANfp70>
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: Wed, 17 Jun 2020 17:21:11 -0000

Hi Stewart,

If there are no further objections, I'm going to declare consensus.

On Thu, Jun 11, 2020 at 1:45 PM Martin Duke <martin.h.duke@gmail.com> wrote:

> Stewart,
>
> do we need more cycles for this, or is draft-15 sufficient to address your
> concerns?
>
> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman <mallman@icir.org> wrote:
>
>>
>> Hi Stewart, et.al.!
>>
>> I just submitted a new version of rto-consider.  Please ask the
>> datatracker for diffs between this and rev -14.  The highlights:
>>
>>   - The diffs with the last rev are here:
>> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>>
>>   - All small comments addressed.
>>
>>   - I think we all agree that this is not a one-size-fits-all
>>     situation.  Rather, this document is meant to be a default case.
>>     So, the main action of this rev is to make that point more
>>     clearly.  The first paragraph in the intro is new.  Also, there
>>     are some more words fleshing out the context more in section 2.
>>     In particular, more emphatically making the point that other
>>     loss detectors are fine for specific cases.
>>
>>   - The first paragraph in the intro also makes clear we adopt the
>>     loss == congestion model (as that is the conservative default,
>>     not because it is always true).
>>
>>   - I made one other change that wasn't exactly called for, but
>>     seems like an oversight.
>>
>>     Previously guideline (4) said loss MUST be taken as an
>>     indication of congestion and some standard response taken.  But,
>>     this guideline has an explicit exception for cases where we know
>>     the loss was caused by some non-congestion event.  Guideline (3)
>>     says you MUST backoff.  But, it did not have this exception for
>>     cases where we can tell the cause.  But, I think based on the
>>     spirit of (4), (3) should also have these words.  So, I added
>>     them.
>>
>>     Also, I swapped (3) and (4) because it seemed more natural in
>>     re-reading to first think about taking congestion action and
>>     then dealing with backoff.  I think the ordering is a small
>>     thing, but folks can yell and I'll put it back if there is
>>     angst.
>>
>> Please take a look and let me know if this helps things along or
>> not.
>>
>> allman
>>
>