Hi Eddie
thanks for the clarification. I think this makes clear what Ian's recalculate-loss optimization
does. I am copying this to dccp@ietf as well since a related question was posed there.
What made the analysis so confusing is that [RFC 3448, 5.4] was used as reference, such as in
the following commment.
/* This code implements the part of section 5.4 of RFC3448 which says we should
* recalculate the average loss interval if we have a sufficient long loss
* interval.
It is now, with the below, however clear that the relevant section is not 5.4, but rather
section 6.1 - whichstates that the receiver has to recompute p on reception of each data packet.
And it seems to be the point of Ian's patch to relax this requirement somehow.
Hence you are right, it is not a new technique but rather an attempt to optimise the implementation.
Thanks again for the references.
Gerrit
| Chapter and verse, all from RFC 3448.
|
| 5.4: "When calculating the average loss interval we need to decide whether
| to include the interval since the most recent packet loss event. We
| only do this if it is sufficiently large to increase the average loss
| interval."
|
| ==> If the time since the last loss interval will increase the average
| loss interval, then it should be included.
| ==> Note that the time since the last loss interval will increase on every
| successful packet receipt.
| ==> Therefore we may need to recalculate the average loss interval after
| every successful packet receipt (or, at the sender, on every feedback packet).
|
| 5.4: "I_0 being the interval since the most recent loss event"
|
| ==> I_0 is the time since the last loss interval.
|
| 5.5: "As described in Section 5.4 the average loss interval is calculated
| using the n previous loss intervals I_1, ..., I_n, and the interval
| I_0 that represents the number of packets received since the last
| loss event."
|
| ==> thus I_0 means the same thing in 5.4 and 5.5
|
| 5.5: "I_0 [is] the number of packets received since the last loss event"
|
| ==> yet another way to say the same thing
|
| 5.5: "Note that with each new packet arrival, I_0 will increase further"
|
| ==> YET ANOTHER way to say the same thing.
|
| In summary
| - I_0 is the interval since the most recent loss event
| - I_0 increases with every packet received
| - The average loss interval calculation depends on I_0
| - The average loss interval should be recalculated whenever I_0 changes
| - I_0 changes with every packet received
| - What more can I say here?????
| - All of this average loss interval calculation applies equally to sender and
| receiver; it is in section 5, a general section on "calculating loss event
| rate"; and as the intro to section 5 says, "Loss rate measurement is performed
| at the receiver"
|
| Ian's patch is NOT experimental; Ian is attempting to implement standard
| compliant behavior; Ian's change is documented in the RFCs; etc.; etc.; etc.
|
| Can we put this to bed?
|
| If you still don't understand, please be clearer about why not.
|
| Eddie
|
|
|
|
| Gerrit Renker wrote:
| > | 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.
|
|
