Re: [tcpm] 793bis ready to go?

"Scheffenegger, Richard" <> Thu, 18 February 2021 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 013F33A1252; Thu, 18 Feb 2021 06:00:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7A-bHuv62hD6; Thu, 18 Feb 2021 06:00:10 -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 952543A1234; Thu, 18 Feb 2021 06:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1613656798; bh=X6is0+chGoqTDkd592HUcfHPYmE2EsGTVt0zRVzOYFc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fy98eXIXBe5rEFb4kd8MOpApXFBFh9YjwPpbhcy34eaHztlx/gnTVMn7wy8RjP12v LtPNL2r8xq7ud13bnPU9lp6ZmgewH9wRGKNILwQzs+4IPFRwfe1iUDr/bZjb/SkWDC vRzjrADrk5qdCm6g3E0D+mM9K340xMleCduJMkZA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1M6lpG-1lDHXM0PBG-008I0T; Thu, 18 Feb 2021 14:59:58 +0100
To: Markku Kojo <>, Michael Scharf <>, Wesley Eddy <>,
Cc: tcpm IETF list <>
References: <> <>
From: "Scheffenegger, Richard" <>
Message-ID: <>
Date: Thu, 18 Feb 2021 14:59:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:MSE/j3iiDDuCb+KV2dLCrhNtTLyIDcG6nYJpfNPsoJeFFUcipbY EnxG+W95TUoG6YMLshRRsZoJbY8yexYE5+OnJFa7faiCXyl2v+yKx21Fn0HGmE8cmZZHPw7 k0Sc5HdqA2LydX71bRezkheYbRDm+ZKLqkppAgpr0/+HBUtJgmbJZBnos03SIKJ4WVD7EWZ U7YsR5Z3/WGcGv8zCenrg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7ALn6zMJ6tM=:RQmLw7XUi1SFWCbw32FIEb CWa7xbvzf7aEqHkDpBRpAxHMbmoOFqapLo92h8R5fKy0z66DrGvs03VCHHpUDX9ydbna5pF6y lZLSFBCts11OyLx56LsEPwuwrgtXc72pdT7fOZE5pRBT+ihhy6D1c7BoQPq4PkE/81+GMnCdK 5C0/qRczAJAum+rJ0G0lwUOLx7XeqQcUtXss0tDbZ7Q2XOnWze5NWuQMg+t8U/zQJRLvUIS9c AS+NUUGJeNIwK0VRht5uxBGUog4jsYQVEZDVXaxrGEI4cGbijT0rkp0GQyavjICkfYrgCAm5o /TCk3BaBAjaNhqMtszQV1mmJKZtDCAOZ1+WcQBWhQjEnjkq4/7gKpTZiwbW/o35U10VMj12G/ jQSuyRLTrqEW0r4yeI/kBmHUd1UNE4eJ7JM2oe+U6Qjy4uffVCYNcSDMp0Oh3bNO+TF8g3W1V 7OduDb9rWOoneg8LqF3Ib7Vbs/lWLt8VBN0uphzzZEXMnxHIEzgcuKlW8KP91qHW+RFW3pgLR Q6q0gH81alWMUPwPlTO8++oZ/yF/drIyIzu3qstIbQELLrYv1gfHA4xxq7eXIHySARvQD5/eB zvYuzBLfLf+I8gP5zzy66ovQLrVRnSd8wjs5i3IbqQCycx6GEwmHxqHrWCDx/q6HFExdiF7Pr Xi+bOX+3PZ4HoCtVDKY4+ce1GhzUN32e2ICEPPJIO2Tg6ZwatZVjnLcunt0Lm7PYRBf+6JslL pY/dhkBiMcp9W5Hy+RzLqkp9YSzYzfotlBLDNJ8wEPaL6KE+wzXuQrG4qQfYWN0V+4azZoaEl HF2dCkJIPL9d5Wgpt33+0RG3bmt5J87c/IRl6aJqgBzQnI7AteFsbrhMoQFg+hoMk2vtzdPnH P9ImHERkOk4JHhFxeg1Q==
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: Thu, 18 Feb 2021 14:00:12 -0000

One more nit, around dealing with data-in-SYN,ACK

793bis (page 71) has this text, which unfortunately doesn have any
RFC2119 language.

But in short, it seems to require the transmission of a pure ACK just
for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowledge
the data.

The FBSD implementation was found to skip over the ACK-only-the-SYN
intermediate step (which must be acceptable, as that ACK may get lost in
the network), sending out only the cummulative ACK for SYN and data,
after having transitioned into ESTABLISHED.

But strictly speaking, this behavior is a deviation from 793 / 793bis.

Perhaps a "and should send it" would do, to allow this behavior,
conserving one pure ACK...

Best regards,

  If the state is SYN-SENT then

          first check the ACK bit

             If the ACK bit is set
fourth check the SYN bit

             This step should be reached only if the ACK is ok, or there
             is no ACK, and it the segment did not contain a RST.

             If the SYN bit is on and the security/compartment is
 >>>         acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
             SEG.SEQ.  SND.UNA should be advanced to equal SEG.ACK (if
             there is an ACK), and any segments on the retransmission
             queue that are thereby acknowledged should be removed.

             If SND.UNA > ISS (our SYN has been ACKed), change the
             connection state to ESTABLISHED, form an ACK segment

 >>>            <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

             and send it.  Data or controls that were queued for
             transmission may be included.  If there are other controls
or text in the segment then continue processing at the sixth
             step below where the URG bit is checked, otherwise return.