IETF Logo Mail Archive

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

Stewart Bryant <stewart.bryant@gmail.com> Fri, 05 June 2020 16:29 UTC

Return-Path: <stewart.bryant@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 F3EFC3A0829; Fri, 5 Jun 2020 09:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 3us0VMTq9dm4; Fri, 5 Jun 2020 09:29:46 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 87FCD3A081B; Fri, 5 Jun 2020 09:29:46 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id j10so10374901wrw.8; Fri, 05 Jun 2020 09:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U9hWm/YTjCmJ+CnMZMf6a8Pki+iiuMWSpn2AK51FAbU=; b=Zq6GJPux4k7myhXyFg50KYWAECDnngcjiNdCWqwLR3wA5VYWwjaPgbczpUTGFLOat3 dXacb8IGXI5BO1NlT0Bg+klWw1TSzq3mq0y+yYH1VgsxRSjlXbo86/joXZaoBe2cLAK0 j/ipxHZboV4QKQAxmwSowp2F0IC3uDzZmr0F9KuD3rRKwgYaOmRxy+sd2FIdEt30kIuW 7QVSKC0vmSDxv0NzvkHLp2EADjRZe4U6azhfHiKMoU46ybOBNpb1u4hXyZb7UjVGMd16 WFDyjUQGxoeTB+UlTAVPvrVvl0V0+2uKOyUuH/p2HdRn1FberfK27HL0kUSSRB2x91p4 3Eqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U9hWm/YTjCmJ+CnMZMf6a8Pki+iiuMWSpn2AK51FAbU=; b=DtvblT6BozZV6o4DlZI94UYwGK+XMH2iNXBn70v8/oAmx0P3iVuJg/hVQ7SKa6Vbci gL1tVyzqjNHgwdRkqifDC8AmG7EGIIgkDvNudZEW8tPZTP6U1+B9xvdRgu+JqA1ETGnE bE383vc0jNTe6R0Vn0SobEVg5LCz1piyuyIX4oAgxvs9YyfU3HpWEsbq1XOAMfw3uMVC xzv+GKo5rSoA5oxPX2Et8Wx5J1ZwI4XWDpyrzDqF1tvnwcVygm4mEuz2bR9YY7F1H+3N f1ssSVuYLCmocyWFgoziJe7OqinmCOnJIyDs1jJ8A2zyL8GREpddBFWVUxIxRJOcPBQJ Cbbw==
X-Gm-Message-State: AOAM532GR6c0VDZsJSney5SU5vPFeXBqa/9+3UPYUZDBeE+NMRKVkohw v+WFJZf7yxCoo5PkTMtqs8Y=
X-Google-Smtp-Source: ABdhPJy1B7flHKeQesAir+SgNysaBxrhpoXo4kThEy1pqYO1xM4465bL13i42rJoQ+xofWs0qXy6qg==
X-Received: by 2002:a05:6000:d:: with SMTP id h13mr10090077wrx.17.1591374584896; Fri, 05 Jun 2020 09:29:44 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id h18sm12399821wru.7.2020.06.05.09.29.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 09:29:44 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>
Date: Fri, 05 Jun 2020 17:29:13 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, tom petch <daedulus@btconnect.com>, Last Call <last-call@ietf.org>, tcpm <tcpm@ietf.org>, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <12B81224-2A95-48F7-8365-636C0A0E7A4D@gmail.com>
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> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>
To: Mark Allman <mallman@icir.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/EEc3GF28yS-AhaQf_w-QJbkoutQ>
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: Fri, 05 Jun 2020 16:29:48 -0000


> On 5 Jun 2020, at 17:16, Mark Allman <mallman@icir.org> wrote:
> 
> 
>> Mark, that is what I am questioning,
> 
> well ...
> 
>> that by default loss implies congestion.  Historically true for
>> the IETF but I think that there are a growing number of cases
>> where it is not true as in a post I saw on another WG list this
>> week where a document was saying that loss MUST NOT be taken as an
>> indication of congestion so the MUST in this I-D I find too
>> strong.
> 
> OK.  So, I am not sure what to do here.  I will say several things ...
> 
> (1) I believe that as a general, default the document is quite right
>    in specifying a congestion response and exponential backoff.
> 
> (2) I believe consensus of the WGs has been the same as my notion in
>    (1) for some time now.  So, even setting aside (1), I am not
>    sure I feel like I have carte blanche to change this.
> 
> (3) I do not believe loss always means congestion and I do not
>    believe assuming such is always correct or should always be
>    done.  I don't think I know anyone who thinks that.  So, the
>    document explicitly says that is fine, just go get consensus
>    that some other approach is fine.  (And, that should be
>    happening regardless of this document, so I am not sure what the
>    big deal is here.)
> 
> So, basically, I am not sure what to do here.  Maybe one of the ADs
> can help.  Or, maybe we can set this aside and I can do the things I
> told you I'd do and a little extra framing will make this better.  I
> am all ears for advice here.
> 
> (BTW, I have a half response to Stewart, as well.  I am not ignoring
> his review.  I am just behind.)
> 
> allman
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call


A good example of congestion free transient loss is a link failure repaired 50ms later by FRR.

- Stewart

v2.23.0 | Report a Bug | By Email