Subject: Re: Does window scale solve long fat pipe issue?

From: Omar Elloumi <[email-masked]>
Date: Fri, 29 Oct 1999 12:24:45 +0200

Julien Godard wrote:

>
>
> As far I understand, your file is 64Kbytes and your RTT 500ms ?
> In this case, because your bandwidth-delay product is around 128000
> bytes, you need a maximum window which should be a little bigger than
> this value to achieve the best throughput.
>
> With an initial window of 1500 bytes your slow start duration should
> be around 3.2 s, and the size of the file transfered during this time
> should be ~45 Kbytes.
>
> So, the impact of the slow start is strong...
> First, I recommend you to test a bigger file (with ~1900 Kbytes, the
> slow start should take 10 % of the time), and then to check your max
> window.
>
> Windows scale can make it possible to fully use the pipe, but you will
> always have the slow start...

By the way, what's the state of Floyd's proposal to have an initial
congestion window size of 4 packets instead of 1. This may help
during slow start.

Omar.

--
____________________________________________________________
Omar Elloumi

Alcatel Research - Network Architecture - Traffic Technology

Francis Wellesplein 1, 2018 Antwerp, Belgium

Phone: + 32 3 240 78 33
Fax:   + 32 3 240 99 32
http://www.alcatel.com/crc/
____________________________________________________________

Opinions expressed are those of the sender and do not reflect Alcatel
policy or agreement

---

From: "Julien Godard" <[email-masked]>
Date: Fri, 29 Oct 1999 10:12:20 +0100

As far I understand, your file is 64Kbytes and your RTT 500ms ?
In this case, because your bandwidth-delay product is around 128000 bytes,
you need a maximum window which should be a little bigger than this value to
achieve the best throughput.
With an initial window of 1500 bytes your slow start duration should be
around 3.2 s, and the size of the file transfered during this time should be
~45 Kbytes.
So, the impact of the slow start is strong...
First, I recommend you to test a bigger file (with ~1900 Kbytes, the slow
start should take 10 % of the time), and then to check your max window.
Windows scale can make it possible to fully use the pipe, but you will
always have the slow start...

julien

> -----Original Message-----
> From:	Eric Travis [SMTP:[email-masked]]
> Sent:	Friday, October 29, 1999 5:51 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: Does window scale solve long fat pipe issue?
> 
> 
> > I did a few simulations of client-server ftp sessions over
> > geostationary on-board ATM processed satellite using OPNET
> > simulation tool with almost all default values provided by OPNET
> > Modeler6.0, and find that window scale extension described in
> > RFC1323 does not provide the throughput great than 1Mbps
> > (64Kbytes/500ms) on a 2Mbps link.
> 
> Large windows *can* make it possible to achieve full link utilization,
> but they alone are not sufficient. You need to be transferring enough
> data to allow the connection to "come up to speed".
> 
> If the OPNET models don't allow you to observe the instantaneous cwnd
> of transport connections during a run, then pass *large* amounts of 
> data (per connection) and see if the throughput increases with the
> transfer size...
> 
> You don't mention how large your simulated ftp transfers were, but 
> because of slow-start, is it possible that:
> 
>    - Your transfers were too small for the TCP connections to
>      fully open cwnd to allow for the transmission rate to 
>      reach 2Mbps
> 
>    - Your transfers *were* large enough to allow the cwnd to
>      fully open by the end of the transfers, yet they were
>      not large enough to make the cost of slow-start a minimal
>      in the throughput calculation.
> 
> I'm guessing/hoping that your simulations didn't incur any 
> losses over the path (either due to congestion or corruption); 
> If there are losses involved, your throughput will suffer
> (as you are reducing your cwnd - and thus the transmission
> rate in response to a loss).
> 
> Eric
>