Eddie,
sorry to trouble you with yet another question, but it is extremely important
to get this
right. This concerns the length of I_0, the interval since the most recent loss
event.
In the current implementation, we are relying on the highest sequence numbers
received
before a loss occurred. Using the terminology from [RFC 4342, 10.2], this
corresponds
to X_prev and Y_prev.
For subsequent loss intervals (assuming that more than 1 RTT lies between
X_prev/Y_prev),
we can compute the loss interval length [RFC 3448, 5.3] as modulo-2^48 distance
between
X_prev and Y_prev.
( Strictly speaking, the first packet known to be lost - starting the loss
event -
has sequence number (X_prev + 1) % 2^48. Since the next loss event begins at
sequence
number (Y_prev + 1) % 2^48, the distance is however the same as from X_prev
to Y_prev. )
With the open loss interval I_0, however, the situation is different. In [RFC
3448, 5.5],
I_0 is defined as "the number of packets received since the last loss event".
Taking this
literally means the following:
* at the instant this loss is detected, I_0 = 3
(since NUMDUPACK=3 packets need to be received to identify a loss event)
* when the first data packet after the loss arrives, I_0 = 4,
* when the i-th data packet after the loss arrives, I_0 = 3 + i
* ... and so on until the next loss is detected
Question: Is this reasoning correct, or is the intention to determine the
number of
data packets in I_0 by using X_prev and simply subtracting X_prev
from the
sequence number of the currently received packet (modulo 2^48)?
The first variant seems to be conform with the RFC, the latter is conform with
the way
the other loss intervals are computed.
Resolving this will help to clear up the loss detection algorithm we are
currently using.
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
