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 B4A1F3A1F66 for <>; Mon, 3 May 2021 19:32:04 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Gw5xevSmMp4Z for <>; Mon, 3 May 2021 19:32:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48C8D3A1A23 for <>; Mon, 3 May 2021 19:32:03 -0700 (PDT)
Received: by with SMTP id o5so7269991qkb.0 for <>; Mon, 03 May 2021 19:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=i4dPDhPAsQwCsMfIbw4zAmSS+aZMia9tpTnuJ5h6y8Y=; b=p2ISR6gOGsHpC2f0bwIpOpRV4b9IboZPWAjV1AkhO0RWaJsflnUF54OblRPVurJbF1 Iq+l+blZ3qMBeGnzDqhSWFHxvuDDzMINZnk+6LGk55koJ1FxrjcgyXQLYxYDdcIGZtTp QMK5vS81/wZ1t3NYVjv7FsYP8YzH3z647Zz+NDarBNVtl3mA95wwT0GTyOXRmYmmb+/3 W4Cv7WO+FT2o/kWDz/BRsGVcnxdSR6Jb6+eLZc0ny3MKAxfJwqRbjo1x+R8sFZ7okTNa yVDdQg6Gx3FDYYKnJm5xCtMtX82antsZrYqgtqlit54AyWDYrrRDYYASWPQ1V6mbsNoF fTJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=i4dPDhPAsQwCsMfIbw4zAmSS+aZMia9tpTnuJ5h6y8Y=; b=KeX0wIiOuVo4Aewrh0Lr9XEjPoi9lbGt0m4pdKLI1V2+WtnhVTzStcbYLaEtLvOr1j A3sPhVMw5Fj43WrAsBriO5UhmxBQC5DWedaAnxnFbAQbJsV/oB5SZ9FvtatUMIjbFgRw Zz9eKLfn+rWYF8pycfBpxP9+dNGdtUBBSorKIz0eRNbpx4aW+3j9npKxAj9+SAUyIsyu X/gZH/TdP2EpbBhp3aGx+HYrxLi+eV9YDpeyshOA+5KQ7khA75Bd7tM576lA+YriUTLq li3Idz0BzreD0hE5gbQ4eDx5hDOpGPiEeddsa6cHH4uHJBknfgh//JkdX5ugJdKq0ryh OrTQ==
X-Gm-Message-State: AOAM531zwKCWR+dKFXd9tsqENowqmEHSsd335s5LyrjLBQu6qzTpPUp4 RP6xWz7TW05cZ8aEx2Wg9FXHBg==
X-Google-Smtp-Source: ABdhPJzYLewZrzayUUzO6JiCUt1+sUTVIQBb+eWowH8aOpMqLztl4OCw1p+YlElnqF1xAo0hxB75Dg==
X-Received: by 2002:a05:620a:786:: with SMTP id 6mr15763814qka.196.1620095520612; Mon, 03 May 2021 19:32:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a21sm10259628qkk.45.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:32:00 -0700 (PDT)
From: Wesley Eddy <>
To: "Scheffenegger, Richard" <>, Michael Tuexen <>, Joseph Touch <>
Cc: tcpm IETF list <>, Markku Kojo <>
References: <> <> <> <> <> <> <>
Message-ID: <>
Date: Mon, 03 May 2021 22:31:57 -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="------------63E54875783599F25EC6FCB6"
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:10 -0000

On 2/21/2021 9:33 AM, Scheffenegger, Richard wrote:
> Well, making the transmission of the ACK-only-the-SYN optional when data
> is present, which needs to be ACK'd anyway..
> That way, current FBSD and Linux behaviour both would comply with
> 793bis, while I agree with Michael T. that the behavior of FBSD is more
> efficient.

The different behaviors seem important to document, though it wasn't 
clear to me that the WG thread here had converged to a specific change, 
so for now I simply added note of this condition:

    Some TCP implementations suppress sending this segment when the
    received segment contains data that will anyways generate an
    acknowledgement in the later processing steps, saving this separate
    extra acknowledgement of the SYN from being sent.

This is kind of a weak statement, since it doesn't really say whether 
this is "right" or "wrong".  If there is agreement in the WG, then we 
could make a stronger statement.