Re: SRM log is not correct

[Kannan Varadhan <kannan@ISI.EDU>]

Hi Christoph,

Apologies for the delay.

At 09:24 PM 9/25/97 -0400, Christoph Haenle wrote:
>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

I don't think I follow you.

An agent at a node $n_i$ spins off a separate loss object to handle the
repair for a particular loss.  dupREPR is the statistic maintained by one
loss object:  that object tracks the number of duplicate repairs that it
notices at $n_i$.
It is not clear to me how the loss of a packet can be co-related to
protocol behaviour at a node.

>---------------------------------------------------------------------
>    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]
>---------------------------------------------------------------------
>
>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.

Ummm...the code above is "correct" for some definition of the word.
This code is invoked when an agent receives a repair.  At this point,
one of three possibilities occur:  either the agent is currently executing
some error recovery, i.e. a request or a repair, in which case
an error recovery object exists, and will handle the repair (which is
usually to go in the 3d(S,B) wait, or none exists.  Bullets 1 and 2 in the
comment above illustrate this.  

If you create an error recovery object, and force the agent into a 3d(S,B)
wait for this packet, then the agent will not be able to assist another
possibly valid request for that packet.  I believe that this is undesirable
behaviour per the description of SRM in Floyd etal. [sigcomm '95].

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

Because of similar constraints in getting statistics, I resorted to
gethering this information from the trace data.  I wrote up some scripts to
parse the data that I hope to make available in a couple of weeks.

Alternatively, you may have other considerations or protocol behaviour in
mind that is somehow different from the SRM paper.  If you describe your
requirements in some other detail, we can try to figure out how best to
code this.

Another quick hack option (though, in the medium to long run, this may not
be quite what you want) is to either derive a separate SRM agent that
simply overloads this particular method in OTcl, or to override this method
in specific simulation scripts.



Kannan