It does not surprise me that you received performance gains. Looking at
the simple single connection over an uncongested direct satellite link as
part of another project I worked on, we did a simple mathematical formula
where we asked how low does the BER have to go before the largest (RFC
compliant) TCP MSS size available was no longer optimal, and factoring in
header overhead the answer was ridiculously low (like 10e-3). By
extension, it was clear that a larger MSS was much more efficient on the
higher bandwidth links seen today. I'm not sure where you got the 16208 MSS
size, but I suspect that it is link bandwidth specific and if for some
reason your bandwidth was seriously suddenly reduced (such as a competing
data stream) you'd suddenly have virtually no bandwidth available to either
data stream as neither would complete a TCP segment very often. Still, it
is an interesting tuning idea for a single TCP connection over a satellite
link with no other competition when the bandwidth is known and fixed. Other
than that case, things fall apart quickly as there is poor scaling and
little adaption. As Gorry Fairhurst pointed out, run it with anything else
and then see. There are other better options. (I'll also point out that
you're still only at best about 73% link efficiency with your modifications,
so even if this specific case always applies to your usage, wasting over
2Mbps of satellite bandwidth probably won't please whoever pays for it :))
Cheers,
Charlie
--- Charlie Younghusband Network Software Engineering Xiphos Technologies http://www.xiphos.ca/ 514-848-9640-----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Sergey Raber Sent: August 27, 2001 1:00 PM To: [email protected] Cc: [email protected] Subject: Re: TCP question
> > If the Sender Maximum Segment Size (SMSS) is set to the same value > > as the Receiver Window (rwnd), will the window used by the sender > > - defined as min(rwnd,cwnd) - always remain at a constant value of > > rwnd? > > > > For example, if the sender receives a rwnd of 64K, can it set the > > MSS to 64K and keep its window wide open all the time - even if > > there is congestion? > > Clever. ;) > > I think you're correct since there is a lower bound on cwnd (i.e., > it can never be less than 1 MSS). > > But, I don't think this will actually work all that well -- and it > may be worse for the network than simply setting your TCP to never > adjust cwnd. The problem is that you are spitting out 64KB onto the > network at once. With a burst like that some packet is going to be > lost -- which means you'll end up retransmitting the TCP segment > again (in a 64KB burst). Packets from that segment will likely be > dropped, etc. So, you likely won't be getting much of anything > done.
Anyhow, we have tested out the following:
Test link: 8Mbps forward on the real GEO satellite (BER ~10E-8), 128Kbps reverse over sat. simulator. Total RTT ~550ms. Using standard tcp MSS (1448) with the max. window size of 589815Byte and downloading a 20MByte file (via ftp) we have got the speed of 280-610KByte/sec (depending on the packet losses that initiated retransmit & congestion avoidance) Using tcp MSS 16208Byte we have reached improvement of the speed to 480-730KByte/sec on the same link with the same conditions. Slow start reaches max. cwnd about two times faster and congestion avoidance phase reaches max. cwnd about 10 times faster.
Is this really does not deserve any following discussion?
Regards, --- Sergey Raber GMD.NET Project Satellite Communication
This archive was generated by hypermail 2b29 : Mon Aug 27 2001 - 16:35:53 EDT