Re:Fwd:RE: nt to nt tcpsat problems

From: [email protected]
Date: Wed Feb 16 2000 - 13:13:45 EST

  • Next message: Marcelo Reis: "RES: Fwd:RE: nt to nt tcpsat problems"

    Please note that a TcpWindowSize of 65536 in decimal value is
    1 0000 in Hexadecimal. Win NT 4.0 does not realize this is and sets
    the window size to 0. When sending a packet to a host with a
    TcpWindowSize of zero, the host follows the TCP spec and sends back 1 byte to
    respond to the zero window size. The Win NT host then proceeds to advertize a
    no-zero window size and the communications begin. The rest of the packet which
    trails the initial 1 byte originaly sent is fragmented and minimizes throughput.

    To provide a band-aid fix, you can set 1 back the TcpWindowSize to 65535 which
    is ffff in hex and does fit in the 16 bit tcp parameter.
    Windows advertizes correctly and communications is possible to a full
    theoretical

    64 Kbyte * 8 bit/Byte / .250 ms(average sat delay) = 2.048 Kbit/sec

    Longterm fix - Use Solaris or Windows 2000 with the scaling option.

    Loay Oweis
    COMSAT Corp
    [email protected]

    ____________________Reply Separator____________________
    Subject: Fwd:RE: nt to nt tcpsat problems
    Author: Rob Kibler
    Date: 2/11/00 9:16 AM

    ____________________Forward Header_____________________
    Subject: RE: nt to nt tcpsat problems
    Author: <[email protected]>
    Date: 2/10/00 6:04 PM

    Gentlemen,

    I did a week long study on this exact problem and the simple answer is "YOU
    ARE OUT OF LUCK." I have a ticket open with MS on this problem as it is how
    the CIFS protocol works. CIFS will only negotiate a 4K transfer size when
    the latency and bandwidth are small (if you are very very ... lucky maybe
    upto 12K). Basically, in short your throughput will be about equal to
    4K/RTT (excluding other various factors). Thus, window size only needs to
    be 4K for this. It is a higher layer problem!!!

    While I cannot give you a copy of my report, I do have a couple of graphs I
    can get to you.

    Greg

    -----Original Message-----
    From: [email protected] [mailto:[email protected]]On
    Behalf Of Robert Schellhase
    Sent: Thursday, February 10, 2000 1:18 PM
    To: [email protected]
    Cc: [email protected]
    Subject: RE: nt to nt tcpsat problems

    Hi Graham,
    I see you have found that Windows supports a registry key for TcpWindowSize.
    The sad news is that it has no effect, in spite of the fact that Microsoft
    has a white paper on its own TCP implementation that claims otherwise.

    You might try the NetManage OnNet kernel for Windows 95/98 at
    http://www.netmanage.com/products/onnetkernel4/index.asp

    I don't know what they charge for it, but I think it's affordable and they
    offer a free demo.

    Best regards,
    Robert Schellhase
    Senior Engineer
    INTELSAT

    -----Original Message-----
    From: [email protected] [mailto:[email protected]]On
    Behalf Of Graham Street
    Sent: Thursday, February 10, 2000 9:04 AM
    To: [email protected]
    Subject: nt to nt tcpsat problems

    Hi all,

    We're trying to run windows file sharing protocols over a tcp sat link
    and getting miserable performance, even after setting TcpWindowSize to
    65536. We can get about 100-250k max. We are trying to get at least
    one megabit out of it. Is this even possible? We can get 1-2 megabits
    ftping from a sun box over satellite...

    does anyone know of any clever (cheap) solutions (spoofing nacks?,
    translating
    to udp?)

    Thanks,
    Graham Street
    [email protected]

    Received: from neal ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP
      (IMA Internet Exchange 3.13) id 0000C4FC; Thu, 10 Feb 2000 20:34:37 -0500
    Received: from [139.88.112.33] (helo=lombok-fi.lerc.nasa.gov)
        by neal with esmtp (Exim 2.12 #8)
        id 12J4w1-0002ND-00; Thu, 10 Feb 2000 20:31:49 -0500
    Received: (from listserv@localhost)
        by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03975
        for tcpsat-outgoing; Thu, 10 Feb 2000 19:05:42 -0500 (EST)
    Received: from seraph3.lerc.nasa.gov ([email protected]
    [139.88.146.12])
        by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA03944
        for <[email protected]>; Thu, 10 Feb 2000 19:05:40 -0500 (EST)
    Received: by seraph3.lerc.nasa.gov; id TAA20274; Thu, 10 Feb 2000 19:05:40 -0500
    (EST)
    Received: from
    new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by
    seraph3.lerc.nasa.gov via smap (V5.0)
        id xma020153; Thu, 10 Feb 00 19:04:58 -0500
    Received: from houpdc.newf.com (mail.newf.com [216.62.131.2])
        by ns.newf.com (8.9.3/8.9.3) with ESMTP id SAA08636;
        Thu, 10 Feb 2000 18:04:54 -0600
    Received: from heliox (216.190.71.51) by houpdc.newf.com (Worldmail 1.3.167); 10
    Feb 2000 18:04:54 -0600
    Reply-To: <[email protected]>
    From: "Greg Otto" <[email protected]>
    To: "'Robert Schellhase'" <[email protected]>,
            <[email protected]>
    Cc: <[email protected]>
    Subject: RE: nt to nt tcpsat problems
    Date: Thu, 10 Feb 2000 18:04:20 -0600
    Message-ID: <000001bf7423$8bee7080$[email protected]>
    MIME-Version: 1.0
    Content-Type: text/plain;
    Content-Transfer-Encoding: 7bit
    X-Priority: 3 (Normal)
    X-MSMail-Priority: Normal
    X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
    X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
    Importance: Normal
    In-Reply-To: <000001bf73fb$8f1de5b0$1615cad0@kensington>
    Sender: [email protected]
    Precedence: bulk



    This archive was generated by hypermail 2b29 : Wed Feb 16 2000 - 11:02:05 EST