Confussion regarding ADSL and Cable

Basically i`ve got Cable, I notice when my uploads are saturated my
Downloads suffer.
Got told on ADSL this isn`t a problem but then got told it is :s

I`m very confused :0)

"Meggahurtz" <(E-Mail Removed)> wrote in news:18b48$40920eda$516db958
$(E-Mail Removed)-service-com:

> Got told on ADSL this isn`t a problem but then got told it is :s

It'll be a problem with both cable and ADSL. If the upstream is saturated
the computer can't send out "ACK" messages to the server you're
downloading from fast enough so it's sitting there waiting for it before
it can send you what you requested.

--
My photos: http://www.weezer.plus.com/
To send me an e-mail, remove TEETH

Its also an ADSL problem. Basically when you download you need to upload
details of the progress made etc. Therefore should you be upload saturated,
your download speeds will suffer.
Try limiting the upload speeds to leave some free bandwidth.

P


"Meggahurtz" <(E-Mail Removed)> wrote in message
news:18b48$40920eda$516db958$(E-Mail Removed)-service-com...
> Basically i`ve got Cable, I notice when my uploads are saturated my
> Downloads suffer.
> Got told on ADSL this isn`t a problem but then got told it is :s
>
> I`m very confused :0)
>
>

On Fri, 30 Apr 2004 10:18:32 +0100, Phil Chung wrote:

> "Meggahurtz" <(E-Mail Removed)> wrote in news:18b48$40920eda$516db958
> $(E-Mail Removed)-service-com:
>
>> Got told on ADSL this isn`t a problem but then got told it is :s
>
> It'll be a problem with both cable and ADSL. If the upstream is saturated
> the computer can't send out "ACK" messages to the server you're
> downloading from fast enough so it's sitting there waiting for it before
> it can send you what you requested.

This is a symptom of 'tweaking' your RWIN setting as recommended by the
misguided people. Basically you are telling the server to reduce the
amount of data to send to you between ACKs.

Steve <(E-Mail Removed)> wrote:
> On Fri, 30 Apr 2004 10:18:32 +0100, Phil Chung wrote:
>
>> "Meggahurtz" <(E-Mail Removed)> wrote in news:18b48$40920eda$516db958
>> $(E-Mail Removed)-service-com:
>>
>>> Got told on ADSL this isn`t a problem but then got told it is :s
>>
>> It'll be a problem with both cable and ADSL. If the upstream is saturated
>> the computer can't send out "ACK" messages to the server you're
>> downloading from fast enough so it's sitting there waiting for it before
>> it can send you what you requested.
>
> This is a symptom of 'tweaking' your RWIN setting as recommended by the
> misguided people. Basically you are telling the server to reduce the
> amount of data to send to you between ACKs.

Nope.
It's the basic way TCP/IP handles congestion.

If you try to send too much data through a connection, then TCP/IP
reduces the amount of data it sends.
It does this by sensing when packets are lost, then slowing the rate
of transmission until no more packets are lost.

This has the unfortunate side-effect that if you have two connections
downloading over the same link to equally fast sites, if the round-trip
time is different, the one that's closer to you will hog the link.

The backwards direction is needed for a successfull connection, to
inform the other end that data is being got.
If this is clogged, the forwards direction slows too, which is why
maxing out uploads or downloads can slow the other.

"Peter" <(E-Mail Removed)> wrote in message
news:c6tb3e$992$(E-Mail Removed)...
> Its also an ADSL problem. Basically when you download you need to upload
> details of the progress made etc. Therefore should you be upload
saturated,
> your download speeds will suffer.
> Try limiting the upload speeds to leave some free bandwidth.
>
> P
>
>
> "Meggahurtz" <(E-Mail Removed)> wrote in message
> news:18b48$40920eda$516db958$(E-Mail Removed)-service-com...
> > Basically i`ve got Cable, I notice when my uploads are saturated my
> > Downloads suffer.
> > Got told on ADSL this isn`t a problem but then got told it is :s
> >
> > I`m very confused :0)

it may be the ADSL, but there is a generic issue with TCP where the uplink
and downlink bandwidths are different - see RFC3449 if you want all the
complications.

bottom line - if you saturate the link in 1 direction it may impact
(probably will for TCP) how much bandwidth you can use in the other. This
effect gets worse if the bandwidths are unequal when you "clog" the slower
direction.

--
Regards

Stephen Hope - return address needs fewer xxs

On Sat, 01 May 2004 19:11:52 +0000, Ian Stirling wrote:

> Steve <(E-Mail Removed)> wrote:
>> On Fri, 30 Apr 2004 10:18:32 +0100, Phil Chung wrote:
>>
>>> "Meggahurtz" <(E-Mail Removed)> wrote in news:18b48$40920eda$516db958
>>> $(E-Mail Removed)-service-com:
>>>
>>>> Got told on ADSL this isn`t a problem but then got told it is :s
>>>
>>> It'll be a problem with both cable and ADSL. If the upstream is saturated
>>> the computer can't send out "ACK" messages to the server you're
>>> downloading from fast enough so it's sitting there waiting for it before
>>> it can send you what you requested.
>>
>> This is a symptom of 'tweaking' your RWIN setting as recommended by the
>> misguided people. Basically you are telling the server to reduce the
>> amount of data to send to you between ACKs.
>
> Nope.

Yes

> It's the basic way TCP/IP handles congestion.

Optimal RWIN is based on the RTT as you say, setting it too small will
make the server back off when it should not.

> If you try to send too much data through a connection, then TCP/IP
> reduces the amount of data it sends.
> It does this by sensing when packets are lost, then slowing the rate of
> transmission until no more packets are lost.

Packets getting lost is when this has gone wrong, the client advertised
the RWIN based on the RTT - it is dynamic and should be allowed to grow as
big as the OS want and not constrained.


> This has the unfortunate side-effect that if you have two connections
> downloading over the same link to equally fast sites,


This happens all the time, it may not be your pipe, but any link in the
path.

> if the round-trip
> time is different, the one that's closer to you will hog the link.

Only if you have crippled your receive window.

> The backwards direction is needed for a successful connection, to
> inform the other end that data is being got. If this is clogged, the
> forwards direction slows too, which is why maxing out uploads or
> downloads can slow the other.

Only if something is not working well (like crippling your max RWIN).

The design of TCP and subsequent modifications takes all these factors
into account, TCP/IP is designed to run over disparate networks. In the
instance above, the sending side will have worked out the round trip time,
this is permitted to change throughout the lifetime of the connection.

Steve <(E-Mail Removed)> wrote:
> On Sat, 01 May 2004 19:11:52 +0000, Ian Stirling wrote:
>
>> Steve <(E-Mail Removed)> wrote:
>>> On Fri, 30 Apr 2004 10:18:32 +0100, Phil Chung wrote:
>>>
>>>> "Meggahurtz" <(E-Mail Removed)> wrote in news:18b48$40920eda$516db958
>>>> $(E-Mail Removed)-service-com:
>>>>
>>>>> Got told on ADSL this isn`t a problem but then got told it is :s
>>>>
>>>> It'll be a problem with both cable and ADSL. If the upstream is saturated
>>>> the computer can't send out "ACK" messages to the server you're
>>>> downloading from fast enough so it's sitting there waiting for it before
>>>> it can send you what you requested.
>>>
>>> This is a symptom of 'tweaking' your RWIN setting as recommended by the
>>> misguided people. Basically you are telling the server to reduce the
>>> amount of data to send to you between ACKs.
>>
>> Nope.
>
> Yes
>
>> It's the basic way TCP/IP handles congestion.
>
> Optimal RWIN is based on the RTT as you say, setting it too small will
> make the server back off when it should not.
>
>> If you try to send too much data through a connection, then TCP/IP
>> reduces the amount of data it sends.
>> It does this by sensing when packets are lost, then slowing the rate of
>> transmission until no more packets are lost.
>
> Packets getting lost is when this has gone wrong, the client advertised
> the RWIN based on the RTT - it is dynamic and should be allowed to grow as
> big as the OS want and not constrained.

At some point, if you've got two or more TCP/IP connections, that are
quite happy to send at many times your link capacity, then you
can't simply grow the RWIN indefinately, as at some point the packets
pile up at a router somewhere until it decides it's got too many of
your packets queued up, and throws some away.

Both then backoff, and the one with the lower RTT recovers faster,
so it gradually takes over the link.
>
>
>> This has the unfortunate side-effect that if you have two connections
>> downloading over the same link to equally fast sites,
>
>
> This happens all the time, it may not be your pipe, but any link in the
> path.

Yep.
>
>> if the round-trip
>> time is different, the one that's closer to you will hog the link.
>
> Only if you have crippled your receive window.
>
>> The backwards direction is needed for a successful connection, to
>> inform the other end that data is being got. If this is clogged, the
>> forwards direction slows too, which is why maxing out uploads or
>> downloads can slow the other.
>
> Only if something is not working well (like crippling your max RWIN).

Well, no.
You need some 1/30th (it's been a while since I measured it) of the
bandwidth in the other direction to handle the ACKs.
If the ACK pipe can't handle this traffic, as it's full of data, then your
downloads will slow.
AIUI, I'd welcome education if I'm wrong.
will slow.