[tcpm] Re: Discussion on whether the TCP four-wave mechanism can be simplified to three-wave mechanism

Yoshifumi Nishida <nsd.ietf@gmail.com> Mon, 26 August 2024 07:24 UTC

Return-Path: <nsd.ietf@gmail.com>
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 9AE5AC151557 for <tcpm@ietfa.amsl.com>; Mon, 26 Aug 2024 00:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKa1W7JC6zHk for <tcpm@ietfa.amsl.com>; Mon, 26 Aug 2024 00:24:57 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AED9C151552 for <tcpm@ietf.org>; Mon, 26 Aug 2024 00:24:57 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-e115ef5740dso3940821276.3 for <tcpm@ietf.org>; Mon, 26 Aug 2024 00:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724657096; x=1725261896; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yHNASc952VghWSveIXTQh5aqnq0kw2i6FL5Ec7wOkM4=; b=AF0+eYAhmETkuujP/nBZJL1+5+XOeivDNeUk2V+ms8lJ8sjELXDn5kvtui6zgtkUiX 8l+SNTV9E5TlMUPwp6ShRmjpPrxYcDWlmY3Khq52M0E4CGAZF/NmRLHRMx/tSTS8S154 8BYQk81BgdRDsSsspoXeaYK/zLI7/vEBa+B18oncFSznqPAjt1Op0gdaWn1yxSSreDYU b5cQLB9PQy+tKbPp5FWAUKsRill/V0JIToBZZ5RojZJ8b04Mi0T8YsYU++erx43V2s2b WWQoeyoLaiIqk9AwkH0MPV/6KMRgMZM032iAwBnRrKBuDpmnL1yDIyJYqYANjWW4Jhlk S5xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724657096; x=1725261896; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yHNASc952VghWSveIXTQh5aqnq0kw2i6FL5Ec7wOkM4=; b=QooFzkbIIZ3Pdr2MIqyGnhHfVoNIAZMmHDhv09mYDfW6sLb7d0GeNDhd+D5jRtSYb8 ggbU4rWvPju5sDlvXe2itS5UQPVaoFVKEfqvUNtpDBPYMIv6hU91BOpc22IecB6I/f7L b8YBNpRHat8amQzsju9pOlwExuQ4fauYWtfRGocKD/uMYQR/iD1ft3MR/6WeO+C/wZNh WDzpY7BW4M7SHpMp5HWP75UqSGbTZuQknnnsg4WqFASIFFGPDzYhOD85x7zZOp7cbC41 17PkHgER6dQ7tajfjGntFCUr7lRlbLkWcoW3E6A4pj3Z2KeT7kfvL6nrFrnGBn6EgaMF siBQ==
X-Gm-Message-State: AOJu0Yx7H9/b1F4TN2cn2lXEcHuA502lfHjEJV34NjReMBBT5gZoiBDF O/NUMNA1lahhu6yctYy5lf34tpM8ZwhWWfaaATNTEO9BGZ58ai8+fGrWpuS0YnjLYrE2oUPuxFy +99WblqxIyvyspv+bKbDks0cgUqMUcjUC
X-Google-Smtp-Source: AGHT+IF+qqxvovsIbxnp5zJ/rtS4TtoYBZdfNUWQ5xW74YzY87yf0BVcKqCDVOkVbQDMV78HA6M/r5LvPuR+d8G9X3c=
X-Received: by 2002:a05:690c:6603:b0:649:8f00:5254 with SMTP id 00721157ae682-6c62432046fmr101597887b3.1.1724657096175; Mon, 26 Aug 2024 00:24:56 -0700 (PDT)
MIME-Version: 1.0
References: <6defaffd.3f8b1.1917c9c2f23.Coremail.yangbuwangchuxin@163.com> <CAAK044SZyk5LJwohkJ-Fjk1rZidq5fGKXHYBBxgUWh45aiijXA@mail.gmail.com> <55af587.448d8.191885dc7d7.Coremail.yangbuwangchuxin@163.com> <CAAK044TDm72yUxxhkbtYk7O0cRL5vE35kYp+1Q83S9vbdw0jPw@mail.gmail.com> <383509b2.45497.191888db1eb.Coremail.yangbuwangchuxin@163.com>
In-Reply-To: <383509b2.45497.191888db1eb.Coremail.yangbuwangchuxin@163.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Mon, 26 Aug 2024 00:24:44 -0700
Message-ID: <CAAK044Se=KKaUDpL4=kBARJrsNVKu85ejDC2i7sFUVBD1tTJRw@mail.gmail.com>
To: "yangbuwangchuxin@163.com" <yangbuwangchuxin@163.com>
Content-Type: multipart/alternative; boundary="00000000000093bb7e0620910531"
Message-ID-Hash: EO42M23V4T3ANB6PZ47CXCCMSMMVS4YN
X-Message-ID-Hash: EO42M23V4T3ANB6PZ47CXCCMSMMVS4YN
X-MailFrom: nsd.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tcpm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tcpm <tcpm@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tcpm] Re: Discussion on whether the TCP four-wave mechanism can be simplified to three-wave mechanism
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/nTnfLQ7gzp1le2ag7u4Xql-m6-o>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Owner: <mailto:tcpm-owner@ietf.org>
List-Post: <mailto:tcpm@ietf.org>
List-Subscribe: <mailto:tcpm-join@ietf.org>
List-Unsubscribe: <mailto:tcpm-leave@ietf.org>

Hi Yang,
I think aggregating the 2nd packet (ACK for FIN) and the 3rd packet (FIN)
is theoretically possible if you want to do it.
--
Yoshi


On Sun, Aug 25, 2024 at 1:02 AM yangbuwangchuxin@163.com <
yangbuwangchuxin@163.com> wrote:

> I find the picture,When the server has no data to transmit, can the second
> and third waves be combined to reduce one wave? Because it has this delay
> mechanism, when there is data to be sent, it is sent, and there is no delay
> waiting. If something needs to be sent during the waiting period, can I do
> an ACK confirmation to send the merge?
>
>
> ---- Replied Message ----
> From Yoshifumi Nishida<nsd.ietf@gmail.com> <nsd.ietf@gmail.com>
> Date 08/25/2024 15:34
> To yangbuwangchuxin@163.com
> Cc tcpm<tcpm@ietf.org> <tcpm@ietf.org>
> Subject Re: [tcpm] Discussion on whether the TCP four-wave mechanism can
> be simplified to three-wave mechanism
> Hi Yang,
>
> OK. It seems to me that you're suggesting that when one peer sends the
> final FIN, it can terminate the connection without waiting for the FIN ACK.
> However, if this FIN hasn't arrived at the other end, the other end cannot
> know the peer has terminated the connection.
> My concern here is that the other end would be suspended in this kind of
> situation.
> --
> Yoshi
>
> On Sun, Aug 25, 2024 at 12:09 AM yangbuwangchuxin@163.com <
> yangbuwangchuxin@163.com> wrote:
>
>> yes
>>
>>
>> ---- Replied Message ----
>> From Yoshifumi Nishida<nsd.ietf@gmail.com> <nsd.ietf@gmail.com>
>> Date 08/25/2024 15:05
>> To yangbuwangchuxin@163.com
>> Cc tcpm<tcpm@ietf.org> <tcpm@ietf.org>
>> Subject Re: [tcpm] Discussion on whether the TCP four-wave mechanism can
>> be simplified to three-wave mechanism
>> Hi Yang,
>> Are you referring to the 4 way close in TCP? and you want to make it 3
>> way?
>> --
>> Yoshi
>>
>> On Fri, Aug 23, 2024 at 5:03 AM yangbuwangchuxin@163.com <
>> yangbuwangchuxin@163.com> wrote:
>>
>>> IEFT Hello, I am a Chinese computer major student, I have an idea is to
>>> study the TCP four wave mechanism, if one party still has data to pass,
>>> continue to open the connection. However, if both parties have no more data
>>> to transmit at a given moment, can it be possible to dispense with one
>>> wave, thus turning four waves into three? (Go straight back to the finally
>>> state at the end of the third time.) For example, is it feasible to go
>>> directly to the last step, that is, to change from the original four waves
>>> to three waves? Is there a theoretical basis for this assumption and the
>>> possibility of practical application?
>>>
>>> Thank you, looking forward to reply!
>>>
>>> I wish all the best!
>>> Yang Zhiyuan
>>> August 23, 2024
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list -- tcpm@ietf.org
>>> To unsubscribe send an email to tcpm-leave@ietf.org
>>>
>>