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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
