{"push_id":1022101798,"size":45,"distinct_size":0,"ref":"refs/heads/ccid4","head":"48e655e009b435ec6dbca410e46ff878bf6e8c39","before":"2d55b95059a0476d768e68de54c5f38b86dadb01","commits":[{"sha":"fb97e375189d1f03feabd74b9a454625f8654325","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"Add README for Github\n\nTo comply with the directory structure used by github.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/fb97e375189d1f03feabd74b9a454625f8654325"},{"sha":"7c92e16bf6d41f8a3be8975f04383072bdd71fee","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp: Reduce noise in output and convert to ktime_t\n\nThis fixes the problem that dccp_probe output can grow quite large without\napparent benefit (many identical data points), creating huge files (up to\nover one Gigabyte for a few minutes' test run) which are very hard to\npost-process (in one instance it got so bad that gnuplot ate up all memory\nplus swap).\n\nThe cause for the problem is that the kprobe is inserted into dccp_sendmsg(),\nwhich can be called in a polling-mode (whenever the TX queue is full due to\ncongestion-control issues, EAGAIN is returned). This creates many very\nsimilar data points, i.e. the increase of processing time does not increase\nthe quality/information of the probe output.\n\nThe fix is to attach the probe to a different function -- write_xmit was\nchosen since it gets called continually (both via userspace and timer);\nan input-path function would stop sampling as soon as the other end stops\nsending feedback.\n\nFor comparison the output file sizes for the same 20 second test\nrun over a lossy link:\n * before / without patch:  118   Megabytes\n * after  / with patch:       1.2 Megabytes\nand there was much less noise in the output.\n\nTo allow backward compatibility with scripts that people use, the now-unused\n`size' field in the output has been replaced with the CCID identifier. This\nalso serves for future compatibility.\n\nWhile at it, the update to ktime_t was also performed.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>\nAcked-by: Ian McDonald <ian.mcdonald@jandi.co.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/7c92e16bf6d41f8a3be8975f04383072bdd71fee"},{"sha":"95fc2faa84551ab4f07bd854217e2cef2a338a8d","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp: Remove CCID-3 specific code from dccp_probe\n\nThis creates a function pointer to wrap CCID-specific code, since\nCCID-specific code should not be mixed with the general DCCP code\n(in particular when CCID-3 is disabled via Kconfig).\n\nResolving module dependencies did not work satisfactorily in the\ncurrent dccp_probe, so I created an explicit depdency by putting\nthe probe handler into output.c.\n\n% modprobe -v dccp_probe\ninsmod /lib/modules/2.6.28/kernel/net/dccp/dccp.ko\ninsmod /lib/modules/2.6.28/kernel/net/dccp/dccp_probe.ko\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/95fc2faa84551ab4f07bd854217e2cef2a338a8d"},{"sha":"5e7ee3feedc295b6c1e790cbcedf55c4ce73739c","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp: Add dccp_probe support for CCID-2\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/5e7ee3feedc295b6c1e790cbcedf55c4ce73739c"},{"sha":"a7b6e806b07e127dfc42b7721619fd8992842e35","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Runtime verification of timer resolution\n\nThe DCCP base time resolution is 10 microseconds (RFC 4340, 13.1 ... 13.3).\n\nUsing a timer with a lower resolution was found to trigger the following\nbug warnings/problems on high-speed networks (e.g. local loopback):\n * RTT samples are rounded down to 0 if below resolution;\n * in some cases, negative RTT samples were observed;\n * the CCID-3 feedback timer complains that the feedback interval is 0,\n   since the feedback interval is in the order of 1 RTT or less and RTT\n   measurement rounded this down to 0;\nOn an Intel computer this will for instance happen when using a\nboot-time parameter of \"clocksource=jiffies\".\n\nThe following system log messages were observed:\n  11:24:00 kernel: BUG: delta (0) <= 0 at ccid3_hc_rx_send_feedback()\n  11:26:12 kernel: BUG: delta (0) <= 0 at ccid3_hc_rx_send_feedback()\n  11:26:30 kernel: dccp_sample_rtt: unusable RTT sample 0, using min\n  11:26:30 last message repeated 5 times\n\nThis patch defines a global constant for the time resolution, adds this in\ntimer.c, and checks the available clock resolution at CCID-3 module load time.\n\nWhen the resolution is worse than 10 microseconds:\n * module loading exits with a message \"socket type not supported\",\n * when compiled into the kernel, the warning message appears in the\n   kernel log file, but DCCP sockets are not made available.\n\nThe following was obtained when passing\n  clocksource=jiffies\nas kernel parameter (HZ=300):\n[ 2.973217] DCCP: clocksource too coarse (3333 usec), need 10-usec resolution\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/a7b6e806b07e127dfc42b7721619fd8992842e35"},{"sha":"aed141d95b207685b24b87b1bf58718471f703f3","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Simplified handling of TX states\n\nSince CCIDs are only used during the established phase of a connection,\nthey have very little internal state; this specifically reduces to:\n\n * \"no packet sent\" if and only if s == 0, for the TX packet size s;\n\n * when the first packet has been sent (i.e. `s' > 0), the question is whether\n   or not feedback has been received:\n   - if a feedback packet is received, \"feedback = yes\" is set,\n   - if the nofeedback timer expires,  \"feedback = no\"  is set.\n\nThus the CCID only needs to remember state about whether or not feedback\nhas been received. This is now implemented using a boolean flag, which is\ntoggled when a feedback packet arrives or the nofeedback timer expires.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/aed141d95b207685b24b87b1bf58718471f703f3"},{"sha":"a6b6b1ffa212f25cb670138919fa403b048d0c5a","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Suppress unavoidable \"below resolution\" warning\n\nIn the congestion-avoidance phase a decay of p towards 0 is natural once fewer\nlosses are encountered. Hence the warning message \"p is below resolution\" is\nnot necessary, and thus turned into a debug message by this patch.\n\nThe TFRC_SMALLEST_P is needed since in theory p never actually reaches 0. When\nno further losses are encountered, the loss interval I_0 grows in length, \ncausing p to decrease towards 0, causing X_calc = s/(RTT * f(p)) to increase.\n\nWith the given minimum-resolution this congestion avoidance phase stops at some\nfixed value, an approximation formula has been added to the documentation.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/a6b6b1ffa212f25cb670138919fa403b048d0c5a"},{"sha":"03ea2f1a7702d9664a9c41867d9fed4ef5011f47","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Receiver history initialisation routine\n\nThis patch\n 1) separates history allocation and initialisation, to facilitate early\n    loss detection (implemented by a subsequent patch);\n\n 2) removes duplication by using the existing tfrc_rx_hist_purge() if the\n    allocation fails. This is now possible, since the initialisation routine\n 3) zeroes out the entire history before using it.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/03ea2f1a7702d9664a9c41867d9fed4ef5011f47"},{"sha":"4e29cad31c62071b420d4548f0bd6c414075bbd2","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Perform early loss detection\n\nThis enables the TFRC code to begin loss detection (as soon as the module\nis loaded), using the latest updates from rfc3448bis-06, 6.3.1:\n\n * when the first data packet(s) are lost or marked, set\n * X_target = s/(2*R) => f(p) = s/(R * X_target) = 2,\n * corresponding to a loss rate of ~ 20.64%.\n\nThe handle_loss() function is now called right at the begin of rx_packet_recv()\nand thus no longer protected against duplicates: hence a call to rx_duplicate()\nhas been added.  Such a call makes sense now, as the previous patch initialises\nthe first entry with a sequence number of GSR.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/4e29cad31c62071b420d4548f0bd6c414075bbd2"},{"sha":"ad7572bd870762b74d0a24d363dd9f408dd755ed","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Return type of update_i_mean is void\n\nThis changes the return type of tfrc_lh_update_i_mean() to void, since that\nfunction returns always `false'. This is due to\n\n \tlen = dccp_delta_seqno(cur->li_seqno, DCCP_SKB_CB(skb)->dccpd_seq) + 1;\n\n \tif (len - (s64)cur->li_length <= 0)\t/* duplicate or reordered */\n\t\treturn 0;\n\nwhich means that update_i_mean can only increase the length of the open loss\ninterval I_0, and hence the value of I_tot0 (RFC 3448, 5.4). Consequently the\ntest `i_mean < old_i_mean' at the end of the function always evaluates to false.\n\nThere is no known way by which a loss interval can suddenly become shorter,\ntherefore the return type of the function is changed to void. (That is, under\nthe given circumstances step (3) in RFC 3448, 6.1 will not occur.)\n\nFurther changes:\n----------------\n * the function is now called from tfrc_rx_handle_loss, which is equivalent\n   to the previous way of calling from rx_packet_recv (it was called whenever\n   there was no new or pending loss, now  it is also updated when there is\n   a pending loss - this increases the accuracy a bit);\n * added a FIXME to possibly consider NDP counting as per RFC 4342 (this is\n   not implemented yet).\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/ad7572bd870762b74d0a24d363dd9f408dd755ed"},{"sha":"693477db8a456b062cb1c33405b8c5e28a053895","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Let dccp_tfrc_lib do the sampling work\n\nThis migrates more TFRC-related code into the dccp_tfrc_lib:\n * sampling of the packet size `s' (which is only needed until the first\n   loss interval is computed (ccid3_first_li));\n * updating the byte-counter `bytes_recvd' in between sending feedbacks.\nThe result is a better separation of CCID-3 specific and TFRC specific\ncode, which aids future integration with ECN and e.g. CCID-4.\n\nFurther changes:\n----------------\n * replaced magic number of 536 with equivalent constant TCP_MSS_DEFAULT;\n   (this constant is also used when no estimate for `s' is available).\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/693477db8a456b062cb1c33405b8c5e28a053895"},{"sha":"29016303a8cf46ad015dc476117a0c9dda6ba259","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Remove duplicate RX states\n\nThe only state information that the CCID-3 receiver keeps is whether initial\nfeedback has been sent or not. Further, this overlaps with use of feedback:\n\n * state == TFRC_RSTATE_NO_DATA as long as no feedback has been sent;\n * state == TFRC_RSTATE_DATA    as soon as the first feedback has been sent.\n\nThis patch reduces the duplication, by memorising the type of the last feedback.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/29016303a8cf46ad015dc476117a0c9dda6ba259"},{"sha":"d56cce50db2ba4a69ac093e683e2ef7db8afb1c6","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Always perform receiver RTT sampling\n\nThis updates the CCID-3 receiver in part with regard to errata 610 and 611\n(http://www.rfc-editor.org/errata_list.php), which change RFC 4342 to use the\nReceive Rate as specified in rfc3448bis, requiring to constantly sample the\nRTT (or use a sender RTT).\n\nDoing this requires reusing the RX history structure after dealing with a loss.\n\nThe patch does not resolve how to compute X_recv if the interval is less\nthan 1 RTT. A FIXME has been added (and is resolved in subsequent patch).\n\nFurthermore, since this is all TFRC-based functionality, the RTT estimation\nis now also performed by the dccp_tfrc_lib module. This further simplifies\nthe CCID-3 code.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/d56cce50db2ba4a69ac093e683e2ef7db8afb1c6"},{"sha":"3ed8e112cb667349b726a2c74b0c8b676533e895","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp: Clamping RTT values\n\nThis extracts the clamping part of dccp_sample_rtt() and makes it available\nto other parts of the code (as e.g. used in the next patch).\n\nNote: The function dccp_sample_rtt() now reduces to subtracting the elapsed\ntime. This could be eliminated but would require shorter prefixes and thus\nis not done by this patch - maybe an idea for later.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/3ed8e112cb667349b726a2c74b0c8b676533e895"},{"sha":"842c9acee19852d5e0d5a03f50e994b04d4d9c59","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp tfrc: Increase number of RTT samples\n\nThis improves the receiver RTT sampling algorithm so that it tries harder to get\nas many RTT samples as possible. \n\nThe algorithm is based the concepts presented in RFC 4340, 8.1, using timestamps\nand the CCVal window counter. There exist 4 cases for the CCVal difference:\n * == 0: less than RTT/4 passed since last packet -- unusable;\n *  > 4: (much) more than 1 RTT has passed since last packet -- also unusable;\n * == 4: perfect sample (exactly one RTT has passed since last packet);\n * 1..3: sub-optimal sample (between RTT/4 and 3*RTT/4 has passed).\n\nIn the last case the algorithm tried to optimise by storing away the candidate\nand then re-trying next time. The problem is that\n * a large number of samples is needed to smooth out the inaccuracies of the\n   algorithm;\n * the sender may not be sending enough packets to warrant a \"next time\";\n * hence it is better to use suboptimal samples whenever possible.\nThe algorithm now stores away the current sample only if the difference is 0.\n\nApplicability and background\n----------------------------\nA realistic example is MP3 streaming where packets are sent at a rate of less\nthan one packet per RTT, which means that suitable samples are absent for a\nvery long time.\n\nThe effectiveness of using suboptimal samples (with a delta between 1 and 4) was\nconfirmed by instrumenting the algorithm with counters. The results of two 20\nsecond test runs were:\n * With the old algorithm and a total of 38442 function calls, only 394 of these\n   calls resulted in usable RTT samples (about 1%), and 378 out of these were\n   \"perfect\" samples and 28013 (unused) samples had a delta of 1..3.\n * With the new algorithm and a total of 37057 function calls, 1702 usable RTT\n   samples were retrieved (about 4.6%), 5 out of these were \"perfect\" samples.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/842c9acee19852d5e0d5a03f50e994b04d4d9c59"},{"sha":"7e7a8a28c4f35a89c3ecb455be780adc54f2c0ef","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Update the computation of X_recv\n\nThis updates the computation of X_recv with regard to Errata 610/611 for\nRFC 4342 and draft rfc3448bis-06, ensuring that at least an interval of 1\nRTT is used to compute X_recv.  The change is wrapped into a new function\nccid3_hc_rx_x_recv().\n\nFurther changes:\n----------------\n * feedback is not sent when no data packets arrived (bytes_recv == 0), as per\n   rfc3448bis-06, 6.2;\n * take the timestamp for the feedback /after/ dccp_send_ack() returns, to avoid\n   taking the transmission time into account (in case layer-2 is busy);\n * clearer handling of failure in ccid3_first_li().\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/7e7a8a28c4f35a89c3ecb455be780adc54f2c0ef"},{"sha":"0737e1c2e75a726883635886c85da7e8d9926cc3","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Update the RX history records in one place\n\nThis patch is a requirement for enabling ECN support later on. With that change\nin mind, the following preparations are done:\n * renamed handle_loss() into congestion_event() since it returns true when a\n   congestion event happens (it will eventually also take care of ECN packets);\n * lets tfrc_rx_congestion_event() always update the RX history records, since\n   this routine needs to be called for each non-duplicate packet anyway;\n * made all involved boolean-type functions to have return type `bool';\n\nUpdating the RX history records is now only necessary for the packets received\nup to sending the first feedback. The receiver code becomes again simpler.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/0737e1c2e75a726883635886c85da7e8d9926cc3"},{"sha":"2ace705041cf1f78a43cb1a0d7c7c5e93f303071","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Implement rfc3448bis change to initial-rate computation\n\nThe patch updates CCID-3 with regard to the latest rfc3448bis-06:\n * in the first revisions of the draft, MSS was used for the RFC 3390 window;\n * then (from revision #1 to revision #2), it used the packet size `s';\n * now, in this revision (and apparently final), the value is back to MSS.\n\nThis change has an implication for the case when no RTT sample is available,\nat the time of sending the first packet:\n\n * with RTT sample, 2*MSS/RTT <= initial_rate <= 4*MSS/RTT;\n * without RTT sample, the initial rate is one packet (s bytes) per second\n   (sec. 4.2), but using s instead of MSS here creates an imbalance, since\n   this would further reduce the initial sending rate.\n\nHence the patch uses MSS (called MPS in RFC 4340) in all places.\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/2ace705041cf1f78a43cb1a0d7c7c5e93f303071"},{"sha":"a7e2dc64891990d049450f5de9f24d686f317e06","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Measuring the packet size s with regard to rfc3448bis-06\n\nrfc3448bis allows three different ways of tracking the packet size `s':\n\n 1. using the MSS/MPS (at initialisation, 4.2, and in 4.1 (1));\n 2. using the average of `s' (in 4.1);\n 3. using the maximum of `s' (in 4.2).\n\nInstead of hard-coding a single interpretation of rfc3448bis, this implements\na choice of all three alternatives and suggests the first as default, since it\nis the option which is most consistent with other parts of the specification.\n\nThe patch further deprecates the update of t_ipi whenever `s' changes. The\ngains of doing this are only small since a change of s takes effect at the\nnext instant X is updated:\n * when the next feedback comes in (within one RTT or less);\n * when the nofeedback timer expires (within at most 4 RTTs).\n\nFurther, there are complications caused by updating t_ipi whenever s changes:\n * if t_ipi had previously been updated to effect oscillation prevention (4.5),\n   then it is impossible to make the same adjustment to t_ipi again, thus\n   counter-acting the algorithm;\n * s may be updated any time and a modification of t_ipi depends on the current\n   state (e.g. no oscillation prevention is done in the absence of feedback);\n * in rev-06 of rfc3448bis, there are more possible cases, depending on whether\n   the sender is in slow-start (t_ipi <= R/W_init), or in congestion-avoidance,\n   limited by X_recv or the throughput equation (t_ipi <= t_mbi).\n\nThus there are side effects of always updating t_ipi as s changes. These may not\nbe desirable. The only case I can think of where such an update makes sense is\nto recompute X_calc when p > 0 and when s changes (not done by this patch).\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/a7e2dc64891990d049450f5de9f24d686f317e06"},{"sha":"a9183707fc22dae2a3b62aec6fb22cf75131461c","author":{"email":"3b97070d46ccd66422a8e7b83e6967ed84780538@erg.abdn.ac.uk","name":"Gerrit Renker"},"message":"dccp ccid-3: Simplify computing and range-checking of t_ipi\n\nThis patch simplifies the computation of t_ipi, avoiding expensive computations\nto enforce the minimum sending rate.\n\nBoth RFC 3448 and rfc3448bis (revision #06), as well as RFC 4342 sec 5., require\nat various stages that at least one packet must be sent per t_mbi = 64 seconds.\nThis requires frequent divisions of the type X_min = s/t_mbi, which are later\nconverted back into an inter-packet-interval t_ipi_max = s/X_min = t_mbi.\n\nThe patch removes the expensive indirection; in the unlikely case of having\na sending rate less than one packet per 64 seconds, it also re-adjusts X.\n\nThe following cases document conformance with RFC 3448  / rfc3448bis-06:\n 1) Time until receiving the first feedback packet:\n   * if the sender has no initial RTT sample then X = s/1 Bps > s/t_mbi;\n   * if the sender has an initial RTT sample or when the first feedback\n     packet is received, X = W_init/R > s/t_mbi.\n\n 2) Slow-start (p == 0 and feedback packets come in):\n   * RFC 3448  (current code) enforces a minimum of s/R > s/t_mbi;\n   * rfc3448bis (future code) enforces an even higher minimum of W_init/R.\n\n 3) Congestion avoidance with no absence of feedback (p > 0):\n   * when X_calc or X_recv/2 are too low, the minimum of X_min = s/t_mbi\n     is enforced in update_x() when calling update_send_interval();\n   * update_send_interval() is, as before, only called when X changes\n     (i.e. either when increasing or decreasing, not when in equilibrium).\n\n 4) Reduction of X without prior feedback or during slow-start (p==0):\n   * both RFC 3448 and rfc3448bis here halve X directly;\n   * the associated constraint X >= s/t_mbi is nforced here by send_interval().\n\n 5) Reduction of X when p > 0:\n   * X is modified indirectly via X_recv (RFC 3448) or X_recv_set (rfc3448bis);\n   * in both cases, control goes back to section 4.3 (in both documents);\n   * since p > 0, both documents use X = max(min(...), s/t_mbi), which is\n     enforced in this patch by calling send_interval() from update_x().\n\nI think that this analysis is exhaustive. Should I have forgotten a case,\nthe worst-case consideration arises when X sinks below s/t_mbi, and is then\nincreased back up to this minimum value. Even under this assumption, the\nbehaviour is correct, since all lower limits of X in RFC 3448 / rfc3448bis\nare either equal to or greater than s/t_mbi.\n\nNote on the condition X >= s/t_mbi  <==> t_ipi = s/X <= t_mbi: since X is\nscaled by 64, and all time units are in microseconds, the coded condition is:\n\n    t_ipi = s * 64 * 10^6 usec / X <= 64 * 10^6 usec\n\nThis simplifies to s / X <= 1 second <==> X * 1 second >= s > 0.\n(A zero `s' is not allowed by the CCID-3 code).\n\nSigned-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>","distinct":false,"url":"https://api.github.com/repos/uoaerg/linux-dccp/commits/a9183707fc22dae2a3b62aec6fb22cf75131461c"}]}