netdev - Re: [PATCH next resend] tcp: use zero-window when free

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Feb 2014 08:19:46 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Florian Westphal <fw@...len.de>
Cc:	netdev@...r.kernel.org, Neal Cardwell <ncardwell@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH next resend] tcp: use zero-window when free_space is low

On Thu, 2014-02-13 at 16:34 +0100, Florian Westphal wrote:
> Eric Dumazet <eric.dumazet@...il.com> wrote:

> > Would you mind waiting we run our packetdrill tests before acknowledging
> > this patch, because I suspect this might have some impact ?
> 
> Of course not.  I am very happy that you folks have these kinds of tests
> and are willing to double-check.  Take all time you need, there is no
> need to haste.
> 


We have today 348 different packetdrill tests, and this number keeps
increasing ;)

> Many Thanks Eric.
> 
> Do you think it makes sense to add counters for this?
> 
> The caveat is that decision to send 0 window doesn't mean we end
> up sending one, since we cannot shrink already offered window.
> 
> static u16 tcp_select_window(struct sock *sk)
> {
>     struct tcp_sock *tp = tcp_sk(sk);
>     u32 cur_win = tcp_receive_window(tp);
>     u32 new_win = __tcp_select_window(sk);
> 
>     /* Never shrink the offered window */
>     if (new_win < cur_win) {
> 
> Would you add SNMP counter for '__tcp_select_window() wants 0 window'
> or for 'tcp_select_window() does pick 0 window' ?
> 
> [ or even different counters for both ? ]

Ideally, having counters of transitions would be nice.

This would help us to spot regressions in TCP stacks or network drivers,
or wrong application tunings.

One counter tracking number of times a socket went from a non zero
window to a zero window (as you said, I am referring to effective window
being sent)

One counter tracking the reverse.

If it proves being too complex or expensive, a single counter tracking
"win 0" sent to the peers.



--
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