Re: [tcpm] 793bis ready to go?

"Scheffenegger, Richard" <rs.ietf@gmx.at> Mon, 22 February 2021 10:18 UTC

Return-Path: <rs.ietf@gmx.at>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84CD3A124F; Mon, 22 Feb 2021 02:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufcCjQ6KzVa0; Mon, 22 Feb 2021 02:17:58 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B12B3A124D; Mon, 22 Feb 2021 02:17:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613989056; bh=S8Px7+1jL7UAOwjcXBUGL33o+wmLJJTnnuD5REww+ew=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=RkDtDJ4eWwewuh923ciAegjfodh5VRe6ZwF48qvu9JgloUioXVFKofVJsI7/Aan9B uHTvpeeYGmuB3RZ3JRdRdfyMcpwmywd0wwWACxHtacD5HrzZj57oOeJMA9qbskr9Gl NxU+bGnizvPDuYbDfxQl3dyvXBVpECpZDFsNLua0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.199] ([178.165.129.182]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1Hdq-1lFnFC04zq-002ojn; Mon, 22 Feb 2021 11:17:36 +0100
To: Joe Touch <touch@strayalpha.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: tcpm IETF list <tcpm@ietf.org>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
References: <D7F636DC-E133-47F6-87A5-5BBEBB5D5C85@lurchi.franken.de> <37D123C4-03F5-4D14-84C2-849C5B7B94F1@strayalpha.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <35688a2b-a802-7092-46b8-6e18090123de@gmx.at>
Date: Mon, 22 Feb 2021 11:17:34 +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: <37D123C4-03F5-4D14-84C2-849C5B7B94F1@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:x/4LuTcQ7e7vEYnT/mxwISoZnBru37i/hmd/At0Q1WU97flz+x4 /z0gtdJHIOk0++Gtduu6ZvXW1y2Tx4Bj5hH7xeNiqkBU4lhE5Etex7DwXFSkgV5IVcg3EOE HwntTQmpmUVq5oJZQaPb3Xx5d9nc34wDN+sj9Rmsj8NjvgU02+LzFwF2E7plwuaZfwx939X WsdsKQFuHc9/C+DQfWfhA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:qAvoHa9sEaI=:MgQgjC+IBAojcvmO/tuRmM yjQNtGW8XTtilg55FZHflgtECwTjfKxpgZFbp4UXRw2YqDKO1cpphlqSJsKxAESrtG6gl1BNI LyLZ1h4CrmQPvRYWcTfFbYohWMVH5EZ1UqAcx+ofdFO95DLfkKTdWDJnB2MK/Q9EQqUsXs+86 yvZgrGdcCi2eWtAGcAM6RYnngZ66KQEWgOG9gdHyT0Ql11+olFIoAIL0ALz+wkiI0mMoxm/OW MMYZZw5Urzh2GR7eeSsjSv5Ziskdx+PkeuZfZPjP1Q1xJQaLlybMqpqOpiMCfTBHxRrCwcRz2 fEFzcRNLPVi3yPUYTSLF0Oz7onwcUR9zV+UUIPJVmevOs86HZrA+xiUpyBjqYbXl5190iykNa E/+HeinfzwIaIxeaYajQ6AKQPJCH9d76Q4uBmQ55nRXJO3QIvn3oYur9SUHDzSiLuvvwBD89m HcpgZc8uHZVx6eIQz9Dbrw4DB8F2/AQrQwk9A8gTW7OiQGQ2ngwErIyovpaUUX0PNP7UHHkoH 7yzhMklSLcuuLduKXUAOgyEo1CMMLV8FbxX9AwdrqBO94xaVtBkJ6wbeKI/nc0ztbcPzFhiqu zwrFgiP+WGkSEZ3akuQ3XNpoxTjTGqBP3vqvNNW20df/6j4PZpH5hWwzuqFrZ44noMbo/89ti uIOx536f1noT4cooT7IKhjEnAzBPlTeAoQMSVhPXjtGGZTb+DAvr1QTRDUOEXVg31vop4IBA6 TfwAvBX7/pHGMYxwrvtZCBDKofiWvyJKujEE+tdhhr0/NlEuqtkEVCn50HELeknYf5TubWpem XdZkZEjZBKnbR2FPPhZZHQl7D8n1M07zICTPksl2aCCTklsZ69INIa+dwFYFR9Bh92QH4ox47 Y/4aqSgsLYVbmKGJLIdg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SCEgBs9dA9sxXGSbeX_MgxX424A>
Subject: Re: [tcpm] 793bis ready to go?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Feb 2021 10:18:01 -0000

I also like the word-smithing the two of you came up with. That text
reads exactly like what I would like to know in that instance, where I
to implement the behavior.

Thanks!

Am 21.02.2021 um 20:39 schrieb Joe Touch:
> Works for me.
>
>> On Feb 21, 2021, at 11:16 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
>>
>> 
>>>
>>> On 21. Feb 2021, at 19:38, Joseph Touch <touch@strayalpha.com> wrote:
>>>
>>>> On Feb 20, 2021, at 1:53 PM, Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote:
>>>>
>>>>
>>>>
>>>>> On 20. Feb 2021, at 22:37, Joseph Touch <touch@strayalpha.com> wrote:
>>>>>
>>>>> Even if you prefer the FreeBSD variant, the text below doesn’t appear to fix this; it will end up sending the SYN-ACK of the received data *and a second ACK* at the end of the sixth step.
>>>> I think the idea of Richard is that if the text is
>>>>
>>>>         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 should send it.
>>>>
>>>> Then NOT following the should, but only send the ACK at the end of step 6.
>>>> Wouldn't that work?
>>>
>>> FWIW, I think the case of combining the bare ACK with the ACK of the received SYN-ACK data is already covered in the sixth step below in the following text:
>>>
>>>         This acknowledgment should be piggybacked on a segment being
>>>         transmitted if possible without incurring undue delay.
>>>
>> I agree, this covers it. But it would be good to have it a bit more explicit.
>>>
>>> If this needs to be made more explicit, here’s my suggestion:
>>>
>>> OLD:
>>>
>>>         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 which 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.
>>>
>>>
>>>
>>> NEW:
>>>
>>>         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>
>>>
>>>         Data or controls which were queued for
>>>
>>>         transmission MAY be included in this segment.  If there are no
>>>     other controls or text in the segment then send the ACK segment
>> Maybe:
>>          other controls or text in the received segment then send the ACK segment
>>>     and return. Otherwise, continue processing at the sixth step below
>>>     where the URG bit is checked, either sending the ACK segment now or
>>>     piggybacking it with the response from that continued processing
>>>     (as noted therein).
>> I like your proposal (maybe with the above suggestion).
>>
>> Best regards
>> Michael
>>>
>>> Joe
>>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>