Subject: RE: nt to nt tcpsat problems

From: David Godwin <[email-masked]>
Date: Thu, 10 Feb 2000 18:30:13 -0500

Hi Graham,

Sounds like you might want to try XFTP (see
http://roland.grc.nasa.gov/~mallman/papers/wosbis.ps).  Also, there are some
interesting papers at http://tcpsat.lerc.nasa.gov/tcpsat/papers.html.

Best regards,
David Godwin
Petroleum/C-Store Development Engineer 
VeriFone, a division of Hewlett-Packard 
Office: (727) 953-4072  Fax: (727) 953-4001 
http://www.verifone.hp.com 
Mailto:[email-masked] 
> -----Original Message-----
> From:	Graham Street [SMTP:[email-masked]]
> Sent:	Thursday, February 10, 2000 9:04 AM
> To:	[email-masked]
> 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-masked]

---

From: Mark Allman <[email-masked]>
Date: Fri, 11 Feb 2000 08:23:25 -0500

> http://roland.grc.nasa.gov/~mallman/papers/wosbis.ps).  Also,
> there are some interesting papers at
> http://tcpsat.lerc.nasa.gov/tcpsat/papers.html.

Actually, xftp is the *wrong* thing to use.  XFTP was an
experiment.  It is inappropriate for use on shared networks, as its
congestion response is not similar to that used by TCP (it ends up
being N times more aggressive because you are using N connections).
See the following paper for a discussion about why using multiple
flows is not appropriate from a congestion control perspective...

    Floyd, S., and Fall, K., Promoting the Use of End-to-End
    Congestion Control in the Internet, IEEE/ACM Transactions on
    Networking, August 1999. 
    http://www.aciri.org/floyd/end2end-paper.html

allman

---
http://roland.grc.nasa.gov/~mallman/

---

From: "Julien Godard" <[email-masked]>
Date: Fri, 11 Feb 2000 13:53:45 -0000

a very usefull webpage : http://www.psc.edu/networking/perf_tune.html

You will found all the tips to change the parameters needed for TCP over sat
for various operating systems.

Cheers
Julien Godard
System Engineer, Broadband Satellite Networks

Nortel Networks
London Road
Harlow, Essex, CM17 9NA
United Kingdom

Email :  [email-masked]
Phone : +44 (0) 1279 403769
	ESN : 742 3769
Fax :     +44 (0) 1279 402400

Company name: Nortel Networks plc
Company number: 2515751
Company's registered office address: Maidenhead Office Park, 
Westacott Way, Maidenhead, Berkshire SL6 3QH.

> Sent:	Thursday, February 10, 2000 2:04 PM
> To:	[email-masked]

---

From: David Godwin <[email-masked]>
Date: Fri, 11 Feb 2000 11:28:54 -0500

Hi Mark,

Sorry for muddying the waters with my comment regarding XFTP.  In my reply, I
made the assumption that Graham was using a (momentary) point-to-point
connection on a private VSAT network.  That is the scenario that is used by most
of systems with which I am familiar.

Also, I should have made it clear that I have no real experience with the
technique described in the XFTP paper... just that I was very impressed that you
had found an application-level workaround for an underlying protocol problem.  I
can certainly understand how the approach could lead to excessive congestion.
Thank you for the interesting reference to the Floyd and Fall paper.

Best regards,
David Godwin
> From:	Mark Allman [SMTP:[email-masked]]
> Sent:	Friday, February 11, 2000 8:23 AM
> To:	David Godwin
> Cc:	[email-masked]'; [email-masked]
> Subject:	Re: nt to nt tcpsat problems 
> 
>

---

From: Noam Gonen - Israel <[email-masked]>
Date: Wed, 16 Feb 2000 17:04:07 +0200

Regarding DefaultReceiveWindow \ DefaultSendWindow  :

	Note that applications can modify this value on a per-socket basis
with the SO_RCVBUF socket option.
	so your changes might be "undone" on a per app. basis.

	regards,
	Noam G. ([email-masked])

> From:	Marcelo Reis [SMTP:[email-masked]]
> Sent:	ו 11 פברואר 2000 14:23
> To:	[email-masked]'; [email-masked]
> Subject:	RES: nt to nt tcpsat problems
> 
> Hi Graham,
> 
> For winsock applications you need also to set two more variables:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul
> tR
> eceiveWindow
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul
> tS
> endWindow 
> 
> Both of type REG_DWORD.
> 
> I don't know if it applies to you, but NT4 SP5 has a math error in its tcp
> stack that causes the retransmit timer to be incorrectly computed, leading
> to unnecessary retransmissions. There is a new tcpip.sys file that fixes
> that bug. If you need this file and also the MS bug report regarding this,
> please let me know.
> 
> Regards,
> 
> Marcelo M. Reis
> [email-masked]
> 
> > ----- Mensagem original -----
> > De:		Graham Street [SMTP:[email-masked]]
> > Enviada em:		Quinta-feira, 10 de Fevereiro de 2000 11:04
> > Para:		[email-masked]
> > Assunto:		nt to nt tcpsat problems
> > 
> > Hi all,
> >

---

From: [email-masked]
Date: Wed, 16 Feb 2000 10:13:45 -0800

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-masked] 

____________________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-masked]>
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-masked] [mailto:[email-masked]]On
Behalf Of Robert Schellhase
Sent: Thursday, February 10, 2000 1:18 PM
To: [email-masked]
Cc: [email-masked]
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-masked] [mailto:[email-masked]]On
Behalf Of Graham Street
Sent: Thursday, February 10, 2000 9:04 AM
To: [email-masked]
Subject: nt to nt tcpsat problems

Hi all,

Thanks,
Graham Street
[email-masked]

[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-masked]>; 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-masked]>
From: "Greg Otto" <[email-masked]>
To: "'Robert Schellhase'" <[email-masked]>,
        <[email-masked]>
Cc: <[email-masked]>
Subject: RE: nt to nt tcpsat problems
Date: Thu, 10 Feb 2000 18:04:20 -0600
Message-ID: <[email-masked]>
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-masked]
Precedence: bulk