From nobody Wed Feb 26 15:21:23 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 4Z2yqg69wSz5qHZq for ; Wed, 26 Feb 2025 15:21:35 +0000 (UTC) (envelope-from y.jaeyong@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4Z2yqg30T5z3T2P; Wed, 26 Feb 2025 15:21:35 +0000 (UTC) (envelope-from y.jaeyong@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-8641bc78952so1836609241.0; Wed, 26 Feb 2025 07:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740583294; x=1741188094; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KM04bYg9PdWLrFKpenINjM1ZceCjSK2wApHaktP2IXo=; b=WMCHyaFIkUBT7746FuIIjLcE9Ghgc/x+X7wAQRiJN1rMN4wNI8ER3kXWSkmJ6Si1r6 4FS5sjwhj/859QdEeShdPsHYDv1KTG366iI0uFBRs3GUMKDAIIDzDUz2Pc56r17hQUPp ug0twqJU9WFa/hYmUsXuOVUyny7xt1itNlQUZ+DopW0mcBtP8R5gHvuR/z9ZJs7AUqVF GWmT6VnpbPlgdntRGzo5TWqTwFfS8Oy+3Q/NIYaKZtFwpixg3ggCsEK6bOc8xNkR2pDg EbsC5koG5T9EANorINXhBb9bYOUEbo4cUL7JLCHWTKBLKrt3WZuXttEosoJvWQh4CGSk zOcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740583294; x=1741188094; h=content-transfer-encoding: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=KM04bYg9PdWLrFKpenINjM1ZceCjSK2wApHaktP2IXo=; b=IEA+KMLEmsfzjS/Xr7g98rkqkw/bzgx2/cP1VktLyWqMwx7xLZzV0qPaC77rpDUVZ6 lkdDwtbCKNd808L2Q9W+EoeS+6LtBSsVcW8Zpe0PGQgdzwNLQbiUGZUlA7xlY9Imbj1h dcmO6KsQG00C3o6Jjfr2/c9ILxnOs2ph1AV6Uot3duEGRXX9FJtWW6pMuvzNhquaMdSX x/WJB1xz0/Xa96qJhz5UB2xOMzvydN4ri5gAzCm8eU2gKtFjUimbWKWtQBeUXDj6Debt jH1VfdiiIJ5b2w/YY93cmhtiBqvjJb7UrzZ8GZ4RdgJ0LJwVxGV+VJMB6zJOjQcK+Cay EPdw== X-Gm-Message-State: AOJu0YwRL3VJwW9uDvYMOnIkBqFOeB3wH9n4MDYRngJ7eomAhUt/JlzP l8rn46p+pNiquB0cgpbCJRL6M56D7JR3wArGBTHYHSHYaEqp9hWxa5mdz5JW+NOzc/arkEsh0jC yQe797YAY9q/kEvPB7Va3Ab/hMCmF9wzANvA= X-Gm-Gg: ASbGncsf4izMKZVQUlNoEsdL+u9UksSfJt0brz4RrTCIOmsPtgMY+/F5BTFcmOqgEIV 5tqXtRfJ/egJ78TuyOqBhi+CIYkLXkWd33NoNGJjeTqqErsdBZxYcg3qBvRxhYkrT9a2X3hWQmF ID4YmaGYZ7tnbqVkoIiMltJv9da5wVMc0oWZUORWYQug== X-Google-Smtp-Source: AGHT+IFJAG2HGtbXF5P+K9wIc5NmR/6ToSsYibaN09P7Eg0EAe2a4vuAstwl5AvSW7KaoBSmrZhVC7FIbIqhwCPKAuY= X-Received: by 2002:a05:6102:2c01:b0:4b2:cc94:1881 with SMTP id ada2fe7eead31-4bfc027751amr12070979137.21.1740583294178; Wed, 26 Feb 2025 07:21:34 -0800 (PST) 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 References: <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org> In-Reply-To: <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org> From: jaeyong yoo Date: Wed, 26 Feb 2025 10:21:23 -0500 X-Gm-Features: AQ5f1JqPJ_pzlQXr9PEZqnyl7_UeOukGbxi8sVBcaLUrTz2En83THWNLpFDfPpc Message-ID: Subject: Re: Sending empty segment upon receiving partial ACK To: Cheng Cui Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Z2yqg30T5z3T2P X-Spamd-Bar: ---- Thanks for your reply Cheng! Yes that behavior was observed during recovery phase and during that time frame, there were no packets going out to the other direction so there is no reason to send pure ACK (and the ack number for those 3 acks are the same and no possibility of challenge ack as well). I believe this is a buggy behavior and yet the impact is minor as it just sends out few unnecessary acks which doesn't impact the overall TCP states of both ends. I think the fix would be adding extra check for this condition and if it matches just return without sending anything, somewhere around https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#L= 702 I would love to get some input on my theory. Thanks, Jaeyong 2025=EB=85=84 2=EC=9B=94 26=EC=9D=BC (=EC=88=98) =EC=98=A4=EC=A0=84 9:38, C= heng Cui =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > On Feb 18, 2025, at 12:11, jaeyong yoo 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#L2892 > during prr-partial ack processing, it calls tcp_output with ACKNOW flag. > > 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. > > 3. https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_outpu= t.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 recov= ery > related principles. It might mean your network was experiencing congestio= ns > or packet drops if you checked at the right code. If yes, that was a prob= lem 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 > > >