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: <[EMAIL PROTECTED]>
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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
