Do NTL shape FTP traffic? Can't get anywhere near my connection speed

[rdhw]

Originally Posted by Paul M

3. RWIN is a tcp setting, not an http/ftp setting, so it should affect all or none.

Yes but no.

Because NTL operate a transparent web proxy cache, the actual source of HTTP traffic is always close to the client, so that good TCP throughputs will be achieved even with a low RWIN setting.

With FTP traffic (irrespective of port number), the RWIN matters a great deal more, and given that the connection is international, I do indeed think that the poster should try increasing their RWIN for long-haul FTP downloads.

To imporve FTP uploads, it is the server's RWIN that needs to be increased.

[Chrysalis]

It isnt just udp and icmp its latency in ssh as well, it improved at the same time throughput dropped, which to me looks like shaping. I happen to think this is a good thing it isnt a complaint, if there was no shaping speeds wouldnt be much better and latency would be bad as well, at least now there is useability in ssh during peak hours. I dont know if gaming itself has improved but if you check the leics gaming thread it got quieter around the same time also which seems to suggest shaping is enabled. But I dont think ntl are deprioritising traffic like ftp and p2p I think they are just prioritising latency sensitive traffic, and it could well just be temporary because that router is saturated pretty bad right now.

Also last night in the space of 30 minutes I had a download of leaseweb going from around 1.7mbit to 10mbit it just shot up. Could be either shaping is only on during the evenings or a lot of users went offline at the same time.

[Chrysalis]

Originally Posted by rdhw

Yes but no.

Because NTL operate a transparent web proxy cache, the actual source of HTTP traffic is always close to the client, so that good TCP throughputs will be achieved even with a low RWIN setting.

With FTP traffic (irrespective of port number), the RWIN matters a great deal more, and given that the connection is international, I do indeed think that the poster should try increasing their RWIN for long-haul FTP downloads.

To imporve FTP uploads, it is the server's RWIN that needs to be increased.

That is correct rwin directly affects ftp transfer's much more then http and in particular when proxies are used.

[Ignition]

Originally Posted by Chrysalis

That is correct rwin directly affects ftp transfer's much more then http and in particular when proxies are used.

Nope doesn't affect any differently apart from when proxies are used, TCP/IP doesn't care whether its' FTP or HTTP that's running over it and neither of those have any influence over when ACKs are issued.

Originally Posted by Chrysalis

That is correct rwin directly affects ftp transfer's much more then http and in particular when proxies are used.

No, it doesn't. The only time you will see a difference with http over anything else (from apparently the same remote source) is when an http proxy is used, because as Robin pointed out, the actual [real] source is closer - and that is not rwin making a difference to http, it the proxy making a difference to the source location.

[Chrysalis]

some httpd servers overide the system's send rwin value thus making it not apply whilst ftpd servers normally use it so a httpd server eg. might be using a 65536 rwin as opposed to a ftpd's 32768 rwin.

We agree on the proxies anyway but I will add an additional point, even if the file isnt cached if the end user has a default rwin which is much lower then 64240 and the proxy has that value set then I think the proxy is retrieving it for them at 64240 and then they download of the proxy as it recieves it.