From nobody Wed Feb 26 14:38:20 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Z2xtR4B0xz5qCR0 for ; Wed, 26 Feb 2025 14:38:55 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z2xtP70Ftz4Fkf for ; Wed, 26 Feb 2025 14:38:53 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of ccfreebsd@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=ccfreebsd@gmail.com Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e6096b9c014so80494276.1 for ; Wed, 26 Feb 2025 06:38:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740580733; x=1741185533; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/whcmvWxjN6oefxITsbOPwCnalkieCR/PZoS5G/G/LI=; b=Kg36ZX963XBafk5wjUWy/PWJgp7YLYXaTxqlvoyDTW1gUTpo25gyCFedpZlSpd9wzv /uOvmiIXEu0r5t3m84d7QWdbFyyrPkplCmO1KjhB0KC75veq5QBQXyBoD0TSQOM8n1fa W+86UvZhSnI/z3CNeCsgQYTzkE3d1tN7ITP3AN5NqIGoAMkVScc5DfUYf+YxkEd3lLP8 DROk72lD4mTJWsQrnGrjk7JysNWsMMYxih0+dk5Yz2hTBkJ7ylvwfZ69wH2XC/+ZWOXI SLYRg2+g1nf3ph7vQp163EFPMSswhJhZS2XXVsYfadnbwynQsNfY1C7t+QZfJKS3NxHB 5O/Q== X-Gm-Message-State: AOJu0YykuDCwhE+m8jOKwfw2wSPu2raG/ymAd7VHliIH4az651gjsLoQ fb7TBimcavyBduwt5S0c+QZW2I8F4JMd9m4iMoDmq2zrVCFAVIsFuFwIow== X-Gm-Gg: ASbGnctCNy0UAD9mKhDsUdexz1s8jNea6+NSPN8tBtwBnx8Hs9gQ4Ikscl9rA01b9GT AtjNnxNm1RVD2rwmYVpfbWWaJUvbdQOyk19ZS6npl9KbOCrzMOmFpba6Gjyl1+UTjbQpAE3OtF1 llQsJoHnPoAour0sr8Rb9FJBCuw67mspaPvyJvKEgzL7T3atUr4ikdTf7ZjGAAfl6g5uqCpfp6O ct60gWRPLrGiEtyRSc64EUWVATPV8oElC8+6D7Cihecz+7x7v7QFmvCvu+ToMvHTDqQfkZauacE fMb0Ke3FgtOaDh2lO3lnW5LhJrGwMNdR/FdSb+GeHekEpzv1TQQTXeFlZm+fFAWfLjg87UbgyHP oFrKnAP/HuevT2Q== X-Google-Smtp-Source: AGHT+IH1vJQ8dmXxTyN4deYQQAqDb5L8RIxSAHi1IvEKIBAejGZhS4XB11XbKxNvjcyuyAslyU7ccg== X-Received: by 2002:a05:690c:3703:b0:6f2:9533:8fb6 with SMTP id 00721157ae682-6fbcc1ff098mr81775297b3.1.1740580732751; Wed, 26 Feb 2025 06:38:52 -0800 (PST) Received: from smtpclient.apple (99-130-150-236.lightspeed.rlghnc.sbcglobal.net. [99.130.150.236]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6fd117dcf36sm10039897b3.90.2025.02.26.06.38.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2025 06:38:52 -0800 (PST) From: Cheng Cui Message-Id: <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C5102C62-4B25-4E97-B35F-D4496FD48309" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: Sending empty segment upon receiving partial ACK Date: Wed, 26 Feb 2025 09:38:20 -0500 In-Reply-To: Cc: freebsd-net@freebsd.org To: jaeyong yoo References: X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spamd-Result: default: False [1.50 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_SPAM_MEDIUM(0.89)[0.890]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[cc@freebsd.org,ccfreebsd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RBL_SENDERSCORE_REPUT_8(0.00)[209.85.219.169:from]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[cc@freebsd.org,ccfreebsd@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.169:from]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.169:from]; TAGGED_RCPT(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Z2xtP70Ftz4Fkf X-Spamd-Bar: + --Apple-Mail=_C5102C62-4B25-4E97-B35F-D4496FD48309 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 18, 2025, at 12:11, jaeyong yoo wrote: >=20 > Hi freebsd-net, >=20 > I am observing somewhat strange pcap behavior. > Scenario: > A --> B > A is the only sender of the data and B is the only receiver. Note that > we use PRR. > When B is sending partial ACKs to A, there are cases when A sends out > just an empty segment with the same sequence number to B. Which seems > to be pure overhead. >=20 > After digging through the code, I think this could be triggered by the > following sequence: >=20 > 1. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_input.c#L= 2892 > during prr-partial ack processing, it calls tcp_output with ACKNOW = flag. >=20 > = 2.https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.= c#L415 > in tcp_output, it determines "len" how much to send and when ACKed > bytes in partial ack is small enough, this "len" becomes zero. >=20 > 3. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#= L702 > As the flag is set to "ACKNOW", with zero length, it anyway sends out > a segment with 0 length. >=20 > My question is, is there some check before sending out like checking > if the length is zero? >=20 >=20 > Thanks, > Jaeyong >=20 Hi Jaeyong, The places (1&2) you have looked at are TCP congestion control/loss = recovery related principles. It might mean your network was experiencing = congestions or packet drops if you checked at the right code. If yes, that was a = problem to look at in the first place. If not, the zero length TCP packet is a pure ack, which in different = code path has its own purpose. Best Regards, Cheng Cui --Apple-Mail=_C5102C62-4B25-4E97-B35F-D4496FD48309 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 18, 2025, at 12:11, jaeyong yoo = <y.jaeyong@gmail.com> wrote:

Hi freebsd-net,

I = am observing somewhat strange pcap behavior.
Scenario:
=   A --> B
A is the only sender of the data and B is the = only receiver. Note that
we use PRR.
When B is sending partial = ACKs to A, there are cases when A sends out
just an empty segment = with the same sequence number to B. Which seems
to be pure = overhead.

After digging through the code, I think this could be = triggered by the
following sequence:

1. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_input.c#L= 2892
during prr-partial ack processing, it calls tcp_output with = ACKNOW = flag.

2.https://github.com/freebsd/freebsd-src/blob/main/sys/netine= t/tcp_output.c#L415
in tcp_output, it determines "len" how much to = send and when ACKed
bytes in partial ack is small enough, this "len" = becomes zero.

3. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#= L702
As the flag is set to "ACKNOW", with zero length, it anyway = sends out
a segment with 0 length.

My question is, is there = some check before sending out like checking
if the length is = zero?


Thanks,
Jaeyong


Hi Jaeyong,

The places (1&2) you = have looked at are TCP congestion control/loss = recovery
related principles. It might mean your network was = experiencing congestions
or packet drops if you checked at the = right code. If yes, that was a problem to look
at in the first = place.

If not, the zero length TCP packet is a = pure ack, which in different code path has
its own = purpose.

Best Regards,
Cheng Cui



= --Apple-Mail=_C5102C62-4B25-4E97-B35F-D4496FD48309--