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

Enke Chen <> Tue, 22 December 2020 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8AC03A0940 for <>; Mon, 21 Dec 2020 19:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=CX218wh0; dkim=pass (2048-bit key) header.b=HWiyqkDq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hWqJ-B4u4Zs9 for <>; Mon, 21 Dec 2020 19:21:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDEBE3A0936 for <>; Mon, 21 Dec 2020 19:21:00 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id 0BM3JaVt016205 for <>; Mon, 21 Dec 2020 19:20:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS12012017; bh=ePmZSJbZcPlIApPo4EcpGAW6Ke+3f9RyhV1i90/IDO8=; b=CX218wh0i/0xLyTuwdlOekisNSqaLa87fd3l0CqzedKK6BwGufG+oeYMwe9v077XguYt Mk68ElgEoYAPgIxuIDxMGOajGLIpoKK6i2QYTmotPQWtY5yPdstR9Ee97lzSwhSvQ9KO lRnlB+R0+fnAz0uHwca40rKuX4SD7GqHkbtjfiOSKMq63tD0MLFfNC+pZTYofoEyIfLf +jU7+NlbvJg3334ECT0gYwln1svfEyVSJmMPfrZlZXH33xgORHtaylDSyZi9Ss3JDYgL LUSTRGTkvaYVWzG2SFhL7w2wbRAU0SpezWj+nqjM2z3oRYVd6o1I2p/gcsvfxsIZKF7q 0A==
Received: from ( []) by with ESMTP id 35k84m89tf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <>; Mon, 21 Dec 2020 19:20:59 -0800
Received: by with SMTP id m20so14401687lfl.20 for <>; Mon, 21 Dec 2020 19:20:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ePmZSJbZcPlIApPo4EcpGAW6Ke+3f9RyhV1i90/IDO8=; b=HWiyqkDqATEFuCNh0XQrqMgBkjB6I/L3NJ/VLuAczZCGxlPwGIrqbCIEemkaE/5bGF rPx3Ktsxo36bRnvS1BtatXLL7CpYaXm1Km/63c93uN39X2HTtq0Kahs8ub8R3qVYHiT7 LpyMd8PxC0P8F+rD5UDhIWrmiU/7ky2K61/TRbwHnK0qIedOCIrRGLpCgp0IVq1QBU7R AXXdwa6TXyD7n7pRLShgBAqXufiXjKk0vCKWSIBns61IZh8qIUWqhJipHd9xvUweSGAn XPNfoSNWsUSw7qlfeYoW13OO+9AdJ6/akSzLiHIZ6iwZTKzSDhkLgPtjNgNt6fWTN86f GPEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ePmZSJbZcPlIApPo4EcpGAW6Ke+3f9RyhV1i90/IDO8=; b=rrFlU4tpGFf8G48J4dQD6RyHqhnx4r1DUkPTE8h2uA6p2wB/b/MuUTliyiSbabSbeo 5j6cEOuCo83tKcJFHM4vWm7DAcprpszAFP96WkCIBGr3sEDyPCC1mC+VS4pzAJICGTCN aX5qapDMqm6LprvssF641n6idru5xwDTXXkiblJitgM4vn/qpyPRpIb/xYSSTQH/R2HX AGyCdvEdacOVNQeg4eWRQoZdF2D2Pm16a6ZXe9XbUepGf3cxi0xzYsr6NW9Jt4qQXLLQ m1o6QcpTBJK5e4iTTQXtg3xmWibxpYB7tZtoiy5FziYsrVCVbqkOwASO3TqAXNSnLmQw A+yA==
X-Gm-Message-State: AOAM530sRUwNrR+IupKHYalHnSm2iE2+GRyz61iU0YT8yumyIoFAvhl+ /q/CSUf6zK3ZHrjkVeIJPITfbwGAQm+UujRmudZXNOEWfTmiSNvc0KsQ7vENYCRF/H+FHVS5IVE svNX2XVO+zrKAuMO8veI=
X-Received: by 2002:a2e:9151:: with SMTP id q17mr8474684ljg.475.1608607257241; Mon, 21 Dec 2020 19:20:57 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyEyrwogaVU0SYbX1N8BXe5O8Lcvvs5lV+iMcGYxHnMNBofqZCr0Ls0Hc1duylCJs/HP1Ym08eUjqeLelgwiC4=
X-Received: by 2002:a2e:9151:: with SMTP id q17mr8474675ljg.475.1608607256977; Mon, 21 Dec 2020 19:20:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Enke Chen <>
Date: Mon, 21 Dec 2020 19:20:46 -0800
Message-ID: <>
To: John Scudder <>
Cc: Jeffrey Haas <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000022c29e05b7051000"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-22_01:2020-12-21, 2020-12-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 adultscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 mlxlogscore=999 suspectscore=0 bulkscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012220022
Archived-At: <>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Dec 2020 03:21:07 -0000

Hi, John:

I checked a recent Linux version (v5.10-rc7-149-g33dc961), and confirmed
that the per-session USER_TIMEOUT value (icsk->icsk_user_timeout) is applied
 in all these cases:

  1) tcp_retransmit_timer()

     2)  tcp_probe_timer()
             For zero-window event: when there is outstanding un-acked
data, or buffered data.

     3)  tcp_keepalive_timer()

So it seems that the implementation does provide the desired semantics
described in RFC 793, but the man page is out-dated.

Thanks.  -- Enke

On Fri, Dec 18, 2020 at 2:32 PM John Scudder <> wrote:

> On Dec 18, 2020, at 1:09 PM, Enke Chen <>
> 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
> 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