Gerrit,
Now, for (1) we have a bona-fide bug fix and this should be given priority over other issues. With regard
to (2), I say the following: if you can prove or show that using the technique which is embedded into your
algorithm leads to performance improvements in cases such as the following:
| Probably the easiest way to illustrate this is:
| - Fixed 128 kbits second link.
| - Loss occurs when we are only up to 32 kbits per second
| - No loss then occurs again or for a very long time
| - How do we then use the full bandwidth?
then you have tackled an original problem - too precious to just code away as a patch. As far as I know,
this problem has _not been tackled_ neither by any RFC (the closest I can find is RFC 4342, 5.1) nor an Internet
Draft. Ergo, you would have the material for writing an Internet draft which, if the technique indeed helps
performance, would be a valuable contribution to the CCID 3 infrastructure.
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.
Ian's implementation strategy is unconventional, it's true, but he is
attempting to implement RFC-compliant behavior, no more, no less. He
might have a bug, but his code is strictly better and more RFC compliant
than what exists.
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.
Eddie
| This is what I think the RFC is saying.
See above :-)
| > 3) I have a suggestion: you seem to be sure of the merits of this solution and report on
| > test results. My suggestion would be to offer using this method via a configuration
| > option (same as per the nofeedback timer threshold). You could put detailed advice into
| > the kernel configuration menu, and we would have the best of both worlds - a standards-
| > compliant TFRC implementation and a configurable Ian's nifty solution. Would that settle
| > things?
| >
| I'll wait to see the feedback from others first before heading down
| that path. Maybe I can even convince you yet! But if we can't resolve
| that would be good.
I can reformulate this now with regard to (2): the technique is novel and so far not documented
in any RFC/Internet Draft. It would be a valuable addition, but for testing it would be better to have
it as a configuration option so that people can play with it and note the differences between using it
and not using it. Given that most of it is already in the dccp_li_hist_recalcloss function, it does
not seem too hard to encapsulate the algorithm into its own separate function.
Given that you are busy at the moment and that I am bogged down with trying to sort out TX/RX history
locking issues, can we put this on top of the todo list? With regard to the bug fix, I will summarize
in separate posting.
Gerrit
-
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
-
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
