Date: Wed, 26 Feb 2025 10:21:23 -0500 From: jaeyong yoo <y.jaeyong@gmail.com> To: Cheng Cui <cc@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Sending empty segment upon receiving partial ACK Message-ID: <CANud0TEUTakZkHj39J%2BJRyS9DHRgPr4FKxpgvjHcJao_Si01FQ@mail.gmail.com> In-Reply-To: <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org> References: <CANud0THEOnkWbuOn413AV_auSrY7-SysXThrTyigZMxujEdqEg@mail.gmail.com> <38B72ADC-B796-4BFC-8F94-2BD6E40C4231@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <cc@freebsd.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > 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#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 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANud0TEUTakZkHj39J%2BJRyS9DHRgPr4FKxpgvjHcJao_Si01FQ>