| Um, you misunderstand. The problem that Ian's patch addresses seems
| entirely within the purview of RFC 3448/4342. He is not trying to
| innovate. Recalculating the loss rate after a longer period of non-loss
| is NOT EXPERIMENTAL it is REQUIRED. The loss event rate is NOT
| calculated ONLY when losses are detected. It must be calculated on
| every feedback packet. I don't have time at the moment to look up
| chapter and verse, maybe later.
Please take another look at the patch: what you are saying is true but applies to the _sender_, but Ian's
code is entirely within the _receiver_. We are not at 4342 yet, at the moment the receiver calculates
the loss event rate and then contacts the receiver.
Can you please look up chapter and verse -- I have read all related documents and can only identify
section 5.4 of RFC 3448. With regard to this, we are in agreement: this needs to be audited to be conform.
But with regard to recalculating the loss rate after a longer period of non-loss:
==> either there is indeed a reference for this in the current RFCs (it is not [RFC 3448, 5.4] and not the
corresponding section in 3448bis) but then neither Ian nor I have found this
==> or there is no such reference and then we should clearly separate the issues into (a) making sure that
the code complies to [RFC 3448, 5.4] and (b) what do we do with the "recalculating the loss rate after
a longer period of non-loss" ?
| I think (for what it's worth) his patch should be accepted as is, and
| maybe he, or someone, will simplify the recalc_recalcloss part later.
I agree with the points you raised, but disagree with adding an experimental part. The reason is that
the CCID 3 module is still seriously broken:
* from the output of dccp_probe one can see that the entire system is oscillating and not
reaching a stable fixed point; even under ideal, non-loss conditions
* the behaviour using tools such as iperf is unpredictable
* performance is very poor: sometimes, on a good day one gets 50% of the bandwidth, but at other
test runs the speed goes down to only a couple of Mbits/sec (and this with a loss rate of 0)
Therefore my suggestion is for the moment to only put in changes which are documented in the RFCs, fix
all these bugs, and add everything else once the basic problems have been sorted out.
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
