Re: [PATCH 2/5]: DCCP Recalc on non-loss intervals

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

Hi Eddie

thanks for the clarification. I think this makes clear what Ian's recalculate-loss optimization
does. I am copying this to dccp@ietf as well since a related question was posed there.

What made the analysis so confusing is that [RFC 3448, 5.4] was used as reference, such as in 
the following commment.

    /* 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.

It is now, with the below, however clear that the relevant section is not 5.4, but rather 
section 6.1 - whichstates that the receiver has to recompute p on reception of each data packet.
And it seems to be the point of Ian's patch to relax this requirement somehow. 

Hence you are right, it is not a new technique but rather an attempt to optimise the implementation.

Thanks again for the references.

Gerrit
|  Chapter and verse, all from RFC 3448.
|  
|  5.4: "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."
|  
|      => If the time since the last loss interval will increase the average 
|  loss interval, then it should be included.
|      => Note that the time since the last loss interval will increase on every 
|  successful packet receipt.
|      => Therefore we may need to recalculate the average loss interval after 
|  every successful packet receipt (or, at the sender, on every feedback packet).
|  
|  5.4: "I_0 being the interval since the most recent loss event"
|  
|      => I_0 is the time since the last loss interval.
|  
|  5.5: "As described in Section 5.4 the average loss interval is calculated
|      using the n previous loss intervals I_1, ..., I_n, and the interval
|      I_0 that represents the number of packets received since the last
|      loss event."
|  
|      => thus I_0 means the same thing in 5.4 and 5.5
|  
|  5.5: "I_0 [is] the number of packets received since the last loss event"
|  
|      => yet another way to say the same thing
|  
|  5.5: "Note that with each new packet arrival, I_0 will increase further"
|  
|      => YET ANOTHER way to say the same thing.
|  
|  In summary
|  - I_0 is the interval since the most recent loss event
|  - I_0 increases with every packet received
|  - The average loss interval calculation depends on I_0
|  - The average loss interval should be recalculated whenever I_0 changes
|  - I_0 changes with every packet received
|  - What more can I say here?????
|  - All of this average loss interval calculation applies equally to sender and 
|  receiver; it is in section 5, a general section on "calculating loss event 
|  rate"; and as the intro to section 5 says, "Loss rate measurement is performed 
|  at the receiver"
|  
|  Ian's patch is NOT experimental; Ian is attempting to implement standard 
|  compliant behavior; Ian's change is documented in the RFCs; etc.; etc.; etc.
|  
|  Can we put this to bed?
|  
|  If you still don't understand, please be clearer about why not.
|  
|  Eddie
|  
|  
|  
|  
|  Gerrit Renker wrote:
|  > |  Um, you misunderstand.  The problem that Ian's patch addresses seems 
|  > |  entirely within the purview of RFC 3448/4342.  He is not trying to 
|  > |  innovate.  Recalculating the loss rate after a longer period of non-loss 
|  > |  is NOT EXPERIMENTAL it is REQUIRED.  The loss event rate is NOT 
|  > |  calculated ONLY when losses are detected.  It must be calculated on 
|  > |  every feedback packet.  I don't have time at the moment to look up 
|  > |  chapter and verse, maybe later.
|  > Please take another look at the patch: what you are saying is true but applies to the _sender_, but Ian's
|  > code is entirely within the _receiver_. We are not at 4342 yet, at the moment the receiver calculates
|  > the loss event rate and then contacts the receiver.
|  > 
|  > Can you please look up chapter and verse -- I have read all related documents and can only identify
|  > section 5.4 of RFC 3448. With regard to this, we are in agreement: this needs to be audited to be conform.
|  > 
|  > But with regard to recalculating the loss rate after a longer period of non-loss: 
|  > 
|  >  => either there is indeed a reference for this in the current RFCs (it is not [RFC 3448, 5.4] and not the
|  >      corresponding section in 3448bis) but then neither Ian nor I have found this
|  > 
|  >  => or there is no such reference and then we should clearly separate the issues into (a) making sure that
|  >      the code complies to [RFC 3448, 5.4] and (b) what do we do with the "recalculating the loss rate after
|  >      a longer period of non-loss" ?
|  > 
|  > 
|  > |  I think (for what it's worth) his patch should be accepted as is, and 
|  > |  maybe he, or someone, will simplify the recalc_recalcloss part later.
|  > I agree with the points you raised, but disagree with adding an experimental part. The reason is that
|  > the CCID 3 module is still seriously broken:
|  > 
|  > 	* from the output of dccp_probe one can see that the entire system is oscillating and not
|  >           reaching a stable fixed point; even under ideal, non-loss conditions
|  >         * the behaviour using tools such as iperf is unpredictable
|  >         * performance is very poor: sometimes, on a good day one gets 50% of the bandwidth, but at other
|  >           test runs the speed goes down to only a couple of Mbits/sec (and this with a loss rate of 0)
|  > 
|  > Therefore my suggestion is for the moment to only put in changes which are documented in the RFCs, fix
|  > all these bugs, and add everything else once the basic problems have been sorted out.
|  
|