Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 16 December 2020 01:07 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F396A3A0A4F for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 17:07:46 -0800 (PST)
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 JrAjnca8jK6K for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 17:07:45 -0800 (PST)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 0D0163A0A3E for <idr@ietf.org>; Tue, 15 Dec 2020 17:07:44 -0800 (PST)
Received: by mail-vk1-xa33.google.com with SMTP id d6so2703704vkb.13 for <idr@ietf.org>; Tue, 15 Dec 2020 17:07:44 -0800 (PST)
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=7s/B23S+TLSZfKTajC20BH3WSSPimiCEwOBgMe5v/vk=; b=fPg4FGIHQ7/ouEYG8FsEvGFI3XjV7EthZwsDj6A4PHSiF5BWJwNVGF6z8XPckeaRvO IcRfQBi5KdP1nCvebD21qtACvHWq0PdLdH6qTkKkFLYoMCfRa7xbUJifu72OjBikqO/4 sOV9lfenMOTwydd6FLaZ9UuZZtodi6UgZ2OwaLt2GDB9aVjpAiG9LCM4hIGXWG7jd1eH m31q2JO5wNP9Wzv1GAmLH+QeGNHTeTRH4Oap2SZB7C17TGE1SQfZDB/t9ZZ8it4rgMGa LYM0TlNOOcdH7sTpfPncdnCELhH5WIWz6CV2ximDbBZBshOeb4OX7xQVPRSVTqiaL2cW h9lw==
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=7s/B23S+TLSZfKTajC20BH3WSSPimiCEwOBgMe5v/vk=; b=ryTo/66cA3TtHNy14F6f+ZNfWa3ogrIDyaKfqGK65hMnqbngy9NFoylqqY6qlMxhbW f3RGd06uf/7rWjkeITf5aPKTLNt+2DII/eKpniF/lXg2jDNPXQ44cG8GcTUdmLsxKkRe ZLycPWu/lXl3CchNuiUPPqZjQZOrS6Vzvjih4O+oQaWb+8t3ijv5u6q70ysUif0LTvIv tMMDqIu+ASe5JgWyzuQbP5jExlKOW0R6kb0bhWBDqeHKit0MBmqFpihWC3NmzdsWjOqi +POVfnUB3ggwWoIVRysW3a3Qh1kn7dgJqD6HAtwSO5vVzxcCpCF2AdvZQpo/XjJEWfAg /PNA==
X-Gm-Message-State: AOAM533xyYe+/NTuDBP8Hnc+qzlh2Qtedr9SNcfUUqqKHPdbKy3MIx4y 5SAWJEZBdPhDHX4OXsNIWcCatjQOHdwGEoV/188=
X-Google-Smtp-Source: ABdhPJyfX+Dq4kSGDN5zdGzs21XdXWDM+QPsUJ/PrmIKnciAJeZLPmvGa2x5XWDp55cWNsbXf7Oy/siZr9XnpfSYO1U=
X-Received: by 2002:a1f:1105:: with SMTP id 5mr15377244vkr.17.1608080864012; Tue, 15 Dec 2020 17:07:44 -0800 (PST)
MIME-Version: 1.0
References: <X9PHRuGndvsFzQrG@bench.sobornost.net> <CAOj+MME4OHmoqJfzNQ4Tj6+wCd1kJVHPfJsDbk_+Xh8fh5G8Dg@mail.gmail.com> <6F7C5906-51A8-43C2-8AEC-3DB74CB9941F@tix.at> <1B4E7C9D-BBFE-4865-87F9-133ACE55D122@cisco.com> <22C381D0-2174-4828-A724-FD97B2FE0BCB@tix.at> <9D6268BD-C555-4B9A-A883-9B55EEB5D5DA@juniper.net> <91D9B9F7-0DBE-45E6-84D5-2E3D9F8C44A1@tix.at> <X9kweQ5EtTL7tOAM@bench.sobornost.net> <B6F84ED2-E673-4798-AF89-DFC25EC2CCBA@juniper.net> <D94B0E87-30F7-409A-BCCF-D924F652151A@arrcus.com>
In-Reply-To: <D94B0E87-30F7-409A-BCCF-D924F652151A@arrcus.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 15 Dec 2020 17:07:32 -0800
Message-ID: <CAH1iCiow1=M2s-fEbDga2-bWJ4ArGX2erLaiy-hx5Rxnk3516w@mail.gmail.com>
To: Keyur Patel <keyur@arrcus.com>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Job Snijders <job@sobornost.net>, "idr@ietf.org" <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary="000000000000ab6dca05b68a809a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-pYeA8p2z3q6QpAwEc7lJKu-O_k>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 01:07:47 -0000

Top-thread-comment-reply (apologies to those who consider it rude).
I think this may boil down to what some of the knobs or timers measure or
impact.
The current combinations of knobs/timers in the BGP protocol are being used
to infer stuff about the TCP situation.
What really matters is, is the thing at the front of the BGP out-queue
stuck or not?
And by "stuck", the meaning is "stuck for whatever $TX_HOLDTIME is".
Attempting to infer that by adding anything to the queue itself is likely
unreliable or misleading.

Suggesting (but not requiring) implementations determine this situation
more directly, either by looking at the TCP window, or by literally
examining the out-queue, or any other technique that works, is I think what
Job is saying is required.

What to do when that situation is discovered should be pretty clear.
Nothing is going out, and nothing other than RST is likely to prevent bad
things from happening.
Any of the other corner cases being discussed would not align with the
described situation. If the queue is progressing (not necessarily draining,
which implies getting shorter), other mechanisms/techniques can/should be
used.
Only the case where the head of the queue isn't being sent is the thing
that needs to be handled, outside of the BGP state machine proper.

If I have not summarized the problem statement or required response, my
apologies, but I think making those two (problem and fix) as simple as
possible is needed to make *this* queue progress. How's that for meta?

The only correct response amounts to "kill it with fire". And I think
everything else should handle the situation on the other end. If the other
end is in a mild bug state but recovers, that's great. If otherwise, the
resulting withdrawals are a necessary side effect to keep the Internet
running.

Btrian

On Tue, Dec 15, 2020 at 4:55 PM Keyur Patel <keyur@arrcus.com> wrote:

> My comments #Keyur
>
> On 12/15/20, 2:56 PM, "Idr on behalf of John Scudder" <
> idr-bounces@ietf.org on behalf of jgs=40juniper.net@dmarc.ietf.org> wrote:
>
>     It came up earlier in the discussion that HOLDTIME serves at least two
> different purposes: neighbor liveness detection, and as a metric of BGP
> protocol health. If the proposal is adopted, the former use is potentially
> problematic in deployments where the hold time gets cranked down to a very
> small number.
>
> #Keyur: Yep and it has been cranked down to a very small number in number
> of networks.
>
> [*] Of course, you can argue that this is a bad use of the BGP hold time,
> and that the operator should use BFD instead, but sometimes this isn’t
> done, for whatever reason.
>
>     Because of this sad state of affairs, it seems to me that if we adopt
> this proposal, there should be a new hold time introduced, call it
> TX_HOLDTIME if you like. It could have the same default value as HOLDTIME,
> but (and this is the important bit) would not inherit any non-default value
> of HOLDTIME, it would have to be explicitly changed separately.
>
> #Keyur: The TX_HOLDTIME would need be negotiated with a higher value
> (lower negotiated value can result in sending speaker somewhat abusing the
> receiver speaker) being chosen. __
>
> Even if you have a new value (negotiated), it isn’t going to always solve
> Job's problem at hand. __ Assuming receiver is stuck it is not guaranteed
> that receiver would reset the session (sender would have to do it anyways).
> Then why not have a sender implement a knob that essentially says the same:
> Reset a session if a sending speaker cant write for more than configured
> interval of time (or 3*Holdtime or Holdtime interval).
>
> Regards,
> Keyur
>
>     —John
>
>     [*] I assume this is obvious; I’m prepared to detail why if people
> don’t agree.
>     _______________________________________________
>     Idr mailing list
>     Idr@ietf.org
>     https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>