[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de0a9dcb1003170523v104ec57bs6ab31161c75131f1@mail.gmail.com>
Date: Wed, 17 Mar 2010 17:53:43 +0530
From: raj ravi <mekaviraj@...il.com>
To: netdev@...r.kernel.org
Cc: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Subject: Re: tcp_reordering as 0 possible?
On Wed, Mar 17, 2010 at 5:08 PM, Ilpo Järvinen
<ilpo.jarvinen@...sinki.fi> wrote:
> On Mon, 15 Mar 2010, raj ravi wrote:
>
>> what is the behaviour in TCP stack if I set tcp_reordering as 0.
>> So , sender will start retransmission without waiting for any duplicate ACK ?
>> /proc/sys/net/ipv4/tcp_reordering - Please clarify.
>> The default value is 3 which means it waits until 3 duplicate ack's
>> arrive and then start retransmission.
>>
>> "The TCP sender should use the fast retransmit algorithm to detect and
>> repair loss based on incoming duplicate ACKs. After the arrival of 3
>> duplicate ACKs (4 identical ACKs without the arrival of any other
>> intervening packet), TCP performs a retransmission of what appears to
>> be the missing segment, without waiting for the retransmission timer
>> to expire."
>
> Depends on other things quite much but for a typical transfer you'd still
> need one duplicate ACK to trigger actual recovery. However, in general
> root is not (always) forbidden to set non-sensical values for sysctls.
>
> --
> i.
>
Hmm....Is that mean setting the value as 0 is non-sensical ?
OR
After setting the value as 0, TCP Stack doesn't expect any drops to
occur, so that there won't be any recovery required and if any drops
occur it leads to chaos from application point of view as it expects
all the packets ...correct?
Actually I set the value as 0 and tried running firefox with few URLs
...but my machine Crashed !
I think this is expected as This lead to chaos in the stack...
But If the same value is tried between two machines connected
together directly running iperf , There wont be any issues.
Thx,
Kavi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists