Hi, Here are a few comments, no hats on. Generally, I think the draft reads well and is easy to understand, and I didn't find any major issues with it. * I like it how section 2 describes the problems clearly and in good detail. After reading the section, there isn't much question why this option 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? * Sec 3.1, para 1: is this necessarily a TFRC-specific option, even though its only current application is with TFRC? * 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. * 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. * 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? - Pasi On Aug 18, 2010, at 2:42 PM, Gorry Fairhurst wrote: > Dear DCCP'ers. > > Gerrit has been working on improving the CCID-3 implementation in Linux, and this has raised the question of whether we can now progress the 'sender sends RTT estimate' option that was originally specified (and recommended) in RFC 5348 and which was submitted asdraft-renker-dccp-tfrc-rtt-option-00.txt, with accompanying slides for IETF-72 at: > > https://wiki.tools.ietf.org/agenda/72/slides/dccp-3.pdf > > We therefore have uploaded > > http://tools.ietf.org/id/draft-renker-dccp-tfrc-rtt-option-01.txt > > We'd like the WG to consider this minor, but important update as a suitable piece of work for standardisation - We believe it addresses several practical issues with the current DCCP CCID3/4 approach. > > Please read and send comments to the DCCP list. > > Best wishes, > > Gorry & Gerrit
