Re: Sending empty segment upon receiving partial ACK

> 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_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