Re: [tcpm] 793bis ready to go?

Wesley Eddy <> Tue, 04 May 2021 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 352063A1F78 for <>; Mon, 3 May 2021 19:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u_PWkHtEitZY for <>; Mon, 3 May 2021 19:32:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B88953A1F7F for <>; Mon, 3 May 2021 19:32:07 -0700 (PDT)
Received: by with SMTP id u1so3713542qvg.11 for <>; Mon, 03 May 2021 19:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=4kSzjHrrG4xqZF3D1nDE435H08jS3dUuUAaySlItRKw=; b=e5rkxIRvToMjmj94HhZ7tJ6PlTg3CVLrA3kPCMt4FJaNgMDDk2nz2HhsxNKVOdF38c OfRM0sLGc2fa89GPC4utc2++y2/PmJW/GTRI0A7aTeZ6R5cCc81urzn6EvJjV3WaWpKW egLdX1AuR0I9zWOG8R6m3BjWzzF/Qu4StapkIImYtd7XAxjTQm7ylvpscJTyh9DfDmKy 4lM+peyqDF+pOmCEPrO064/LgC4qSJgHrPNZOs99Sc3AkobmtulMVBY7ccOw5Kt94JhK 4Lvk9fXErldAdDTXGQfYA5l8T8Q+PRfRe4bNRwMqcY6yCl6//r/6dsl2vabzE8yllBAk nkaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=4kSzjHrrG4xqZF3D1nDE435H08jS3dUuUAaySlItRKw=; b=Oe1guod9ELn61c7nTVmLvFx5yoeY3RBOh421l8Ruv9GB/zvJqMlumNNdmYj6bQwan5 DRG7g6ORxnm49ghpYpz5M9hUGYGxtZgz0QUrQNi5S6IP7bHn7HIrsoODFFA45AyWMh2V qsl1yyfFy7Xea9jTYk9dPeIfW4gkwf/wKTTMWENt3ISrIMQ/rGPwmdriXaZhMoWq4Cmr Qva+Qt4SBgP7/UiSGkko5mw/NzYIajgKkhOqjKtIlMdRvLg1jYVRo+Ria+v0fWn0E8VO C+QpSjOKblh9tLUwDbJBqwOFs5ZdgygEAwcl7rGIBOD4K0aG4OiTqKsTjLtSXMnx0CIh mFhw==
X-Gm-Message-State: AOAM531mKIF4O8uNcJyEkfsMeSamWVkmgupzG6QlhL4f14eTdzAde3wg 9YPUcYtTU7YsC1Mcjlrs/kNHSDGrH+QNnNMc
X-Google-Smtp-Source: ABdhPJxDCXuA6Qd9qOptQh78MkyblJufYknFecvgAlFdBpPcpFe4MwuqWdw0A64z1VkpgazSLuuDuw==
X-Received: by 2002:a05:6214:19e7:: with SMTP id q7mr23098884qvc.34.1620095525561; Mon, 03 May 2021 19:32:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id d6sm1410452qtn.52.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:32:05 -0700 (PDT)
From: Wesley Eddy <>
References: <> <> <> <> <>
Message-ID: <>
Date: Mon, 03 May 2021 22:32:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C18CA978EE9655779AE08929"
Content-Language: en-US
Archived-At: <>
Subject: Re: [tcpm] 793bis ready to go?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 May 2021 02:32:18 -0000

On 2/16/2021 3:58 AM, Scharf, Michael wrote:
> I'd also be interested in more details. Unfortunately, I am not familiar with BSD.
> For what it is worth, RFC 1122 Section "TCP Keep-Alives" states:
>              Keep-alive packets MUST only be sent when no data or
>              acknowledgement packets have been received for the
>              connection within an interval.
> So, the latter part of the sentence originates from RFC 1122.
> Could somebody comment on whether recent BSD stacks would deviate from the proposed text in 793bis? That would be an important insight!

This is not answering your question about BSD, but just for reference, 
the change in that sentence came from consolidated review comments from 
Microsoft colleagues that was sent to the mailing list:

Section 3.7.4
"Keep-alive packets MUST only be sent when no data or acknowledgement
    packets have been received for the connection within an interval


It's important to call out an additional condition - that sends are not already outstanding. When a send is outstanding, it is retransmitted and serves as an implicit liveness check.