linux-kernel - Re: unexpected newReno behavior in 2.6.21.5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <467976DC.3070209@redhat.com>
Date:	Wed, 20 Jun 2007 14:50:04 -0400
From:	Chuck Ebbert <cebbert@...hat.com>
To:	Sushant <sushantsharma@...il.com>
CC:	linux-kernel@...r.kernel.org, Netdev <netdev@...r.kernel.org>
Subject: Re: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/