<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/dccp/ccids, branch linux-2.6.27.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.27.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-2.6.27.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2008-07-13T10:51:40Z</updated>
<entry>
<title>dccp ccid-3: Length of loss intervals</title>
<updated>2008-07-13T10:51:40Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-07-13T10:51:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2eeea7ba6b4b65ed27b7646a1bdea3b45973c861'/>
<id>urn:sha1:2eeea7ba6b4b65ed27b7646a1bdea3b45973c861</id>
<content type='text'>
This corrects an error in the computation of the open loss interval I_0:
  * the interval length is (highest_seqno - start_seqno) + 1
  * and not (highest_seqno - start_seqno).

This condition was not fully clear in RFC 3448, but reflects the current
revision state of rfc3448bis and is also consistent with RFC 4340, 6.1.1.

Further changes:
----------------
 * variable renamed due to line length constraints;
 * explicit typecast to `s64' to avoid implicit signed/unsigned casting.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: Fix a loss detection bug</title>
<updated>2008-07-13T10:51:40Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-07-13T10:51:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b552c6231f19d50165bbf59e8b34d3f713ab5c01'/>
<id>urn:sha1:b552c6231f19d50165bbf59e8b34d3f713ab5c01</id>
<content type='text'>
This fixes a bug in the logic of the TFRC loss detection:
 * new_loss_indicated() should not be called while a loss is pending;
 * but the code allows this;
 * thus, for two subsequent gaps in the sequence space, when loss_count
   has not yet reached NDUPACK=3, the loss_count is falsely reduced to 1.

To avoid further and similar problems, all loss handling and loss detection is
now done inside tfrc_rx_hist_handle_loss(), using an appropriate routine to
track new losses.

Further changes:
----------------
 * added a reminder that no RX history operations should be performed when
   rx_handle_loss() has identified a (new) loss, since the function takes
   care of packet reordering during loss detection;
 * made tfrc_rx_hist_loss_pending() bool (thanks to an earlier suggestion
   by Arnaldo);		 
 * removed unused functions.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp: Upgrade NDP count from 3 to 6 bytes</title>
<updated>2008-07-13T10:51:40Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-07-13T10:51:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5b5d0e704880addfd979c262e6441f126708539c'/>
<id>urn:sha1:5b5d0e704880addfd979c262e6441f126708539c</id>
<content type='text'>
RFC 4340, 7.7 specifies up to 6 bytes for the NDP Count option, whereas the code
is currently limited to up to 3 bytes. This seems to be a relict of an earlier 
draft version and is brought up to date by the patch.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: Fix error in loss detection</title>
<updated>2008-07-13T10:51:40Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-07-13T10:51:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2013c7e35aeba39777f9b3eef8a70207b3931152'/>
<id>urn:sha1:2013c7e35aeba39777f9b3eef8a70207b3931152</id>
<content type='text'>
The TFRC loss detection code used the wrong loss condition (RFC 4340, 7.7.1):
 * the difference between sequence numbers s1 and s2 instead of 
 * the number of packets missing between s1 and s2 (one less than the distance).

Since this condition appears in many places of the code, it has been put into a
separate function, dccp_loss_free().

Further changes:
----------------
 * tidied up incorrect typing (it was using `int' for u64/s64 types);
 * optimised conditional statements for common case of non-reordered packets;
 * rewrote comments/documentation to match the changes.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: X truncated due to type conversion</title>
<updated>2008-06-11T10:19:10Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-06-11T10:19:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7deb0f851003287d7e259bf6b33548b144c0f2d5'/>
<id>urn:sha1:7deb0f851003287d7e259bf6b33548b144c0f2d5</id>
<content type='text'>
This fixes a bug in computing the inter-packet-interval t_ipi = s/X: 

 scaled_div32(a, b) uses u32 for b, but in "scaled_div32(s, X)" the type of the
 sending rate `X' is u64. Since X is scaled by 2^6, this truncates rates greater
 than 2^26 Bps (~537 Mbps).

Using full 64-bit division now.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: TFRC reverse-lookup Bug-Fix</title>
<updated>2008-06-11T10:19:10Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-06-11T10:19:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1e8a287c79f64226541f5c44aa52d4698bb84cf5'/>
<id>urn:sha1:1e8a287c79f64226541f5c44aa52d4698bb84cf5</id>
<content type='text'>
This fixes a bug in the reverse lookup of p: given a value f(p), instead of p,
the function returned the smallest tabulated value f(p).

The smallest tabulated value of
	 
   10^6 * f(p) =  sqrt(2*p/3) + 12 * sqrt(3*p/8) * (32 * p^3 + p) 

for p=0.0001 is 8172. 

Since this value is scaled by 10^6, the outcome of this bug is that a loss
of 8172/10^6 = 0.8172% was reported whenever the input was below the table
resolution of 0.01%.

This means that the value was over 80 times too high, resulting in large spikes
of the initial loss interval, thus unnecessarily reducing the throughput.

Also corrected the printk format (%u for u32).

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp: Fix sparse warnings</title>
<updated>2008-06-11T10:19:09Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-06-11T10:19:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1e2f0e5e8376f2a0ada8760fc9d3104e1a81382b'/>
<id>urn:sha1:1e2f0e5e8376f2a0ada8760fc9d3104e1a81382b</id>
<content type='text'>
This patch fixes the following sparse warnings:
 * nested min(max()) expression:
   net/dccp/ccids/ccid3.c:91:21: warning: symbol '__x' shadows an earlier one
   net/dccp/ccids/ccid3.c:91:21: warning: symbol '__y' shadows an earlier one
   
 * Declaration of function prototypes in .c instead of .h file, resulting in
   "should it be static?" warnings. 

 * Declared "struct dccpw" static (local to dccp_probe).
 
 * Disabled dccp_delayed_ack() - not fully removed due to RFC 4340, 11.3
   ("Receivers SHOULD implement delayed acknowledgement timers ...").

 * Used a different local variable name to avoid
   net/dccp/ackvec.c:293:13: warning: symbol 'state' shadows an earlier one
   net/dccp/ackvec.c:238:33: originally declared here

 * Removed unused functions `dccp_ackvector_print' and `dccp_ackvec_print'.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: Bug-Fix - Zero RTT is possible</title>
<updated>2008-06-11T10:19:09Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-06-11T10:19:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3294f202dc1acd82223e83ef59f272bd87bb06b2'/>
<id>urn:sha1:3294f202dc1acd82223e83ef59f272bd87bb06b2</id>
<content type='text'>
In commit $(825de27d9e40b3117b29a79d412b7a4b78c5d815) (from 27th May, commit
message `dccp ccid-3: Fix "t_ipi explosion" bug'), the CCID-3 window counter
computation was fixed to cope with RTTs &lt; 4 microseconds.

Such RTTs can be found e.g. when running CCID-3 over loopback. The fix removed
a check against RTT &lt; 4, but introduced a divide-by-zero bug.

All steady-state RTTs in DCCP are filtered using dccp_sample_rtt(), which
ensures non-zero samples. However, a zero RTT is possible on initialisation,
when there is no RTT sample from the Request/Response exchange.

The fix is to use the fallback-RTT from RFC 4340, 3.4.

This is also better than just fixing update_win_count() since it allows other
parts of the code to always assume that the RTT is non-zero during the time
that the CCID is used.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>dccp ccid-3: Fix "t_ipi explosion" bug</title>
<updated>2008-05-27T13:33:54Z</updated>
<author>
<name>Gerrit Renker</name>
</author>
<published>2008-05-27T13:33:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=825de27d9e40b3117b29a79d412b7a4b78c5d815'/>
<id>urn:sha1:825de27d9e40b3117b29a79d412b7a4b78c5d815</id>
<content type='text'>
The identification of this bug is thanks to Cheng Wei and Tomasz
Grobelny.

To avoid divide-by-zero, the implementation previously ignored RTTs
smaller than 4 microseconds when performing integer division RTT/4.

When the RTT reached a value less than 4 microseconds (as observed on
loopback), this prevented the Window Counter CCVal value from
advancing. As a result, the receiver stopped sending feedback. This in
turn caused non-ending expiries of the nofeedback timer at the sender,
so that the sending rate was progressively reduced until reaching the
minimum of one packet per 64 seconds.

The patch fixes this bug by handling integer division more
intelligently. Due to consistent use of dccp_sample_rtt(),
divide-by-zero-RTT is avoided.

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>dccp: ccid2.c, ccid3.c use clamp(), clamp_t()</title>
<updated>2008-05-02T23:44:07Z</updated>
<author>
<name>Harvey Harrison</name>
</author>
<published>2008-05-02T23:44:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=84994e16f25dabe234be4fc2d323ec9db95b87cb'/>
<id>urn:sha1:84994e16f25dabe234be4fc2d323ec9db95b87cb</id>
<content type='text'>
Makes the intention of the nested min/max clear.

Signed-off-by: Harvey Harrison &lt;harvey.harrison@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
