On Tue, Oct 20, 2009 at 2:09 AM, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:
> | It considers if an interval is 2 RTT old, instead of 2 RTT long. But I
> | sent this code in this state anyway, because I want to ask how to solve
> | this problem.
> This is a good point. Personally, I can not really see an advantage in
> storing old data at the sender, as it seems to increase the complexity,
> without at the same time introducing a benefit.
>
> Adding the 'two RTTs old' worth of information at the sender re-introduces
> things that were removed already. The old CCID-3 sender used to store
> a lot of information about old packets, now it is much leaner and keeps
> only the minimum required information.
So, how we can solve this? How can we determine if a loss interval is
(or not) 2 RTT long in the sender?
> Your receiver already implements '2 RTTs long':
> tfrc_sp_lh_interval_add():
>
> /* Test if this event starts a new loss interval */
> if (cur != NULL) {
> s64 len = dccp_delta_seqno(cur->li_seqno, cong_evt_seqno);
>
> // ...
>
> cur->li_length = len;
>
> if (SUB16(cong_evt->tfrchrx_ccval, cur->li_ccval) <= 8)
> cur->li_is_short = 1;
> }
>
> Would it help your implementation if the receiver had a more precise measure
> for "2 RTT long"? A while ago I got fed up with the imprecise RTT measurements
> that the receiver produced when using the CCVal to compute the RTT. The
> suggestion was that the sender would supply its RTT estimate via an option,
>
> "Sender RTT Estimate Option for DCCP"
> http://tools.ietf.org/html/draft-renker-dccp-tfrc-rtt-option-00
>
> If the receiver knew the RTT, it could subtract timestamps and compare
> these against the RTT value. Currently, with the CCVal it is (as for
> the receiver-based RTT estimation), a bit difficult. RFC 5622, 8.1:
>
> "None of these procedures require the receiver to maintain an explicit
> estimate of the round-trip time. However, Section 8.1 of [RFC4342]
> gives a procedure that implementors may use if they wish to keep such
> an RTT estimate using CCVal."
>
> But the problem is that the algorithm in section 8.1 of RFC 4342 (which
> is used by the CCID-3/4 receiver has already proven not to be very reliable,
> it suffers from similar problems as the packet-pair technique.
>
This would be an improvement over the current RTT determination method
on the receiver. But it wouldn't help the sender problem that I said
above. There is no way in Loss Intervals option to tell the sender
about the duration of each Loss Interval, I think.
> As a second point, I still think that a receiver-based CCID-4 implementation
> would be the simplest possible starting point. In this light, do you see an
> advantage in supplying an RTT estimate from sender to receiver?
Yes, better precision. But, at the cost of adding an option
undocumented by any RFC's?
--
Ivo Augusto Andrade Rocha Calado
MSc. Candidate
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Systems and Computing Department - http://www.dsc.ufcg.edu.br
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0x03422935
Quidquid latine dictum sit, altum viditur.
--
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
