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

Enke Chen <enchen@paloaltonetworks.com> Wed, 20 January 2021 18:21 UTC

Return-Path: <enchen@paloaltonetworks.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 91B8F3A11B6 for <idr@ietfa.amsl.com>; Wed, 20 Jan 2021 10:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=paloaltonetworks.com header.b=lEoU6XVb; dkim=pass (2048-bit key) header.d=paloaltonetworks-com.20150623.gappssmtp.com header.b=TkJXM8S0
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 HFxPF0eCc0_j for <idr@ietfa.amsl.com>; Wed, 20 Jan 2021 10:21:01 -0800 (PST)
Received: from mx0b-00169c01.pphosted.com (mx0a-00169c01.pphosted.com [67.231.148.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716093A11B5 for <idr@ietf.org>; Wed, 20 Jan 2021 10:21:01 -0800 (PST)
Received: from pps.filterd (m0048493.ppops.net [127.0.0.1]) by mx0a-00169c01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10KIGaiD026263 for <idr@ietf.org>; Wed, 20 Jan 2021 10:21:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS12012017; bh=Q4njgdBg5uxcbMfvixu3nQaB/uxZOB92SrcfoIeQq20=; b=lEoU6XVbvUbRMasu+J/zpNQazSDqPtwRSr/h6UWuS9yT9ijrpVplqtKUFFRI1qFQYhu3 Z5GziAcH7Xi2Lqki5nrCk2m4/zCoOUnckEQ4K+/6tD4AqlwcmzjiTIqLoRbAbmC1WeYn fVVR5nWrGTjwWgD0iKmiS0qZQZ5cU74S/2b4niG+SVwJUhrUZEGru1NfOdYxgRTmYwAF GTuursch+WxXZpdg7W5aabfnlk61a/hFo3R5VLlnGe2XR9PreTiWAZ+zQm0tSOqurWe6 ddXjMfZT4EbUjKpb7rPRwhu1FV18Ugk9Pm0xEUW691kxTnUt/ZrZtd5Zhe1DunUBHbzT qg==
Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by mx0a-00169c01.pphosted.com with ESMTP id 3668p6f7ym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <idr@ietf.org>; Wed, 20 Jan 2021 10:21:00 -0800
Received: by mail-lj1-f197.google.com with SMTP id m9so512154ljp.16 for <idr@ietf.org>; Wed, 20 Jan 2021 10:21:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4njgdBg5uxcbMfvixu3nQaB/uxZOB92SrcfoIeQq20=; b=TkJXM8S0jixRRDGumnvjwg5PSSBX7EWFvSbo9b2QuYmzjYGNj07I2ZmneagGWbfoWf 0++Qv000y44HU17YV2DLmJZgrJ+2Iyi0rVMOPNF7TtSmK0nO4Y20iKTj5KOBAL56KXfa zLkfkx0HpY9Jbuphh764r3qmW7OIin7si3WUTJHz5zJjG7LQiFFO9gS6SUlwEwiJ3ojn NdeE5MRiO81f8wr72BXVXsQuY9sYCTGDM/ynighPUSjkyiB6Cc+bKCaplU5rui3Wz11I YPW15fVD91uomqruJXQtXtyhHf2M8yO8/n40j6ff4qgidimJmqDJvpvq9EKR6Nzf1zvp E8Dg==
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=Q4njgdBg5uxcbMfvixu3nQaB/uxZOB92SrcfoIeQq20=; b=RON5CdfCgfzUP0KxGDA8zfJUKBCgXfI5+AUyJIU5dZBB3K+VDuqWwbPJ4p+yvzNbZ/ GBOzADLxwMXeKbfYKY9JYR27FWcX0k8iWngVUNN1N8+VtICeQ2YlA5yHaKmJk6sSRKAw 0TwJyqNTkbYO/p8iZHjWtXRyM6DnkKZ+dB4X+P3n4cwg08jBlnaxQkRrXS5ckLdxsnM4 XFdSJzXIde57wYKIo0XTosA1fQqScdN8oR5cwbG36/9CE+Py36xrHC13h7+WATcjyosS 3pjOpLyAd41OcMJAcEW1IQA8c09giNlWUOq71AkWe8Q5YQt4bSbhUpcXxmOTYvp4HXGv UjaQ==
X-Gm-Message-State: AOAM533mhRnQFQtwSWJenTBAo+skXrQDJGtSGkMQzlfpy5RzpqNFFtxr 4SiT2wKd0SXgL/dvGvzqxvb2IY1qeO+sXvCuNIY+Z6PnBA+X3Zfpd6NOaCjcAKI1Bwq0/OCC2ZE GpmU5WoiEjlPiXYL3wlU=
X-Received: by 2002:a05:6512:1311:: with SMTP id x17mr4706922lfu.307.1611166858635; Wed, 20 Jan 2021 10:20:58 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyy9s3qrX/3yA7JZQGRze7ltjLdK7YUVfbI/UE3VKwR9MVvRbdUAgmc462izxsIb99A/8872KL5BE5wYy+GKrk=
X-Received: by 2002:a05:6512:1311:: with SMTP id x17mr4706909lfu.307.1611166858354; Wed, 20 Jan 2021 10:20:58 -0800 (PST)
MIME-Version: 1.0
References: <CANJ8pZ-WMDotkQvhN-NuP7ivZkPRR-9S2KJSar=6463U0VKkow@mail.gmail.com> <EFC56A31-1276-4DAB-9526-9C2F24814D2C@pfrc.org> <CANJ8pZ_LnDna_jtipcLJq9rrS3MM32rLdxRW8ntC2aEi9VvzMg@mail.gmail.com> <722A787A-5B83-4802-A9F4-AB2957BB3305@juniper.net>
In-Reply-To: <722A787A-5B83-4802-A9F4-AB2957BB3305@juniper.net>
From: Enke Chen <enchen@paloaltonetworks.com>
Date: Wed, 20 Jan 2021 10:20:47 -0800
Message-ID: <CANJ8pZ9K2+MS9cksczt2G4OTAiNwR5iBQp=0-UEXMS=nUNqLAQ@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000443de005b959048e"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-20_10:2021-01-20, 2021-01-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 clxscore=1015 bulkscore=0 impostorscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101200107
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fH4HCqfUPVQoTi7GI8OtPNn0OEQ>
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, 20 Jan 2021 18:21:04 -0000

Hi, Folks:

Here is an update on the TCP_USER_TIMEOUT option in Linux for the
zero-window case:

1) There is a bug in the code, and a fix has been committed to Linux's
networking git:


https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac

2) A patch has been committed to Linux's man-page repo to clarify that the
option also covers the case that buffered data remain untransmitted:


https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=1942e41202aa5cc39dd8970ab62cd1b288277753

Thanks.   -- Enke

On Fri, Dec 18, 2020 at 2:32 PM John Scudder <jgs@juniper.net> wrote:

> On Dec 18, 2020, at 1:09 PM, Enke Chen <enchen@paloaltonetworks.com>
> wrote:
> >
> > No, I am not assuming that packets are getting somewhere. The
> TCP_USER_TIMEOUT would work as long as there is "pending data" (either
> unacked, or locally queued). The data can be from the local BGP Keepalives
> or the TCP_KEEPALIVE.
>
> Apart from the other objections to relying on TCP_USER_TIMEOUT, which I
> think are sufficient, it’s not clear to me that implementations will
> provide the desired semantics. RFC 793 seems like it specifies the right
> semantics (“get this data to the peer within N seconds or close”):
>
>         The timeout, if present, permits the caller to set up a timeout
>         for all data submitted to TCP.  If data is not successfully
>         delivered to the destination within the timeout period, the TCP
>         will abort the connection.  The present global default is five
>         minutes.
>
> However the Linux man page documents different semantics:
>
>        TCP_USER_TIMEOUT (since Linux 2.6.37)
>               This option takes an unsigned int as an argument.  When the
>               value is greater than 0, it specifies the maximum amount of
>               time in milliseconds that transmitted data may remain
>               unacknowledged before TCP will forcibly close the
>               corresponding connection and return ETIMEDOUT to the
>               application.  If the option value is specified as 0, TCP will
>               use the system default.
>
> The important difference being that whereas 793 implies data written to
> the socket, the Linux man page says “transmitted” data, which seems like it
> must mean data TCP has written to the network. These are two very different
> things! If Linux (or another stack) implements what the man page seems to
> say, it’s not useful for our purposes.
>
> —John