SRM log is not correct

[Christoph Haenle <haenle@gummo.starburstcom.com>]

Kannan,

I've been seeking the origin for incorrect data in the logfile for
ca. 15 hours.

Wanted to measure how many duplicate lost packets and repairs the
various participants of an SRM-group with 1 sender and n receiver
experience.

My expectation was that the overall sum of "#lost packets" and
"#dupl. repairs" is somewhat more or less constant for
all receivers (at least for low packet loss rates under the
assumption that repair packets get lost rarely).
In that case, the equation should hold because if all receivers
see all repair packets, then the lossy ones report a fewer
number of dupREPR's and a larger number of lost packets whereas
the good receivers have hardly and packet loss, but more dupREPR's.

However, it turned out that the equation was pretty much violated.
I figured out the problem:

Lost repair-requests do not trigger a new instance of "SRM/repair" if
a repair-packet is received later on (see point 1.)

---------------------------------------------------------------------
    Agent/SRM instproc recv-repair {round sender msgid} {
	     $self instvar pending_ stats_
	     if ![info exists pending_($sender:$msgid)] {
		     # 1.  We didn't hear the request for the older ADU, or
		     # 2.  This is a very late repair beyond the $3 d_{S,B}$ wait
		     # What should we do?
             [NOTHING]
---------------------------------------------------------------------

If the packet loss is repaired by other participants by a couple of
repair packets, then all of them will be ignored, thus no statistics_
is logged for that sequence number. This causes my measurements to
greatly become wrong.

Just like a SRM/request-instance stays alive for 3d(S,B) after the missing
packet was received (no repair is ever sent in SRM/request-instances)
only because of gathering statistics, the same should be in the situation
described above, i.e. a SRM/repair-instance should be created and set
immediately to the "holdDown" state.


Do you have a suggestion or could you take care of this?


    -Chris.