[Bugme-new] [Bug 9031] New: TPC window is to cautious on send

[bugme-daemon at bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=9031

           Summary: TPC window is to cautious on send
           Product: Networking
           Version: 2.5
     KernelVersion: Any
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: shemminger at osdl.org
        ReportedBy: a at oo.ms


This has been a longstanding "bug" of sorts when talking to a system that has
extremely small windows (under 1.5k).

The only way to give the stack on the other side a nudge is to ACK twice.

Here is a sample transcript, with a max window size of 1025 bytes.

18:25:43.968358 IP dr.ea.ms.http > 192.168.80.2.40246: . 37377:37633(256) ack
120 win 5840
18:25:43.992402 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 769 <mss
256>
18:25:44.390305 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 1025
<mss 256>
18:25:44.823084 IP dr.ea.ms.http > 192.168.80.2.40246: . 37633:37889(256) ack
120 win 5840

If I take the "nudge" code out of my IP stack, it sits for an aweful long time,
waiting on the next packet, when there clearly is room for a few more.

Should I:
1: Have my IP stack lie about the window till it is important?
2: Something else?

I can't see any good reason for the large delay, since it is on a serial link,
via SLIP.

I can point you to source code that will allow you to verify the problem for
yourself, if you would like.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.