lkml.org 
[lkml]   [2007]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: unexpected newReno behavior in 2.6.21.5
On 06/20/2007 02:27 PM, Sushant wrote:

Sushant, you should be sending this kind of message to netdev.
[cc'd]

> Hi all,
> I am currently doing some analysis on the TCP newReno implementation
> in the Linux kernel and it looks like the sender behavior is not
> expected. Here is what I am observing.
>
> Linux kernel: stable version 2.6.21.5
>
> 1) _sometimes_, there is no fast recovery: i.e. after receiving three
> DUP acks, the sender is not transmitting new packets in response to
> the more DUP acks it is receiving after the first three. It does
> retransmit the lost packet after 3 DUP acks though.
>
> 2) Delayed fast retransmit: _sometimes_, instead of retransmitting the
> lost packet after receiving 3 DUP acks, sender waits for large number
> (which is 127 most of the time) of DUP acks before retransmitting the
> lost packet. But, it keeps on transmitting a new packet for every one
> of 127 DUP acks it is receiving.
>
> Has someone seen this behavior or is this behavior expected under some
> scenarios. I am using wireshark (previously ethereal) on sender to
> analyze all this. I can provide logs if needed or any other
> information that you might need. I have provided my sysctl output for
> TCP parameters at the end of my mail.
>
> Please cc the replies to me as I am not subscribed to the list.
>
> TIA
> -Sushant
>
>
> # /sbin/sysctl -a | grep tcp
> net.ipv4.tcp_timestamps = 1
> net.ipv4.tcp_window_scaling = 1
> net.ipv4.tcp_sack = 0
> net.ipv4.tcp_retrans_collapse = 1
> net.ipv4.tcp_syn_retries = 5
> net.ipv4.tcp_synack_retries = 5
> net.ipv4.tcp_max_orphans = 32768
> net.ipv4.tcp_max_tw_buckets = 180000
> net.ipv4.tcp_keepalive_time = 7200
> net.ipv4.tcp_keepalive_probes = 9
> net.ipv4.tcp_keepalive_intvl = 75
> net.ipv4.tcp_retries1 = 3
> net.ipv4.tcp_retries2 = 15
> net.ipv4.tcp_fin_timeout = 60
> net.ipv4.tcp_syncookies = 1
> net.ipv4.tcp_tw_recycle = 0
> net.ipv4.tcp_abort_on_overflow = 0
> net.ipv4.tcp_stdurg = 0
> net.ipv4.tcp_rfc1337 = 0
> net.ipv4.tcp_max_syn_backlog = 1024
> net.ipv4.tcp_orphan_retries = 0
> net.ipv4.tcp_fack = 1
> net.ipv4.tcp_reordering = 3
> net.ipv4.tcp_ecn = 0
> net.ipv4.tcp_dsack = 1
> net.ipv4.tcp_mem = 1048576 1048576 1048576
> net.ipv4.tcp_wmem = 1048576 1048576 1048576
> net.ipv4.tcp_rmem = 1048576 1048576 1048576
> net.ipv4.tcp_app_win = 31
> net.ipv4.tcp_adv_win_scale = 3
> net.ipv4.tcp_tw_reuse = 0
> net.ipv4.tcp_frto = 0
> net.ipv4.tcp_low_latency = 0
> net.ipv4.tcp_no_metrics_save = 1
> net.ipv4.tcp_moderate_rcvbuf = 1
> net.ipv4.tcp_tso_win_divisor = 3
> net.ipv4.tcp_congestion_control = reno
> net.ipv4.tcp_abc = 0
> net.ipv4.tcp_mtu_probing = 0
> net.ipv4.tcp_base_mss = 512
> net.ipv4.tcp_workaround_signed_windows = 0
> net.ipv4.tcp_slow_start_after_idle = 1
> net.ipv4.tcp_available_congestion_control = reno bic cubic
> net.ipv4.tcp_allowed_congestion_control = reno
> sunrpc.tcp_slot_table_entries = 16
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-20 20:55    [W:0.301 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site