Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gerrit and Gorry,

Assuming that we now have converged on the disabled Send RTT Estimate Feature issue, do you agree with the other comments made on the latest version (by Eddie and Michael)? Do we have remaining open issues?

- Pasi


On Oct 18, 2010, at 2:19 PM, Gerrit Renker wrote:

> Following comments on the list, we have revised the Sender RTT Estimate draft
> and uploaded a revised version on 
> 
>    http://www.ietf.org/staging/draft-ietf-dccp-tfrc-rtt-option-00.txt
> 
> There is a detailed ChangeLog at the end.
> 
> Thanks to Pasi and Eddie who had supplied comments that have helped to improve
> the text. Please find detailed replies to comments below.
> 
> Gerrit and Gorry
> 
> -----------------------------------------------------------------------------------------------------------
>> Date: Wed, 22 Sep 2010 16:57:53 +0300
>> From: Pasi Sarolahti <pasi.sarolahti@xxxxxx>
>> Subject: Re:  New I-D revision: TFRC with sender-RTT estimate
>> 
> <...>
>>  is proposed. But in Sec 2.1, para 3, the text perhaps could be more verbose
>>  about what exactly is the first problem. What happens if CCval diff is less
>>  than 2 or more than 4?
>> 
> Clarified this in section 2.1 (please see changelog).
> 
>> * Sec 3.1, para 1: is this necessarily a TFRC-specific option, even though its
>>  only current application is with TFRC?
>> 
> The scope of the document has been to fix a problem with CCID-3 and CCID-4
> since both are using the CCVal window counter algorithm from RFC 4342. Since we
> understand this need, we have left it define this way in the draft.
> 
> It may be possible that the option makes sense in other contexts too.  If the
> cost is minor, we could define it as a generic DCCP option, but the WG would
> need to motivate why this is useful. Is this more than also saying "Updated RFC
> 4340" and defining a different option number?
> 
>> * There could be a few words before the option format illustration below table
>>  1, just to say (the perhaps obvious fact) that the illustration represents
>>  the option format on wire.
>> 
> Clarified this right at the begin, in section 3.1 (please see changelog).
> 
>> * below the option format description: "senders sampling with a lower
>>  resolution can multiply their RTT estimates" -- I first misread this as to
>>  say that under some circumstances the value of the field is multiplied by
>>  something, which presumably is not the case. If the point of the sentence in
>>  parenthesis is just to say that implementations need to be able to scale
>>  their measurements to 1 microsecond granularity, I wonder if this is a
>>  necessary note at all, or if it could be reworded.
>> 
> You are right, it is superfluous and confusing, thus has been removed.
> 
>> * The following paragraph: "Senders SHOULD send long-term RTT estimates" --
>>  could explain more what is a long-term RTT estimate in practice. Is it a
>>  moving average? Could there be a recommendation what is a good enough
>>  sampling period?
>> 
> Good point, decided to remove this recommendation since it can not be generalized.
> Some connections are short and do not allow for long-term estimates. In other cases
> the path RTT might change and a long-term estimate would reflect the change only 
> slowly. There is some discussion on robustness now in section 3.3.
> 
> -----------------------------------------------------------------------------------------------------------
>> Date: Mon, 20 Sep 2010 10:16:10 -0700
>> From: Eddie Kohler <kohler@xxxxxxxxxxx>
>> Subject: Re:  New I-D revision: TFRC with sender-RTT estimate
>> 
>> * I might prefer to reorder Section 3 and Section 2.  Lead with the option,
>>  follow with the justification.
>> 
> Would much prefer to keep the ordering of the document since other parts of the document
> also rely on the ordering; reshuffling the sections means rewriting much of the document.
> 
> 
>> * It is slightly too bad to use 4 bytes for an RTT Estimate option, when in
>>  most cases the two more significant bytes will be zero.  However, I defer to
>>  the proposers on whether the implementation effort of a variable length option
>>  would be worth the benefit.
>> 
> Thank you; section 3.2.1 has been updated to now specify variable-length options. 
> 
>> * I would put a maximum meaningful value on the Sender RTT Estimate.  In 
>>  particular, since retransmission timers back off to at most 64 seconds, 
>>  64000000 seems like an upper bound on the maximum meaningful Sender RTT Estimate.
>> 
> Revising the option format has naturally lead to a maximum RTT of 16.7 seconds in the
> 3 byte variant (0xffffff). We decided not to support RTTs larger than 16.7 seconds:
> it is not worth the complexity and the additional 4-byte format to support RTT estimates
> in the range from 16.7 seconds to 1.2 hours.
> 
>> * S3.3 "When the Send RTT Estimate FEATURE [sic, note added word] is disabled, 
> Fixed, please see changelog.
> 
>>  the sender MUST NOT send RTT Estimate options...."  Why not?  DCCP receivers will 
>>  correctly ignore RTT Estimate options they do not understand.  And it would seem
>>  useful to take advantage of RTT Estimates whether or not they were required.
> The document follows RFC 4340, 15. We much prefer to give one unambiguous
> specification that agrees with the existing standards.
> 
>>  The document should also perhaps define what happens if a sender agrees to Send 
>>  RTT Estimate and then doesn't actually do so (or sends 0 for too long).
>> 
> That is a good point, section 3.3 has been revised with regard to that (please see
> changelog).
> 
>> A first thought:
>>  - If Send RTT Estimate is 1, the sender MUST provide RTT Estimate options 
>>    on the described packets.
>>  - If Send RTT Estimate is 1, the receiver MUST use the provided RTT 
>>    Estimates in place of the CCVal window counter values.  (Note: The current doc 
>>    says MUST NOT estimate the RTT using CCVal.  Of course, an implementation 
>>    MIGHT estimate the RTT that way; it's just not supposed to USE that estimate.)
> Revised that section: the CCVal value now serves as a fallback mechanism.
> 
> 
>>  - If Send RTT Estimate is 0, the sender MAY provide RTT Estimate options.
>>  - If Send RTT Estimate is 0, the receiver MAY use provided RTT Estimate 
>>    options to augment RTTs estimated another way, but MUST use CCVal window 
>>    counter values or other RTT estimation techniques when valid RTT Estimates are 
>>    not available.
> Not done due to decision above.
> 
>>  - Invalid RTT Estimates: A packet without an RTT Estimate option is 
>>    considered to have an RTT Estimate of 0.
>>  - Invalid RTT Estimates: [TOTAL GUESSWORK -- DO WE ACTUALLY NEED TO 
>>    SPECIFY?]  If at least 64 consecutive packets are received with zero RTT 
>>    Estimates, the receiver MUST treat the RTT Estimate as 64000000. ????????????????
>> 
> The general idea is very good and as a consequence section 3.3 has been reworked in order
> to specify what happens in this case.
> 
> Tracking 64 consecutive packets is a lot of state. Decided to use a maximum of 2 successive
> 0-valued RTT Estimate options since this allows to track the state e.g. in a single-bit
> boolean flag. 
> 




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux