Re: [tcpm] 793bis ready to go?

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04B003A1F51 for <>; Mon, 3 May 2021 19:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ccgFuhB3sH6d for <>; Mon, 3 May 2021 19:31:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B13A3A1F4C for <>; Mon, 3 May 2021 19:31:16 -0700 (PDT)
Received: by with SMTP id j11so2102343qtn.12 for <>; Mon, 03 May 2021 19:31:16 -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-transfer-encoding:content-language; bh=CMKk77+iBZ3yOi3TPCfH3iVnCgEv/Z2C9K3kgyN4Wcg=; b=qKBMORajrCatQsqq+aIQONSpzs2yusfus+YCCN4KEa7qr+1dFEgYmOCFcAF+OMkrbd gkX+/ApGLef/PSwgkQAVRABhPzURlf+QZNWZnDL7wHDZfDp47oL1YuEAR1UxkOynCDD6 joKvKru6tC9dqrFRNiMpMTwP2cuPhIowNJAI9O+F8J7CXZT0ZTQ5M0A/8eLW7QkzXAAz Ewcz4QyJ7OBwOSWcuAUXybDUlJQS+dmnC38p3sQW68StvcEk3TaBKSEQrlFEIKG/+ljh hMro/CXMg3MaCr+944AZX33WfjOYhOmsuDpIrwKM0en0RXJsKcIgrd7pDulExGWeKFHf foJA==
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-transfer-encoding :content-language; bh=CMKk77+iBZ3yOi3TPCfH3iVnCgEv/Z2C9K3kgyN4Wcg=; b=UEHpPo5rr8OmYQIfNjlD1O2K7c0Su6eyJlFWR/IzpQCExKwkbVcc4SlcVbFahptmlT ovAzt0dle9RjpLdiPfGK3TGFZ7h8R6OHc7FvOVXKJJqBFEJ/K2wcI3zdRfGqGE43qpZq tUjLqbDfHUUmFM8ozRRDDn5icNB2I4BoSI5HSCPF4mF9mDi+l9YaBuP0d+PWX9wZLY4l gBqnyghsdwo1a/YymaPpWpCjZYNHMkFmKi+sXw94UdThKjRes1Hqapsczg3M2a4Q1pjj 6GMXev9rqXslS2TGZyr4XOpvb5bMKU5Q0vyR6aoMcm6Rl6gK5kFR2UWpv75wdpcD5FNc 4xDA==
X-Gm-Message-State: AOAM5306vGuXfIsVsA8P25Wq8GPOhPL+Nggki/PrwIWWDA6C2mzJCBs1 LhPe5TT6M275QP+C9LexNYa5goneoS/KErIX
X-Google-Smtp-Source: ABdhPJyev/zpSttLiCdkADH6GpFeUcsqLMm17ADng62jizpoLlsxFkq1xUS+PeZ3XXrGtdDRuPTN/A==
X-Received: by 2002:ac8:5d46:: with SMTP id g6mr7356370qtx.348.1620095473177; Mon, 03 May 2021 19:31:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q126sm10054338qkd.48.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:31:12 -0700 (PDT)
From: Wesley Eddy <>
References: <> <>
Message-ID: <>
Date: Mon, 03 May 2021 22:31:10 -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: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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:31:20 -0000

On 2/10/2021 7:14 PM, Yuchung Cheng wrote:
> I think it's ready. Kudos to Wes for the N-years-long effort to put
> this together!
> Minor:
> The less clear part is the wording of "idle connections". Idleness can
> be interpreted in several ways: no recent rx, tx, or both {on the wire
> | on socket interface}. It'd be good to define more clearly. AFAIK
> implementations have different definitions already leading to
> different KA behaviors.

You're right the definition was only implicit in the text later on, so 
at the beginning of this section I've added:

             A TCP connection is said to be "idle" if for some long
             amount of time there have been no incoming segments 
received and
             there is no new or unacknowledged data to be sent.

How to configure that length of time is dealt with separately later on, 
so I think this should suffice.