snd_wl1 and the tcp send window

[Michael C. Cambria]

Hi,

I'm seeing a problem that today that has been discussed on this list in
the past according to the freebsd-net archives.  However, I can't find
any resolution.  The archives do suggest several changes to tcp_input.c
to "fix" the problem, but those changes are not in 4.10 or 5.2.1.

What I see looks like it has been described already in the thread
related to:

Message-ID:  <20020417160045.GQ343 at fubar.damon.com>

I believe that I'm hitting exactly what is described in the archived
message:

> In the ack processing code (step 6), the variable snd_wl1 tracks the
> newest sequence number that we've seen.  It helps prevent snd_wnd from
> being reopened on re-transmitted data.  If snd_wl1 is greater than
> received sequence #, we skip it.
[deleted]
>
> Since snd_wl1 is only updated if the condition is true -- we're stuck.
> snd_wl1 is only updated with in SYN/FIN processing code and in step 6.
>
> So if we process 2GB in the header prediction code -- where the step 6
> never executes, and then somehow reach step 6.  snd_wnd collapses and
> tcp_output stops sending.

That discussion took place ~18 months ago and nothing seems to be
different in tcp_input.c related to snd_wl1 and snd_wl2.  Is this a real
issue or did I just screw something up?  It looks like the header
prediction case should update snd_wl1 & snd_wl2.

I am using GigE, and the application is doing very long message
transfers.  Both nodes are on the same GigE switch.

Should snd_wl1 & snd_wl2 be updated in the header prediction case?

Thanks,
MikeC