Eddie, many thanks for the answer; which does clarify an issue which has cost quite a lot of reading RFC 3448 / 4342. In particular the example you give below, where I_0 is promoted to I_1, makes quite clear that - despite the wording in RFC 3448 - it is indeed better to use the distance from X_prev to measure the interval I_0. It is also more consistent with the way I_1 ... I_k are computed, so I think the Linux implementation is heading in the right direction. Cheers Gerrit Quoting Eddie Kohler: | Hi Gerrit, | | Strictly speaking one can identify a loss event with a single ECN-marked | packet, so I_0 might be < 3, but let that pass. The RFC occasionally | uses "lost" to mean "lost or marked". | | The correct answer is simply to subtract X_prev from the sequence number | of the currently received packet. This is certainly what we were | thinking while writing RFC4342, although I don't have time now to check | whether the text actually defines this explicitly. | | I'm almost certain but am cc'ing the IETF list for possible correction. | | Among the reasons for this choice is that if you measure it the other | way, I_0 will use different units from every other loss interval length. | | However, to be honest, I'd say that RFC3448 appears to define it as | "number of packets received since last loss event". I think this is a | misstatement in RFC3448 and should be considered for fixing in | RFC3448bis. Every other loss interval is defined as a length in | sequence space INCLUDING lost and marked packets (RFC3448 5.3). There | seems no reason to EXCLUDE lost and marked packets for I_0; this might | lead to weird rate hiccups where the TFRC rate INCREASED after a loss | (because I_0 got longer when it became I_1)! I would define I_0 as "the | most recent interval, which includes the most recent loss event and all | packets thereafter" (5.4), and say later that I_0 "includes the packets | received since the last loss event" (rather than REPRESENTS the number | of packets received since the last loss event) (5.5). | | Eddie | | | | | Gerrit Renker wrote: | > 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 majordomo@xxxxxxxxxxxxxxx | More majordomo info at http://vger.kernel.org/majordomo-info.html | |
