Thanks for the update!
Michael, Eddie -- are you happy with how your comments were addressed? If so, I think we can start WGLC.
- Pasi
On Dec 9, 2010, at 2:16 PM, Gerrit Renker wrote:
> Thanks to everyone who commented on the first revision of the draft.
>
> A new revsion, 01, has been uploaded which is in reply to the comments
> posted earlier -- please see details below.
>
> --------------------------------------------------------------------------------------------
> From: Michael Welzl <michawe@xxxxxxxxxx>
> Date: Wed, 3 Nov 2010 16:08:05 +0100
> Subject: Review of draft-ietf-dccp-tfrc-rtt-option-00.txt
>
> Michael,
>
> both I and Gorry would like to thank you very much indeed for your careful
> reading of the draft. This has been a highly valuable help in identifying
> issues that were important to get right.
>
>
>> 1. You specify that after more than MAX_INVALID_RTT=2 successive 0-
>> valued RTT estimate options, the receiver MUST disregard all
>> subsequent RTT Estimate options.
>>
>> Why isn't it good enough to just disregard all subsequent RTT Estimate
>> options until they carry a normal value again?
>> Since, upon negotiating the use of the option, a sender MUST use it,
>> your "disregard all subsequent .." rule means that there is no way for
>> a sender to not have a valid estimate for a while, and provide a valid
>> estimate again a bit later.
>>
> This and the complementary case below indicated that the previous scheme
> had genuine problems. In revising this, we found a simpler scheme which
> uses a moving average and reacts conservatively (back-off) in response
> to no-number RTT Estimate Options. Please see the revised section 3.3
> and the new section 3.4 for details.
>
>
>> 2. two paragraphs below ("When receiving the special RTT Estimate
>> Option of value 0xFFFFFF, ..."), a similar problem appears - "the
>> receiver SHOULD NOT continue to sample the RTT" ......... until when?
>> Until the end of the connection?
> This case is complementary to the 0-valued one, also addressed by the
> new scheme.
>
>
>> Also, in the same paragraph, you write that it should take appropriate
>> measures to improve the connection's quality, e.g. by associating with
>> a different access point. This seems to stretch the abilities of a DCCP
>> receiver, so I'm not sure if this is appropriate to write in this draft.
>>
> Correct, in response to your feedback this now has been removed.
>
>
>> Actually, although I like the idea of a special value meaning "the RTT
>> exceeds the bounds that we can specify", this paragraph makes me wonder
>> if the 0xFFFFFF value is really useful - I'd expect that continuous use
>> of a 0-value also means "we have a problem" for a receiver.
>>
> You are right, both values communicate a (problem) state, not a sample.
>
> We would like to keep the different meanings of the two values:
> (a) The 0-valued sample can be used to invalidate a previous series
> of samples, to tell the receiver that the sender does not have a
> valid RTT estimate.
> (b) The 0xFFFFFF value indicates an out-of-bounds condition where a sample
> exists but is so large it can no longer be represented.
> Having different semantics may also make sense for a future extension.
>
>
>> Editorial comments:
>>
>> page 5 par 3: "compare [RFC5348]" => is "compare" really the right
>> word here, isn't it rather "see"? I'm not a native speaker, so you're
>> more likely to be right than me :)
> Done.
>
>
>> par 5: the problem described by the first two sentences: "The fifth
>> and last problem is starvation under burst loss..." is not clear
>> enough.
> Please see the ChangeLog and the posting on dccp@ietf -- the paragraph
> has been rewritten from scratch, reducing the imprecise description to
> what I believe is the problem (different rates of change, X and the RTT
> used for the CCVal window counter algorithm).
>
>
>> page 6 par 1: "We are not aware..." - this text appears surprising,
>> because, at this point of the document, you have not yet presented
>> your method. Anyway what's the point of this statement? It feels a bit
>> like "defend an academic paper against its reviewers" language to me.
>> I suggest to remove it.
> Done.
>
>
>> Page 7 par 2: "...which requires complex computations to avoid
>> aliasing effects." - again, this should probably be phrased a bit more
>> precisely, it's not intuitively clear to me how this counter causes
>> complex computations.
> Simplified this sentence. What was perhaps confusing here is that it was
> implicitly referring to the following paragraph of RFC 4342, sec. 10.2:
>
> "[...] the receiver only considers losses X and Y as separate loss
> events if there exists some packet S received between X and Y, with
> the distance from C(X_prev) to C(S) greater than 4. This complex
> calculation is necessary in order to handle the case window counter
> space wrapped completely between X and Y."
>
> --------------------------------------------------------------------------------------------
> From: Eddie Kohler <kohler@xxxxxxxxxxx>
> Date: Fri, 05 Nov 2010 08:54:04 -0700
> Subject: Re: revised sender RTT estimate draft-ietf-dccp-tfrc-rtt-option-00.txt
>
>> Replacing this paragraph
>>
>> When the Send RTT Estimate Feature is disabled, the sender MUST NOT
>> send RTT Estimate options on any of its packets, the receiver MUST
>> ignore the RTT Estimate Option on all incoming packets, and SHOULD
>> try to estimate the RTT in some other way (not specified by this
>> document).
>>
>> with
>>
>> When the Send RTT Estimate Feature is disabled, the receiver MUST
>> estimate the RTT as previously specified in RFC4340/4342/5622.
>>
>> would be acceptable, as I said.
>>
> Thank you, section 3.3 has been updated to now use the above text.
> --------------------------------------------------------------------------------------------
>
> Gerrit and Gorry
