Date: Tue, 15 Jun 2004 11:49:26 -0400 From: "Michael C. Cambria" <mcc@fid4.com> To: net@freebsd.org Subject: snd_wl1 and the tcp send window Message-ID: <20040615154947.20624.qmail@mail102.csoft.net>
next in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040615154947.20624.qmail>