> On Feb 18, 2025, at 12:11, jaeyong yoo <y.jaey...@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_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
