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.
