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

Yoshifumi Nishida <nsd.ietf@gmail.com> Sun, 25 August 2024 07:34 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 1B904C14F6B7 for <tcpm@ietfa.amsl.com>; Sun, 25 Aug 2024 00:34:22 -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_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 KoDIkD3TY6vN for <tcpm@ietfa.amsl.com>; Sun, 25 Aug 2024 00:34:19 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 B10D6C14F6AF for <tcpm@ietf.org>; Sun, 25 Aug 2024 00:34:19 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-44fdde0c8dcso19374421cf.0 for <tcpm@ietf.org>; Sun, 25 Aug 2024 00:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724571258; x=1725176058; 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=8ICbaWFclIEuzqw2NpYTzxc/IrAZzjPfjTcwG/YK3+4=; b=kCs/nc0QbK41fs/5c8hbVXNH7XTkXh47dSP6G0wkaBK4S8YlUoHf7/RF/1WaXhI3C/ 6N1DB9VDDLhSJV4OMjqzexBqvc+kTodLRBUO9jRXku2g1dbgalXRZqNifCjumEpfOprW AMbYh0XC7uLl/0/ycf+1WgGlsBqri0fiNg+Rxllua+8ehFCFM29CfOZ9xwDT2/czDDuG mA/5Nty2knwOYh+Xx2hlM365NwMuYJmagmuf3w4c89x2ZG6OZ6KQVsUADYQez6iCN76K avZ7q25qNumQAiHtdP7HSDBfCxW68M64pWfUPXAIPFAWluf5L9CYqB3KfXVFX6w+diQQ JApQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724571258; x=1725176058; 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=8ICbaWFclIEuzqw2NpYTzxc/IrAZzjPfjTcwG/YK3+4=; b=B3zEWGReVDPjzSaqLyebM60W9doCxJ+xfLhnt0rBB3qlluDpffwQtDh6L2P+TRkZxj k061XApg5/Vpm/JMPH/49U3CmG34LSMlVSva0qJjpcZinlcKjNS+XMWmijUdX3v0Doec mcND0D/kwYOK0apCC36jl/3boFYC9W4JpxxX00diJLrsgLNNTezCVp6eU82QHOgIzijI Z963ogtiRnIdQVQf2TGtINm+EsyGhoUWRV2NVpYZIZdEoq842dSBJee3AsMSGKKDOmCs eMXeTtiX5rL1bZ3jioZ3zDI4MSq1Ms5+S0okXag29jv+8ipwlLiyuVMDoOCu0JVWz/yR qhTg==
X-Gm-Message-State: AOJu0YzGoQ7dnvsGiXOhx1OXnewhAeN++Wq/nJR3dLylACiWZKxNzHSk QFKhgKKTbj2HD3GRXYiDsPEyuBEK6FqtSOc0AfJYsShDZwNGiCIDEBvRZrnpBl967cT/uY1vvKG 5k80tctNHkJlrHxHpta0QpE1sl+A=
X-Google-Smtp-Source: AGHT+IFaurRcUDYGGB5iKRNKTgczFqdy4cxxfd+hPrPp4/OPUUCaRTqUEr1z0BLeCwtGRUbVRLMVzCp8bV23a/clVLg=
X-Received: by 2002:a05:622a:548a:b0:455:af6:7d9 with SMTP id d75a77b69052e-4550af613f8mr74737341cf.16.1724571258469; Sun, 25 Aug 2024 00:34:18 -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>
In-Reply-To: <55af587.448d8.191885dc7d7.Coremail.yangbuwangchuxin@163.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Sun, 25 Aug 2024 00:34:04 -0700
Message-ID: <CAAK044TDm72yUxxhkbtYk7O0cRL5vE35kYp+1Q83S9vbdw0jPw@mail.gmail.com>
To: "yangbuwangchuxin@163.com" <yangbuwangchuxin@163.com>
Content-Type: multipart/alternative; boundary="00000000000040436506207d096c"
Message-ID-Hash: ZCXSRLR7JLHPXW7LU7NZX65Q4UJZMBYL
X-Message-ID-Hash: ZCXSRLR7JLHPXW7LU7NZX65Q4UJZMBYL
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/dCY3fdAA8bzUi4z-wLDNwOrzBwg>
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,

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
>>
>