Date: Wed, 26 Feb 2025 09:38:20 -0500 From: Cheng Cui <cc@freebsd.org> To: jaeyong yoo <y.jaeyong@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Sending empty segment upon receiving partial ACK Message-ID: <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org> In-Reply-To: <CANud0THEOnkWbuOn413AV_auSrY7-SysXThrTyigZMxujEdqEg@mail.gmail.com> References: <CANud0THEOnkWbuOn413AV_auSrY7-SysXThrTyigZMxujEdqEg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <y.jaeyong@gmail.com> 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 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Feb 18, 2025, at 12:11, jaeyong yoo = <y.jaeyong@gmail.com> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>Hi freebsd-net,<br><br>I = am observing somewhat strange pcap behavior.<br>Scenario:<br> = A --> B<br>A is the only sender of the data and B is the = only receiver. Note that<br>we use PRR.<br>When B is sending partial = ACKs to A, there are cases when A sends out<br>just an empty segment = with the same sequence number to B. Which seems<br>to be pure = overhead.<br><br>After digging through the code, I think this could be = triggered by the<br>following sequence:<br><br>1. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_input.c#L= 2892<br>during prr-partial ack processing, it calls tcp_output with = ACKNOW = flag.<br><br>2.https://github.com/freebsd/freebsd-src/blob/main/sys/netine= t/tcp_output.c#L415<br>in tcp_output, it determines "len" how much to = send and when ACKed<br>bytes in partial ack is small enough, this "len" = becomes zero.<br><br>3. = https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_output.c#= L702<br>As the flag is set to "ACKNOW", with zero length, it anyway = sends out<br>a segment with 0 length.<br><br>My question is, is there = some check before sending out like checking<br>if the length is = zero?<br><br><br>Thanks,<br>Jaeyong<br><br></div></div></blockquote><br></= div><div>Hi Jaeyong,</div><div><br></div><div>The places (1&2) you = have looked at are TCP congestion control/loss = recovery</div><div>related principles. It might mean your network was = experiencing congestions</div><div>or packet drops if you checked at the = right code. If yes, that was a problem to look</div><div>at in the first = place.</div><div><br></div><div>If not, the zero length TCP packet is a = pure ack, which in different code path has</div><div>its own = purpose.</div><br><div> <div>Best Regards,<br>Cheng Cui</div><div><br></div><br = class=3D"Apple-interchange-newline"> </div> <br></body></html>= --Apple-Mail=_C5102C62-4B25-4E97-B35F-D4496FD48309--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B72ADC-B796-4BFC-8F94-2BD6E40C4231>