netdev - Re: dccp test-tree [RFC] [Patch 1/1] dccp: Only activate NN values after receiving the Confirm option

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:	Fri, 18 Mar 2011 12:30:52 +0100
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Samuel Jero <sj323707@...o.edu>
Cc:	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: dccp test-tree [RFC] [Patch 1/1] dccp: Only activate NN values
	after receiving the Confirm option

I have revised the patch set addressing the following comments of this thread:

 1) Renamed function to dccp_feat_nn_get().
 2) Added test to ensure that function is called for NN
    features back in.
 3) Replaced ccid2_ack_ratio_next() with calls to that
    function (dccp_feat_nn_get(sk, DCCPF_ACK_RATIO)).
 4) Replaced check for dccps_l_seq_win in ccid2_change_l_seq_window 
    with call to dccp_feat_nn_get(sk, DCCPF_SEQUENCE_WINDOW)
    (for similar calls see separate, attached patch).
 5) De-inlined ccid2_ack_ratio_next() wrapper as discussed.
 6) Updated remaining patches with regard to 1-4.

In (4) I created a separate patch. You mentioned earlier replacing references to
local seq_window with a call to the accessor function, these were the remaining
references, I noticed no regression.

This is all in the test tree, just uploaded 2.6.38
     git://eden-feed.erg.abdn.ac.uk/dccp_exp	[subtree 'dccp']

| > I don't know if blocking the Ack Ratio code is the reason, but during the
| > initial slow-start there were ChangeL requests for Sequence Window on nearly
| > every packet, which seems too much.
| 
| Right now, Change's are sent on every packet until the matching Confirm
| is received. That will be the cause of most of the Change's you are
| seeing.
| 
| The other thing is that at the beginning of a connection the sequence
| window will be reduced and then increased. The initial window of 100
| packets is too wide for 5*cwnd at the start of the connection. So the
| window will be reduced as low as it will go at the very beginning of the
| connection. However, as slow start picks up, cwnd will increase and the
| sequence window will as well.
| 
| I've seen the above behavior, but haven't thought of an effective
| solution (nor am I sure that we need a solution). Capping the minimum
| sequence window at the default (100 packets) would solve this, but that
| doesn't seem like a great solution.
| 
| > 
| > If low_threshold == high_threshold, it oscillates. I think you have already done
| > some work on this in the code using CCID2_WIN_CHANGE_FACTOR.
| 
| I'm not entirely certain what low_threshold and high_threshold you are
| talking about. I have not seen sequence window oscillations other as the
| congestion window oscillates in congestion avoidance as is expected.
|
I meant a Schmitt Trigger like behaviour:
 * low_threshold: to change from lower value to higher value 
 * hi_threshold:  to revert from higher value back to lower value
In these electronic devices there is a gap between low and hi, to avoid fluctuations.
Also audio effect gates have a similar setting.

With regard to your comment about the 100 packets at the begin, I was wondering if
the connection could not grossly exaggerate, or maybe even use the 100 packets.

But all that is not a big deal, stuff for fine-tuning the now much better ccid2 
engine. 

Thank you for all your good work. The comments helped a great deal too.

View attachment "remaining_l_seq_win_refs.diff" of type "text/x-diff" (1813 bytes)