«

The Other Guy wrote:
> Zipper wrote:
>> Is it even possible for an ISP to offer xxx/256?
>> I don't think they can. For some reason Telecom don't seem to want to
>> let ISP's offer 256 up, its either 128 or fullspeed.. seems a bit
>> strange..
>
> Nope, it is either 128k up or 512k up. No option for full speed
> upstream. ADSL can't go much faster than that upstream.
>
> The Other Guy

I meant on the new plans, Telecom are changing any plans with 512
upstream currently to fullstream up.

In message <egf3dj$lue$>, Alan wrote:

> TCP will always perform it error correction functions despite this
> interleaving thing being on or off - I cannot see how it wouldn't, but
> I stand ready to be corrected!

TCP performs error detection, not correction. It sends a NAK instead of an
ACK response, meaning "I didn't get that, please resend".

"Lawrence D'Oliveiro" <_zealand> wrote in
message news:egfpvn$v77$...
> In message <egf3dj$lue$>, Alan wrote:
>
>> TCP will always perform it error correction functions despite this
>> interleaving thing being on or off - I cannot see how it wouldn't,
>> but
>> I stand ready to be corrected!
>
> TCP performs error detection, not correction. It sends a NAK instead
> of an
> ACK response, meaning "I didn't get that, please resend".
>

What is the purpose of the NAK if not to get the corrupted / lost
packet(s) resent in order to facilitate the correction of the data
stream?

Isn't detection simply one part of the correction mechanism or am I
misunderstanding what you are saying?

Thanks,

Alan.
--

The views expressed are my own, and not those of my employer or anyone
else associated with me.

My current valid email address is:



This is valid as is. It is not munged, or altered at all.

It will be valid for AT LEAST one month from the date of this post.

If you are trying to contact me after that time,
it MAY still be valid, but may also have been
deactivated due to spam. If so, and you want
to contact me by email, try searching for a
more recent post by me to find my current
email address.

The following is a (probably!) totally unique
and meaningless string of characters that you
can use to find posts by me in a search engine:

ewygchvboocno43vb674b6nq46tvb

Alan wrote:
> "Lawrence D'Oliveiro" <_zealand> wrote in
> message news:egfpvn$v77$...
>
>>In message <egf3dj$lue$>, Alan wrote:
>>
>>
>>>TCP will always perform it error correction functions despite this
>>>interleaving thing being on or off - I cannot see how it wouldn't,
>>>but
>>>I stand ready to be corrected!
>>
>>TCP performs error detection, not correction. It sends a NAK instead
>>of an
>>ACK response, meaning "I didn't get that, please resend".
>>
>
>
> What is the purpose of the NAK if not to get the corrupted / lost
> packet(s) resent in order to facilitate the correction of the data
> stream?
>
> Isn't detection simply one part of the correction mechanism or am I
> misunderstanding what you are saying?

Resending data isn't correcting it, the corrupted data is thrown away.
With error correction the data along with the checkbits are analysed,
and the original data is corrected.

"Jerry" <> wrote in message
news:452c1725$...
> Alan wrote:
>> "Lawrence D'Oliveiro" <_zealand> wrote in message
>> news:egfpvn$v77$...
>>
>>>In message <egf3dj$lue$>, Alan wrote:
>>>
>>>
>>>>TCP will always perform it error correction functions despite this
>>>>interleaving thing being on or off - I cannot see how it wouldn't, but
>>>>I stand ready to be corrected!
>>>
>>>TCP performs error detection, not correction. It sends a NAK instead of
>>>an
>>>ACK response, meaning "I didn't get that, please resend".
>>>
>>
>>
>> What is the purpose of the NAK if not to get the corrupted / lost
>> packet(s) resent in order to facilitate the correction of the data
>> stream?
>>
>> Isn't detection simply one part of the correction mechanism or am I
>> misunderstanding what you are saying?
>
> Resending data isn't correcting it, the corrupted data is thrown away.
> With error correction the data along with the checkbits are analysed, and
> the original data is corrected.

So, my question:

Is there a higher chance that a file downloaded through the internet will be
corrupt when ADSL interleaving is switched off?

I was hoping that perhaps some other protocol would mean there is no
increased chance of corruption. Seems to me that interleaving is
unnecessary when there are other protocols that perform error detection and
recovery.

In article <452c1725$>, Jerry wrote:
> Alan wrote:
>> "Lawrence D'Oliveiro" <_zealand> wrote in
>> message news:egfpvn$v77$...
>>
>>>In message <egf3dj$lue$>, Alan wrote:
>>>
>>>
>>>>TCP will always perform it error correction functions despite this
>>>>interleaving thing being on or off - I cannot see how it wouldn't,
>>>>but
>>>>I stand ready to be corrected!
>>>
>>>TCP performs error detection, not correction. It sends a NAK instead
>>>of an
>>>ACK response, meaning "I didn't get that, please resend".
>>>
>>
>>
>> What is the purpose of the NAK if not to get the corrupted / lost
>> packet(s) resent in order to facilitate the correction of the data
>> stream?
>>
>> Isn't detection simply one part of the correction mechanism or am I
>> misunderstanding what you are saying?
>
> Resending data isn't correcting it, the corrupted data is thrown away.
> With error correction the data along with the checkbits are analysed,
> and the original data is corrected.

I thought that was "Forward Error Correction". TCP's resend of data is a
type of error correction. A type that in a reasonably high quality link
is much more bandwidth friendly than FEC. The problem with TCP comes in
low quality links where a significant fraction of the data is lost,
causing a large part to be resent and then some of that is lost etc.

In message <_>, whome wrote:

> So, my question:
>
> Is there a higher chance that a file downloaded through the internet will
> be corrupt when ADSL interleaving is switched off?

Theoretically, I would have to say yes. TCP checksumming is quite
simple--has to be, otherwise it would be too slow. So if bits can be
corrupted on the wire, then there is a small chance that a bad packet gets
through with a valid checksum.

This is one reason why it's common practice for open-source sites, at least,
to publish fingerprints of their archive files, that you can verify against
your downloaded copy to ensure it's an exact copy.

Lawrence D'Oliveiro <_zealand> wrote in
news:eghs1b$o6i$:

> Theoretically, I would have to say yes. TCP checksumming is quite
> simple--has to be, otherwise it would be too slow. So if bits can be
> corrupted on the wire, then there is a small chance that a bad packet
> gets through with a valid checksum.
>
> This is one reason why it's common practice for open-source sites, at
> least, to publish fingerprints of their archive files, that you can
> verify against your downloaded copy to ensure it's an exact copy.
>
>

TTL comes into play also. NACK is no good if TTL expired IIRC.
So I would not rely on TCP to transmit good data. I agree that is why we
have MD5 and other checksumming.

--
Ciao, Dave