Can someone please offer an expert opinion on the following TFRC problem:
==> Section 5.4 talks about calculating the average loss interval
==> The issue is the following sentence: " we need to decide whether
to include the interval since the most recent packet loss event." (*)
==> I am arguing that this is already taken care of by the way I_tot0 and I_tot1
are compared, i.e. the statement "I_tot = max(I_tot0, I_tot1)" enforces (*)
==> True or False?
| > | This is making the code conform to RFC 3448, section 5.4
| > I think there is a big misunderstanding here and the existing code, as far as I can see,
| > already conforms to [RFC 3448, 5.4].
| >
| > I got alerted when I re-read the following comment:
| > /* 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.
| > There is no such statement in RFC 3448, 5.4. The most close to this is
| > "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."
|
| The RFC is a little confusing but I think I have carried out it's
| intention correctly. I'll quote verbatim here the relevant parts:
|
| 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.
|
| Thus if the most recent loss intervals are I_0 to I_n, with I_0 being
| the interval since the most recent loss event, then we calculate the
| average loss interval I_mean as:
|
| Notice here the "interval since the most recent packet loss event".
| This implies (but would help if explicit) that this is an interval
| with no loss. We only use if it would increase the average.
|
-
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
