Hi all,
I'm glad to see this as a DCCP draft. Although some of the descriptions of
problems are surprising, they are not that contentious; and the option itself
seems, simply, useful.
Some comments on the draft itself.
* I might prefer to reorder Section 3 and Section 2. Lead with the option,
follow with the justification.
* 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.
* 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.
* S3.3 "When the Send RTT Estimate FEATURE [sic, note added word] is disabled,
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 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).
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.)
- 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.
- 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. ????????????????
Thanks much, Gerrit and Gorry, for this useful work.
Eddie
On 09/08/2010 08:06 AM, Lars Eggert wrote:
Hi,
and with my AD hat on, I would like to see this document progress MUCH faster than the UDP-encaps document did. If possible, WGLC before Beijing.
Lars
On 2010-9-8, at 17:24, Pasi Sarolahti wrote:
Based on the feedback, there seems to be pretty good support for doing
this draft as a DCCP working group item, and this seems a straight-
forward improvement to TFRC. Therefore, authors, please submit the
next version as a DCCP working group draft, with the draft name set
accordingly. The rest of us should read and send comments on the
draft, to help the authors make timely progress getting this forward.
Thanks!
- Pasi& Tom
On Aug 20, 2010, at 9:54 PM, Pasi Sarolahti wrote:
Ok, so a couple of questions:
Gerrit, Gorry: if there is support to take this forward, how close
to ready would you think we are -- are there open issues? Would it
be realistic to think about WGLC in about few months of time? With
quick reading I couldn't identify any contentious issues in the
draft, and I think it points out a relevant problem in TFRC that
needs to be addressed.
Group: would you support this to become a DCCP working group item
for a proposed standard RFC? I will assume that people who respond
"Yes" are committing to participate in reviewing this and the
subsequent versions of the draft.
- Pasi
On Aug 18, 2010, at 4:42 AM, 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
